Subject: [kitten] Nits in draft-ietf-kitten-sasl-openid-06

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Oct 2011 10:12:34 +0200

I just re-read http://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-06 and noticed a few nits. Since the draft is currently in IESG evaluation it is not a good time to update it and hence I will post the nits to the list so that they do not get forgotten. 

FROM:

Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is used by application protocols such IMAP [RFC3501], POP [RFC1939] and XMPP [RFC3920], with the goal of modularizing authentication and security layers, so that newer mechanisms can be added as needed.

TO:

The Simple Authentication and Security Layer (SASL) [RFC4422] is used by application layer protocols, such as IMAP [RFC3501], POP [RFC1939] and XMPP [RFC3920], with the goal of modularizing authentication and security layers, so that newer mechanisms can be added as needed.

Reason: IMHO this is better English (but what do I know). 

FROM:

   Because this mechanism transports information that should not be
   controlled by an attacker, the OpenID mechanism MUST only be used
   over channels protected by TLS, and the client MUST successfully
   validate the server certificate, or similar integrity protected and
   authenticated channels.  [RFC5280][RFC6125]

TO:

  The OpenID mechanism MUST only be used
   over channels protected by TLS, and the client MUST successfully
   validate the server certificate, or similar integrity protected and
   authenticated channels. 

Reason: The first part of the sentence does not make a lot of sense to me. 
The references also appear here a bit out of the blue. 

FROM:

   When considering this flow in the context of SASL, we note that while
   the RP and the client both need to change their code to implement
   this SASL mechanism, it is a design constraint that the OP behavior
   remain untouched, in order for implementations to interoperate with
   existing IdPs. 

TO:

   When considering this flow in the context of SASL, we note that while
   the RP and the client both need to change their code to implement
   this SASL mechanism, it is a design constraint that the OP behavior
   **remains** untouched, in order for implementations to interoperate with
   existing IdPs. 

FROM:

However, it
   may be necessary for a SASL client to invoke to another application.

TO:

However, it
   may be necessary for a SASL client to invoke **WHAT** to another application.

[Hannes: There is something missing in my opinion.] 

FROM:

The SASL mechanism is client-first, and as explained in [RFC4422] the server will send an empty challenge if needed.

TO:

The SASL mechanism is client-first and, as explained in [RFC4422], the server will send an empty challenge, if needed.

FROM:

After normalizing the User-Supplied Identifier as discussed in [OpenID], the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication.

TO:

After normalizing the User-Supplied Identifier, as discussed in [OpenID], the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user utilizes for authentication.

FROM:

The Relying Party and the OP optionally establish an association
        -- a shared secret established using Diffie-Hellman Key
        Exchange. The OP uses an association to sign subsequent
        messages and the Relying Party to verify those messages;
; this
        removes the need for subsequent direct requests to verify the
        signature after each authentication request/response.

TO:

The Relying Party and the OP optionally establish an association, i.e., a security association that contains a shared secret established using a Diffie-Hellman key exchange. The OP and the Relying Party use this association to cryptographically authenticate and integrity protect subsequent message exchanges. This removes the need to perform computationally expensive cryptographic operations using public key cryptography for each request/response between the OP and the Relying Party.

FROM:

The SASL client now sends an response consisting of "=", to
        indicate that authentication continues via the normal OpenID
        flow.

TO:

The SASL client now sends a response consisting of "=" to
        indicate that authentication continues via the normal OpenID
        flow.

FROM:

Next the client optionally authenticates to the OP and then
        approves or disapproves authentication to the Relying Party.

TO:

Next, the client optionally authenticates to the OP and then
        approves or disapproves authentication to the Relying Party.

FROM:

The manner in which the end user is authenticated to their
        respective OP and any policies surrounding such authentication
        is out of scope of OpenID and and hence also out of scope for
        this specification. 

TO:

The manner in which the end user is authenticated to their
        respective OP and any policies surrounding such authentication
        is out of scope of OpenID and hence also out of scope for
        this specification. 

FROM:

 The client
        transmits over HTTP/TLS the redirect of the OP result to the RP.
        This step happens out of band from SASL.

TO:

The client transmits the redirect of the OP result to the RP over HTTP/TLS . 
This step happens outside SASL.

FROM:

The RP MAY send an OpenID check_authentication request directly
        to the OP, if no association has been established, and the OP
        should be expected to respond.  Again this step happens out of
        band from SASL.

TO:

The RP MAY send an OpenID check_authentication request directly
        to the OP, if no association has been established, and the OP
        is expected to respond.  Again, this step happens outside SASL.

FROM:

The SASL server sends an appropriate SASL response to the
        client, with optional Open Simple Registry (SREG) attributes.

TO:

The SASL server sends an appropriate SASL response to the
        client, which may optionally piggyback attributes defined by the OpenID Simple Registry (SREG) extension [openid-simple-registration-extension-1_0].

I noticed that the figure in Section 2 has no caption and it also not referenced in the text either. 

FROM:

   To ensure that a specific request is bound, and in particular to ease
   interprocess communication, it may be necessary for the relying party
   to encode some sort of nonce or transaction-id in the URIs it
   transmits through the client for success or failure.

TO:

   To ensure that the OpenID exchange is bound to the SASL exchange it may be necessary for the relying party
   to encode some sort of nonce or transaction-id in the URIs it
   transmits through the client for success or failure.

Btw, I noticed that sometimes we write "relying party" and sometimes "Relying Party". 
We typically do not use capitalized "Identity Provider" terminology, which looks a bit inconsistent. 

FROM:

   Recall section 5 of [RFC4422] for what needs to be described here.

TO:

   Recall Section 5 of [RFC4422] for what needs to be described here.

FROM:

The user would input
   his Openid into his mail user agent, when he configures the account.

TO:

The user would input his OpenID into his mail user agent when he configures the account.
In our example, no association is created between the Relying Party and the OP. 

FROM:

   This section and its sub-sections and appropriate references of it
   not referenced elsewhere in this document are not required for SASL
   implementors, but this section MUST be observed to implement the GSS-
   API mechanism discussed below.

TO:

This section describes the OpenID GSS-API mechanism and is relevant only for GSS-API developers.