
Message-ID: <47C22EF0.7040302@cisco.com>
Date: Sun, 24 Feb 2008 21:58:56 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: apps-review@ietf.org, IETF Sipping List <sipping@ietf.org>, claudio.allocchio@garr.it
Subject: [APPS-REVIEW] response to APPS-REVIEW of draft-ietf-sipping-service-identification-00
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: apps-review-bounces@ietf.org
Errors-To: apps-review-bounces@ietf.org

Claudio,

You posted a review of this document back in November:
http://www.ietf.org/mail-archive/web/apps-review/current/msg00112.html

I am very delinquent in this update, and apologize for the long delay in 
responding. Thanks for the comments. Responses below:

> General Comments:
> 
> 
> The idea and the problem being addressed is described quite clearly
> in the "Introduction" section. However the Abstract itself seems to
> stress to much the "legal/fraud" bullet point, while the focus of the
> document indeed is elsewhere and more general. I would add a more
> coherent abstract instead of the current one.

The abstract only list fraud as one of several concerns, so I don't see 
how the abstract was emphasizing it. Anyway I tried to reword to align 
it more closely with the flow of the document. So now it reads:

             <t>This document considers the problem of service
	    identification in the Session Initiation Protocol
	    (SIP). Service identification is the process of
	    determining the user-level use case that is driving the
	    signaling being utilized by the user agent. This document
	    discusses the uses of service identification, and outlines
	    several architectural principles behind the process. It
	    identifies several perils associated with service
	    identification, including fraud, interoperability failures
	    and stifling of innovation.
	    </t>


> 
> The term "user agent" is used in the document more as identifying the
> "hardware device", specifically when it states that multiple
> application can run within the same user agent, etc.

Actually it is referring to a SIP user agent, defined in RFC 3261. There 
is a common practice for multiple applications to make use of a common 
SIP stack. I've clarified this in that section:

In some of the examples above, there were multiple software
applications executing on the host. One common way of achieving this
is to utilize a common SIP user agent implementation that
listens for requests on a single port. When an incoming


  This is not
> coherent with the normal definition of user agent, which corresponds
> to a specific application running inside a hardware device (the
> super-classical e-mail User Agent programme, running within a PC,
> mobile device, whatever...). It might lead to confusion.
> 
> As a final general comment, the document itself is a Reccommendation
> more than a BCP in itself... are we sure this is the correct track to
> put it forward?

Informational is probably appropriate here. I changed.

> 
> Conclusion: IMHO ths document is useful, and should be pushed
> forward, even if it might sound "strange" a document whose aim is to
> prevent a potentially BAD practice... I really to not know if it
> whould be better to have this as somthing else than BCP... I would
> call it something in a category like "things you should not do".
> 
> ;-)
> 
> 
> from now on, se inline...
> 
> 
> Best regards, and sorry for being a bit late in the revision!
> 
> 
> Claudio
> 
> 
> -------------
> 
> 
> Detailed inline review:
> 
> 
> see below, notes labelled by ***, some portions of the draft omitted:
> 
> 
> 
> SIPPING                                                     J.
> Rosenberg Internet-Draft
> Cisco Intended status: Best Current
> August 1, 2007 Practice Expires: February 2, 2008
> 
> 
> 
> Identification of Communications Services in the Session Initiation 
> Protocol (SIP) draft-ietf-sipping-service-identification-00
> 
> 
> 
> <.. omitted ..>
> 
> 
> Abstract
> 
> 
> This document considers the problem of service identification in the 
> Session Initiation Protocol (SIP).  Service identification is the 
> process of determining the user-level use case that is driving the 
> signaling being utilized by the user agent.  While seemingly simple, 
> this process is quite complex, and when not addressed properly, can 
> lead to fraud, interoperability problems, and stifling of innovation.
> 
> 
> 
> *** see general comment above.

see my new abstract above.

> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 1]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> This document discusses these problems and makes recommendations on 
> how to address them.
> 
> 
> <.. omitted ..>
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 2]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> 1.  Introduction
> 
> 
> The Session Initiation Protocol (SIP) [2] defines mechanisms for 
> initiating and managing communications sessions between agents.  SIP 
> allows for a broad array of session types between agents.  It can 
> manage audio sessions, ranging from low bitrate voice-only up to 
> multi-channel hi fidelity music.  It can manage video sessions, 
> ranging from small, "talking-head" style video chat, up to high 
> definition multipoint video conferencing, to low bandwidth user- 
> generated content, up to high definition movie and TV content.  SIP 
> endpoints can be anything - adaptors that convert an old analog 
> telephone to Voice over IP (VoIP), dedicated hardphones, fancy 
> hardphones with rich displays and user entry capabilities, softphones
>  on a PC, buddylist and presence applications on a PC, dedicated 
> videoconferencing peripherals, and speakerphones.
> 
> 
> This breadth of applicability is SIPs greatest asset, but it also 
> introduces numerous challenges.  One of these is that, when an 
> endpoint generates a SIP INVITE for a session, or receives one, that 
> session can potentially be within the context of any number of 
> different use cases and endpoint types.  For example, a SIP INVITE 
> with a single audio stream could represent a Push-To-Talk session 
> between mobile devices, a VoIP session between softphones, or audio- 
> based access to stored content on a server.
> 
> 
> These differing use cases have driven implementors and system 
> designers to seek techniques for service identification.  Service 
> identification is the process of determining and/or signaling the 
> specific use case that is driving the signaling being generated by a 
> user agent.  At first glance, this seems harmless and easy enough. It
> is tempting to define a new header, "Service-ID", for example, and 
> have a user agent populate it with any number of well-known tokens 
> which define what the service is.  This information could then be 
> consumed for any number of purposes.
> 
> 
> *** it is unclear at this point if the idea of the new header here is
> being anyhow suggested, depracted, or an alternate better solution
> should be stanrdised. I guess it should make such a statement,
> already at this point, to clarify.


Its saying that doing something like that is a bad idea. I make that 
statement clearly here now:

which define what the service is. This information could then be
consumed for any number of purposes. This approach has many problems,
however. Inclusion of an explicit service identifier in the request
can very easily lead to
fraud, systemic interoperability failures, and a complete stifling of
the innovation that SIP was meant to achieve. The purpose of this
document is to describe service identification in more detail and
describe how these problems arise.
</t>


> 
> However, as this document will demonstrate, service identification is
>  a very complex and difficult process, and can very easily lead to 
> fraud, systemic interoperability failures, and a complete stifling of
>  the innovation that SIP was meant to achieve.
> 
> 
> Section 3 begins by defining a service and the service identification
>  problem.  Section 4 gives some concrete examples of services and why
>  they can be challenging to identify.  Section 5 explores the ways in
>  which a service identification can be utilized within a network. 
> Next, Section 6 discusses the key architectural principles of service
>  identification, and how explicit service identifiers can lead to 
> fraud, interoperability failures, and stifling of service innovation.
> 
> 
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 3]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> 2.  Terminology
> 
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
> document are to be interpreted as described in RFC 2119 [1].
> 
> 
> 
> 3.  Services and Service Identification
> 
> 
> The problem of identifying services within SIP is not a new one.  The
>  problem has been considered extensively in the context of presence. 
> In particular, the presence data model for SIP [3] defines the 
> concept of a service as one of the core notions that presence 
> describes.  Services are described in Section 3.3 of RFC 4479, which 
> has this to say on the topic:
> 
> 
> *** as a general procedural suggestion, I would avoid quoting full
> sections of existing other documents, as they may be updated,
> obsoleted, etc, creating corss reference problems more complex than
> needed if full quoting is used. Replacing the "included" session with
> a reference and just a few significant senteces makes it better. And,
> people redint this BCP shall have no problems in reading the full
> original section, or updates, themselves.

OK.


> 
> 3.3.  Service
> 
> 
> Each presentity has access to a number of services.  Each of these 
> represents a point of reachability for communications that can be 
> used to interact with the user.  Examples of services are telephony 
> (that is, traditional circuit-based telephone service), push-to-talk,
>  instant messaging, Short Message Service (SMS), and Multimedia 
> Message Service (MMS).
> 
> 
> *** for example, the definition of "presentity" is missing here,
> forcing the cautious readed to grab and read the original
> specification anyhow :-)

Inline text was removed.

