During the WGLC, below email has the comments received for the SPP Protocol over SOAP document. My proposed resolution to these comments is prefixed with "[VB:]" below. Also attached is the updated draft (version 3, but off course not yet officially released) with these comments addressed. As part of addressing these comments, I also cleaned up some text in section 11 and 11.1 (in the attached document) for better clarity.

Please let me know if any comments.

Thanks,
Vikas

-----Original Message-----
From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Monday, September 10, 2012 10:47 PM
To: drinks@ietf.org
Subject: [drinks] Review of draft-ietf-drinks-spp-protocol-over-soap-02



In 7.1.2 Public Identity Object Key

we have:

   It is MUST that only one of the "number", "range", and "uri" elements
   appears in a PubIdKeyType instance

This might be better worded as:

    Any instance of PubIdKeyType MUST contain exactly one element from the following set of elements: "number", "range", "uri".
[VB:] I am ok with your modified sentence above.

Section 11: Security Considerations makes TLS a SHOULD, and 11.1 makes it a MUST IMPLEMENT. Didn't we agree to a MUST USE? Note that 11.3 allows non-encryption ... it's weasely.

11.1 discusses authentication alternatves, but doesn't section 5 mandate Digest?


Section 5 says:

5.  Authentication and Session Management

   To achieve integrity and privacy, conforming SPP Protocol SOAP
   Clients and Servers MUST support SOAP over HTTP over TLS [RFC5246] as
   the secure transport mechanism.  This combination of HTTP and TLS is
   referred to as HTTPS.  And to accomplish authentication, conforming
   SOAP SPPF Clients and Servers MUST use HTTP Digest Authentication as
   defined in [RFC2617].  As a result, the communication session is
   established through the initial HTTP connection setup, the digest
   authentication, and the TLS handshake.  When the HTTP connection is
   broken down, the communication session ends.


but 11.1 says:

11.1.  Integrity, Privacy, and Authentication

   The SPP Protocol over SOAP binding relies on an underlying secure
   transport for integrity and privacy.  Such transports are expected to
   include TLS/HTTPS.  In addition to the application level
   authentication imposed by an SPPF server, there are a number of
   options for authentication within the transport layer and the
   messaging envelope.  These include TLS client certificates, HTTP
   Digest Access Authentication, and digital signatures within SOAP
   headers.

   At a minimum, all conforming SPP Protocol over SOAP implementations
   MUST support HTTPS.


[VB:]
Yeah, agree that these sections need to be made consistent w.r.t the use of TLS. We did decide to make TLS a MUST. Keeping that in mind, below is what I propose.

1. Remove section 11.3 ("Deployment Environment Specifics") since I don't see any significance of that section (since we are making TLS a MUST).

2. Section 5 and 11.1 are talking similar information in a bit confusing way. The authentication (HTTP digest) and confidentiality (use of HTTP with TLS) better fit together in one paragraph in my opinion. So, to address your comment and improve clarity, I am proposing to remove section 11.1 and we merge these two sections in to section 5 with some simplified text:

==========Proposed paragraph================================================================================
 5. Authentication, Integrity and Confidentiality

   To accomplish authentication, conforming SPP Protocol over SOAP Clients and Servers MUST use HTTP Digest Authentication as
   defined in [RFC2617] as the authentication mechanism.

   To achieve integrity and privacy, conforming SPP Protocol over SOAP Clients and Servers MUST support Transport
   Layer Security (TLS) as defined in [RFC5246] as the secure transport mechanism.

=========End Proposed paragraph========================================================================================

Notice that I removed the text in section 5  that starts with " As a result, the communication session is...". I think that is just obvious, given protocol mandates HTTP Digest and HTTPS.

_______________________________________________
drinks mailing list
drinks@ietf.org
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.