> 
> It is difficult to give a precise definition for service.  One 
> reasonable approach is to model each software or hardware agent in 
> the system as a service.  If a user starts a softphone application on
> 
> 
> 
> <.. omitted ..>
> 
> 
> Essentially, the service is the user-visible use case that is driving
>  the behavior of the user-agents and servers in the SIP network. 
> Being user-visible means that there is a difference in user 
> experience between two services that are different.  That user 
> experience can be part of the call, or outside of the call.  Within a
>  call, the user experience can be based on different media types (an 
> audio call vs. a video chat), different content within a particular 
> media type (stored content, such as a movie or TV session), different
>  devices (a wireless device for "telephony" vs. a PC application for 
> "voice-chat"), different user interfaces (a buddy list view of voice 
> on a PC application vs. a software emulation of a hard phone), 
> different communities that can be accessed (voice chat with other 
> users that have the same voice chat client, vs. voice communications 
> with any endpoint on the PSTN), or different applications that are 
> invoked by the user (manually selecting a push-to-talk application 
> from a wireless phone vs. a telephony application).  Outside of a 
> call, the difference in user experience can be a billing one (cheaper
>  for one service than other), a notification feature for one and not 
> another (for example, an IM that gets sent whenever a user makes a
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 5]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> call), and so on.
> 
> 
> In some cases, there is very little difference in the underlying 
> technology that will support two different services, and in other 
> cases, there are big differences.  However, for purposes of this 
> discussion, the key definition is that two services are distinct when
>  there is a perceived difference by the user in the two services.
> 
> 
> *** the whole above descriptive section is mabe even too long. The
> concept is made clear in the last above sentence "However... in the
> two services", hence I suggest shrinking the previous descripive
> text.

One thing that was clear in the many discussions leading up to this 
draft, is that lack of examples made any conversation on the topic hard 
to understand. Everyone had a different idea in mind of what things like 
service, user experience, and so on, meant. So I think it is important 
to retain this text.

> 
> This leads naturally to the desire to perform service identification.
>  Service identification is defined as the process of (1)
> determination of the underlying service which is driving a particular
> signaling exchange, (2) associating that service with some kind of
> moniker, and (3) attaching that moniker to a signaling message
> (typically a SIP INVITE), and then utilizing it for various purposes
> within the network.  Service identification can be done in the
> endpoints, in which case the UA would insert the moniker directly
> into the signaling message based on its awareness of the service.
> Or, it can be done within a proxy in the network, based on inspection
> of the SIP message, or based on hints placed into the message by the
> user.
> 
> 
> 
> 4.  Example Services
> 
> 
> It is very useful to consider several example services, especially 
> ones that appear difficult to differentiate from each other.
> 
> 
> 4.1.  IPTV vs. Multimedia
> 
> 
> IP Television (IPTV) is the usage of IP networks to access 
> traditional television content, such as movies and shows.  SIP can be
>  utilized to establish a session to a media server in a network,
> which then serves up multimedia content and streams it as an audio
> and video stream towards the client.  Whether SIP is ideal for IPTV
> is, in itself, a good question.  However, such a discussion is
> outside the scope of this document.
> 
> 
> Consider multimedia conferencing.  The user accesses a voice and 
> video conference at a conference server.  The user might join in 
> listen-only mode, in which case the user receives audio and video 
> streams, but does not send.
> 
> 
> These two services - IPTV and multimedia conferencing, clearly appear
>  as different services.  They have different user experiences and 
> applications.  A user is unlikely to ever be confused about whether a
>  session is IPTV or multimedia conferencing.  Indeed, they are likely
>  to have different software applications or endpoints for the two 
> services.
> 
> 
> *** make it MORE clear that the multimedia conference you're talking
> about is the ONE WAY unidirectional "listening only" version of it.
> It might be more appropriate to call it "multimedia conference
> listening", or something similar for the purpouse of this example.

OK. I called it 'listen-only multimedia conferencing'.


> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 6]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> However, these two services look remarkably alike based on the 
> signaling.  Both utilize audio and video.  Both could utilize the 
> same codecs.  Both are unidirectional streams (from a server in the 
> network to the client).  Thus, it would appear on the surface that 
> there is no way to differentiate them, based on inspection of the 
> signaling alone.
> 
> 
> 4.2.  Gaming vs. Voice Chat
> 
> 
> Consider an interactive game, played between two users from their 
> mobile devices.  The game involves the users sending each other game 
> moves, using a messaging channel, in addition to voice.  In another 
> service, users have a voice and IM chat conversation using a buddy 
> list application on their PC.
> 
> 
> In both services, there are two media streams - audio and messaging. 
> The audio uses the same codecs.  Both use the Message Session Relay 
> Protocol (MSRP) [5].  In both cases, the caller would send an INVITE 
> to the AOR of the target user.  However, these represent fairly 
> different services, in terms of user experience.
> 
> 
> *** expand AOR acronym here, as it is the first occurence of it.

Done. Its Address of Record.

> 
> 
> <.. omitted ..>
> 
> 
> 5.  Using Service Identification
> 
> 
> It is important to understand what the service identity would be 
> utilized for, if known.  The discussions in Section 4 give some hints
> 
> 
> 
> 
> 
> Rosenberg               Expires February 2, 2008                [Page
> 7]
> 
> 
> Internet-Draft                 Service ID                    August
> 2007
> 
> 
> 
> to the possible usages.  Here, we explicitly discuss them.
> 
> 
> 5.1.  Application Invocation in the User Agent
> 
> 
> In some of the examples above, there were multiple software 
> applications running within a single user agent.  When an incoming
> 
> 
> *** see "User Agent" term use note I made inside the General Comments
> above.

Hopefully my suggested text makes this clear now.

> 
> *** is this sections exp;icitly suggesting the creation of the UI
> given in the figure below? It is not crstal clear... or it is just
> using the idea as a basis for discussiong its consequences if used?

Its saying that, in cases where the software is structured this way - 
with a common sip listener - you have this problem. Its the client-side 
equivalent of having a web server listen for requests for multiple 
different domains. You need something in the request itself (in the case 
of http, its the r-uri) to dispatch to the right application. However in 
SIP the request-uri will be the same for all requests, since it is 
entered by the user - i.e., I'd type "joe@example.com" in all cases. So 
something else - a service identity - is needed to dispatch.


> 
> I would clarify this in the begining of it.
> 
> 
> INVITE or MESSAGE arrives, it must be delivered to the appropriate 
> application software.  When each service is bound to a distinct 
> software application, it would seem that the service identity is 
> needed to dispatch the message to the appropriate piece of software. 
> This is shown in Figure 2.
> 
> 
> +---------------------------------+ |
> | | +-------------+ +-------------+ | | |     UI      | |     UI
> | | | +-------------+ +-------------+ | | +-------------+
> +-------------+ | | |             | |             | | | |  Service 1
> | |  Service 2  | | | |             | |             | | |
> +-------------+ +-------------+ | | +-----------------------------+ |
>  | |                             | | | |             SIP
> | | | |            Layer            | | | |
> | | | +-----------------------------+ | |
> | +---------------------------------+
> 
> 
> Physical Device
> 
> 
> Figure 2
> 
> 
> <.. omitted ..>
> 
> 
> 6.  Key Principles of Service Identification
> 
> 
> In this section, we describe some of the key principles of performing
>  service identification.
> 
> 
> 6.1.  Services are a By-Product of Signaling
> 
> 
> *** this section clearly states principles and reasons behind them.
> This is where the reference in the introduction should point for
> clarification of the suggestion that service-id is suggested or not.

Reference added. I reorganized this too so that there was a top-level 
section with principles and a separate top-level section with problems.

> 
> This is ultimately an expression of the principle of DWIM vs. DWIS 
> (Do-What-I-Mean vs. Do-What-I-Say).  Explicit signaling is DWIS - the
>  user is asking for a service by invoking the signaling that results 
> in the desired effect.  A service identifier is DWIM - an unspecific 
> request for something that is ill-defined and non-interoperable.
> 
> 
> *** true, please stress this also in introduction.

OK.
> 
> 
> 6.2.  Perils of Explicit Identifiers
> 
> 
> *** this section is the core of the motivation of the reccomendation
> in the following chapter. I would name it consequently, or make it
> clearer its role in the title.

I think the title is appropriate; I've promoted to a top-level section.

> 
> 7.  Recommendations
> 
> 
> From these principles, several recommendations can be made:
> 
> 
> o  Systems needing to perform service identification must examine 
> existing signaling constructs to identify the service based on fields
> that exist within the signaling message already.
> 
> 
> o  If it appears that the signaling currently defined in standards is
>  not sufficient to identify the service, it may be due to lack of 
> sufficient signaling to convey what is needed, and new standards work
> should be undertaken to fill this gap.
> 
> 
> o  The usage of an explicit service identifier does make sense as a 
> way to cache a decision made by a network element, for usage by 
> another network element within the same domain.  However, service 
> identifiers are fundamentally useful within a particular domain, and
> any such header must be stripped at a network boundary.
> 
> 
> *** ok see above.
> 
> 


Thanks for your comments!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
http://www.ietf.org/mailman/listinfo/apps-review


Return-Path: <apps-review-bounces@ietf.org>
X-Original-To: ietfarch-apps-review-archive@core3.amsl.com
Delivered-To: ietfarch-apps-review-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8714F28C261; Sun, 24 Feb 2008 14:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.464
X-Spam-Level: 
X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 931Spr+B+tSJ; Sun, 24 Feb 2008 14:45:01 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B31428C182; Sun, 24 Feb 2008 14:45:01 -0800 (PST)
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE433A6966; Fri, 22 Feb 2008 19:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROahelFTkGcM; Fri, 22 Feb 2008 19:47:22 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0C5763A69ED; Fri, 22 Feb 2008 19:47:19 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m1N3kVku004511; Fri, 22 Feb 2008 22:46:31 -0500 (EST)
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 22 Feb 2008 22:46:31 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m1N3kPXC026188; Fri, 22 Feb 2008 22:46:25 -0500 (EST)
From: andrea.doherty@rsa.com
Received: from CORPUSMX10B.corp.emc.com ([128.221.14.92]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 22 Feb 2008 22:46:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 22 Feb 2008 22:46:24 -0500
Message-ID: <9ED76AB595E4944BB33D8998DE448D1105B8A1@CORPUSMX10B.corp.emc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-keyprov-dskpp-01
Thread-Index: AcgoZco3aJyfP+nHRP2VH3x+iKGlIBNUvxHK
References: <20071116153033.GF28302@raktajino.does-not-exist.org>
To: <tlr@w3.org>, <smachani@diversinet.com>, <mpei@verisign.com>, <Magnus.Nystrom@rsa.com>, <pbaker@verisign.com>, <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 23 Feb 2008 03:46:25.0264 (UTC) FILETIME=[A9CE4700:01C875CE]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425
X-PerlMx-Spam: Gauge=, SPAM=7%, Reason='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Tablus-Inspected: yes
X-Tablus-Classifications: M and A Terms
X-Tablus-Action: allow
X-Mailman-Approved-At: Sun, 24 Feb 2008 14:44:59 -0800
Cc: keyprov@ietf.org, apps-review@ietf.org
Subject: Re: [APPS-REVIEW] Review of draft-ietf-keyprov-dskpp-01
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: apps-review-bounces@ietf.org
Errors-To: apps-review-bounces@ietf.org

Thomas,
 =

Thanks again for your comments and suggested text.  Please see (long overdu=
e) responses below.  Note that changes made will be in next draft (-03) due=
 25 Feb. By "TBS" is meant more consideration needs to be given to the poin=
ts that you raised.
 =

One question regarding your comment on Content Negotiation: I added your su=
ggested text to the section entitled "HTTP Headers" (now 6.2.3).  However, =
the phrase "SHOULD have the value application/vnd.ietf.keyp.dskpp+xml" is i=
nconsistent with the MUST from the section entitled "Identification of DSKP=
P Message" (Section 6.2.2 in the newest draft).  Is MUST appropriate in Sec=
tion 6.2.2?  (The text for Section 6.2.2 reads:"The MIME-type for all DSKPP=
 messages MUST be application/vnd.ietf.keyprov.dskpp+xml".

Best Regards,
Andrea

________________________________

From: Thomas Roessler [mailto:tlr@w3.org]
Sent: Fri 11/16/2007 10:30 AM
To: Doherty, Andrea; smachani@diversinet.com; mpei@verisign.com; Nystr=F6m,=
 Magnus; pbaker@verisign.com; Hannes.Tschofenig@gmx.net
Cc: apps-review@ietf.org; keyprov@ietf.org
Subject: Review of draft-ietf-keyprov-dskpp-01


This is a review of draft-ietf-keyprov-dskpp-01.  It occasionally =

strays into the PSKC draft; however, I haven't fully read that =

document. =


Specific observations on the HTTP binding: =


- In 12.2.4, the spec says "Persistent connections as defined in =

  HTTP/1.1 are assumed, but not required." Taken literally, I don't =

  know what "assumed, but not required" means. =


adoherty>>Rephrased this to "are OPTIONAL".

- The HTTP binding does not indicate whether it fully defines the =

  behavior of the HTTP server that is appearing as part of the =

  transactions, or whether the DSKPP server is identified by either =

  a specific URI and/or Host.  Please clarify that in the HTTP =

  binding part.  (4.3 -- and other places -- suggest that the DSKPP =

  server is indeed identified by a specific URI, which would be just =

  fine.) =


adoherty>>The DSKPP server is identified by a specific URL.  I added the fo=
llowing sentence to the end of the Introduction to the HTTP binding: "The D=
SKPP server will be identified by a specific URL, which may be pre-configur=
ed, or provided to the client during initialization."  I also added the fol=
lowing to Initialization of DSKPP: "The initialization message MAY carry da=
ta in its body, such as the URL for the DSKPP client to use when contacting=
 the DSKPP server."

- In 12.2.4, instead of talking about "POST operations", maybe say =

  "DSKPP requests are mapped to HTTP requests with the POST method". =


adoherty>>Good point; change made.

- For the 4-step protocol, it's probably worth calling out here how =

  the different messages are bound together, as they may be =

  transported through different connections.  In particular, =

  KeyProvServerHello is bound to the preceding KeyProvClientHello by =

  being transmitted in the corresponding HTTP response; =

  KeyProvServerHello MUST have a sessionId attribute, and the =

  sesionId on the subsequent KeyProvClientNonce MUST be identical. =

  KeyProServerFinished is then once again bound to the rest through =

  HTTP (and possibly through a sessionID). =


adoherty>>Change made.

- The HTTP binding does not cover content negotiation.  I'd suggest: =

  "HTTP requests MAY include an HTTP Accept header field. This =

  header field SHOULD have the value =

  application/vnd.ietf.keyprov.dskpp+xml.  The Accept header MAY =

  include additional content types defined by future versions of =

  this protocol." =

  =

  (The server is allowed to downgrade [6.2.3], so if a future =

  version uses a different content type, that should be in the =

  client's request, along with the current one, *if* the client is =

  willing to downgrade.) =


adoherty>>Added suggested text to HTTP Headers section.  The "SHOULD have t=
he value application/vnd.ietf.keyp.dskpp+xml" is inconsistent with the MUST=
 from the section entitled "Identification of DSKPP Message" (Section 6.2.2=
 in the newest draft).  Is MUST appropriate in Section 6.2.2?

- The examples in 12.2.8 don't match the requirements from 12.2.3. =


adoherty>>Good catch; fixed.

- 12.2.7 is extremely fuzzy as to when the server-side =

  initialization message may be sent.  As long as that's indeed in =

  response to a specific user request with the appropriate Accept =

  header (e.g., to a specific DSKPP server URL), the use of the 200 =

  code seems fine.  However, please clarify that using a 200 code =

  combined with the DSKPP content type is *not* an appropriate means =

  to trigger protocol initialization during a browsing session where =

  the user's request was directed to some other resource.  (In that =

  case, some 40x code might be much more appropriate.) =


adoherty>>Text was clarified.  In addition, the following note was added: "=
Note that if the user's request was directed to some other resource, the DS=
KPP server MUST NOT respond by combining the DSKPP content type with respon=
se code 200.  In that case, the DSKPP server SHOULD respond by sending a DS=
KPP initialization message in an HTTP response with Content-Type set accord=
ing to Section 6.2.2 and response code set to 406 (Not Acceptable)."

- It's not clear how one-step DSKPP would work over HTTP.  What kind =

  of request does the client send to trigger that?  If that isn't =

  intended to run over HTTP, please clarify. =


adoherty>>It would have required a request, and so would have behaved like =
two-pass. In any event, the one-pass DSKPP was removed as of the -02 versio=
n.

- In 12.2.3, the spec says: "HTTP proxies MUST NOT cache responses =

  carrying DSKPP messages. For this reason, the following holds:" =

  That's a conformance requirement on HTTP proxies; don't do that. =

  Instead: "In order to avoid caching of responses carrying DSKPP =

  messages by proxies, the following holds:" (Also, note that POST =

  invalidates cached entities.) =


adoherty>>Text added; thanks.

- In 12.2.5, "If the type of a DSKPP request cannot be determined, =

  the DSKPP responder MUST return a 400 response." What precisely is =

  meant by "type cannot be determined"?  (Example?) =


adoherty>>Reworded to say, "If a request is received that is not a DSKPP cl=
ient message, the DSKPP responder MUST return a 400 (Bad request) response."

Reviewing BCP56, I would suspect that there might be slight =

differences of opinion on whether DSKPP should have a port and URI =

scheme of its own. However, given that the protocol binding (with =

the above clarifications) will be layered rather cleanly on HTTP, =

and won't confuse URI-based addressing, I fail to see the benefit of =

allocating a separate port and/or URI scheme. This binding looks =

like it is implementable on top of a conventional Web server, which =

would suggest sticking to port 80 and http (or port 443 and https). =


Beyond that point, I do not see any significant disagreements =

between the guidance in BCP56 and this draft. =


Various other observations while going through the document... =


- -00 included schema fragments in section 4.9.  These are gone in =

  the corresponding sections in -01, making review of the schema for =

  consistency with the human-readable text significantly harder. I'd =

  recommend resurrecting the schema fragements in future iterations =

  of the draft for ease of review. =


  While dropping the schema fragments, *any* human-readable =

  documentation for types such as AbstractRequestType type has been =

  lost. =


adoherty>>Agree; the schema fragments have been returned to the rightful pl=
ace and examples are back in Appendix A.

- Please say early on in the spec what name space prefixes are used =

  in XML snippets throughout the document, and what they mean. =


adoherty>>TBS

- What's the order relation for the various Version attributes?  Are =

  they treated as decimal numbers, as strings, as a dot-separated =

  pairs of two integers?  Is "01.00" the same as "1.0"? =


adoherty>>Major and Minor releases defined by VersionType in the schema:

   <xs:simpleType name=3D"VersionType">
     <xs:restriction base=3D"xs:string">
       <xs:pattern value=3D"\d{1,2}\.\d{1,3}"/>
     </xs:restriction>
   </xs:simpleType>

Not sure that this needs to be called out explicitly in the text.

- Trying to assemble the overall XML schema to validate some of the =

  examples... =


  * DSKPP imports the schema from PSKC, which in turn imports a =

    schema for the urn:ietf:params:xml:ns:keyprov:logo namespace, =

    which apparently isn't available anywhere. =


adoherty>>"Logo" has been removed from the latest PSKC draft.
  =

  * The DSKPP and PSKC drafts use inconsistent namespaces for PSKC, =

    urn:ietf:params:xml:ns:keyprov:container vs =

    urn:ietf:params:xml:ns:keyprov:1.0:container =


adoherty>>Fixed as of -02 version of both documents.

  * The DSKPP schema uses an extension construct like this one =

    repeatedly (DeviceIdentifierDataType, KeyContainerType, =

    PayloadType, KeyProvTriggerType): =

  =

    <xs:complexType name=3D"DeviceIdentifierDataType"> =

      <xs:choice> =

        <xs:element name=3D"DeviceId" type=3D"pskc:DeviceIdType"/> =

        <xs:any namespace=3D"##other" processContents=3D"strict"/> =

      </xs:choice> =

    </xs:complexType> =

    =

    In conjunction with use of elementFormDefault=3D"unqualified", =

    that unfortunately leads to a non-deterministic content model, =

    as DeviceId is not actually in the target namespace. =


    One possible fix is to move away from =

    elementFormDefault=3D"unqualified".  (PSKC uses "qualified" =

    anyway.) =


adoherty>>We now rely on elementFormDefault=3D"qualified".

- StatusCode is one out of a closed list of strings. For =

  extensibility, it might be worth using URIs/URNs instead of text =

  strings here, and defining StatusCode to be of type anyURI. =


adoherty>>We decided on a closed list for interoperability purposes.

- Same for PlatformType. =


adoherty>>Same as for StatusCode

- ProtocolVariantsType uses elements to identify supported protocol =

  variants.  I wonder if having an extension point in the schema for =

  future variants might be useful.  Also, why not use an URI-based =

  extensibility pattern? =


adoherty>>Future variants are unlikely.  In any case, we chose not to do th=
is for interoperability purposes.

- In 11.3.3, ds:KeyInfoType is used for Payloads, and "only those =

  choices of the ds:KeyInfoType that identify a symmetric key are =

  allowed".  Does a ds:RetrievalMethod that points to a ds:KeyName =

  elsewhere possibly identify a symmetric key?  Please be clearer =

  about which parts of ds:KeyInfo you use here. =


adoherty>>TBS
  =

- Same in 11.2.3 for public keys. =


adoherty>>TBS

- IdentifierType is limited to a maximum 128 characters in the =

  schema, yet that limitation is nowhere found in the normative =

  text. =


adoherty>>Maximum length added to text.

- PSKC uses strings for algorithm identifiers, DSKPP uses URIs.  Why =

  the inconsistency?  (I'd prefer URIs, for consistency with XML =

  Signature, XML Encryption, and neighboring specs.) =


adoherty>>This was resolved in latest draft. At IETF-70 KEYPROV meeting, gr=
oup decided to go with URL's instead of URI's.

- In section 6.2.2, the normative text defines <SupportedKeyTypes>, =

  <SupportedEncryptionAlgorithms>, <SupportedMacAlgorithms>, =

  <Supported KeyContainers> as "a series of URIs..." -- that's =

  actually not true, as each of these elements includes a sequence =

  of container elements that in turn contain the URIs.  Please be =

  precise when describing XML structures. =


adoherty>>Change made.

- In section 6.2.2.2, the text about 4 and 2 pass DSKPP seems =

  confused: =

  =

        If the ProtocolVariantsType is not used, then the DSKPP =

        server will proceed with ordinary 4-pass DSKPP.  However, =

        it does not support 4-pass DSKPP, then the server MUST =

        find a suitable two-pass variant or else the protocol run =

        will fail. =

               =

  I believe it's supposed to say "if no protocol variants are =

  indicated, then the server will proceed with ordinary 4 pass, or =

  maybe with 2 pass", or something like that.  Please phrase this =

  more clearly. =


  (Incidentally, what does it mean that the *type* is not used?) =


adoherty>>Good catch! Change made.

- In 6.2.2.4, "An AuthenticationCode MAY or MAY NOT contain =

  alphanumeric characters.." -- excuse me? =


- same section, "A DSKPP client MAY contain Authentication Data =

  consisting of signed data of client Nonce with a client =

  certificate's private key." I believe this is supposed to describe =

  a public key signature of the client Nonce. =


adoherty>>This option was removed.

- same section, "The element of ... have the following meaning" -- =

  make that "elements" =


adoherty>>Done

- same section, a lot of discussion that "certificate itself is =

  typically sufficient"; "DeviceID, KeyID, and/or nonce provided in =

  the <InitializationTriggerType> element ougth to be sufficient to =

  identify the requester".  What's probably meant is that ClientID =

  can be omitted if the requester can be identified otherwise.  If =

  so, please say that. =


adoherty>>Change made; affected the section on AuthenticationDataType Type.

- The security considerations are somewhat inconsistent in their =

  attacker model.  In some cases, a man in the middle is assumed to =

  have the capability to bypass TLS protection (e.g., 14.2.2); in =

  other sections transport security is presented as a solution to =

  concerns about the integrity of protocol exchanges (e.g., 14.2.4). =


  It would contribute to the clarity of the security considerations =

  if there was a clear discussion of the assumptions beforehand, and =

  a consistent use of attacker models later on. =


adoherty>>TBS

- While I've not worked this through fully, it appears that an =

  active attacker can manipulate the SupportedKeyTypes and KeyType =

  elements in the ClientHello and KeyProvServerHello messages, =

  without the protocol failing, if both device and server support =

  multiple key types with mutually interchangeable key material. =

  That might lead to an inconsistent state, or possibly to the use =

  of weak keys.  It might be useful to use the negotiated algorithm =

  value as input into the MAC derivation mechanism. =


adoherty>>TBS

- Finally, on yet another editorial note, the namespace in the =

  schema and the one in the IANA considerations section are =

  inconsistent. =


adoherty>>This was fixed.

Regards, =

-- =

Thomas Roessler, W3C  <tlr@w3.org> =


_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
http://www.ietf.org/mailman/listinfo/apps-review