Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-openid-01

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Apr 2011 21:18:20 +0100

Shawn Emery wrote:

> This message officially starts the Kitten Working Group Last Call for 
> the following document:
>
> A SASL & GSS-API Mechanism for OpenID
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-01
>
> The Working Group Last Call for this document starts today on 
> Wednesday, March 9th and will end on Wednesday, March 30th.
>
> Please send any comments to the Kitten mailing list or directly to the 
> chairs.  Feed-back from reviews that found no issues are also welcome.

Here is my belated review:

In this review I pretend to be a be more dumb than I am in real life 
(hopefully ;-)).
I mean, I can probably figure out some details by reading OpenID 2.0, 
but this
draft is not making it easier. I think each document should be as 
readable as it
can possibly be on its own.

With that in mind, here are my detailed comments:

1.  Introduction

   Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is
   used by application protocols such IMAP, POP and XMPP, with the goal

Strictly speaking all of these need Informative references.

   of modularizing authentication and security layers, so that newer
   mechanisms can be added as needed.  This memo specifies just such a
   mechanism.

   The OpenID mechanism described in this memo aims to re-use the
   available OpenID specification to a maximum extent and therefore does
   not establish a separate authentication, integrity and
   confidentiality mechanism.  It is anticipated that existing security
   layers, such as Transport Layer Security (TLS), will continued to be

An Informative reference is missing here.

   used.

1.2.  Applicability

   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 [RFC5246], and the client MUST
   successfully validate the server certificate, or similar integrity

Are references to RFC 5280 and RFC 6125 missing here?

   protected and authenticated channels.

2.  Applicability for non-HTTP Use Cases

   OpenID was originally envisioned for HTTP/HTML based communications,

Informative references are missing.

Is any specific version of HTML required here?

   2.   The client initiates a SASL authentiation and transmits the

typo: authentication

        User-Supplied Identifier as well as an optional return_to
        parameter.

 From the description later in the document, the return_to parameter is only
generated by the server. So I think something is wrong in the document 
(either here, or elsewhere).

   3.   After normalizing the User-Supplied Identifier,

How?

        the Relying
        Party performs discovery on it and establishes the OP Endpoint
        URL that the end user uses for authentication.

   4.   The Relying Party and the OP optionally establish an association
        -- a shared secret established using Diffie-Hellman Key
        Exchange.

Where is this described normatively? The text seems fairly informative.

        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.

   8.   Next the client optionally authenticates to the OP and then
        approves or disapproves authentication to the Relying Party.
        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.  This step happens out of band from SASL.

Hmm, this suggests that one can't implement this mechanism interoperably
on the client side. I think this is a problem.

        ----- = SASL
        - - - = HTTP or SSL

Did you mean "HTTP over TLS"? (Avoiding a use of the term "SSL", as SSL 2.0
is deprecated and 3.0 might follow the same path.)

2.1.  Binding SASL to OpenID in the Relying Party

   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 in the URIs it transmits through the
   client for success or failure.  This can be done in any number of
   ways.

Isn't this necessary to implement?

   Examples would include making changes to the base URI or
   otherwise including an additional fragment.

Can you provide expanded examples?

2.2.  Discussion

   As mentioned above OpenID is primarily designed to interact with web-
   based applications.  Portions of the authentication stream are only
   defined in the crudest sense.  That is, when one is prompted to
   approve or disapprove an authentication, anything that one might find
   on a browser is allowed, including JavaScript, fancy style-sheets,
   etc.  Because of this lack of structure, implementations will need to
   invoke a fairly rich browser in order to insure that the
   authentication can be completed.

This is not well defined. I have doubts that that is implementable
without invoking a browser. If that was never the intent, I think a clear
applicability statement upfront is needed.

I also have a more general issue with this: are you saying that this 
mechanism
is only implementable by invoking one of the 5 major (and some number of 
less
deployed) browsers? Are certain features required from a browser being 
invoked?

3.2.  Initiation

       initial-response = gs2-header Auth-Identifier
       Auth-Identifier = Identifier ; authentication identifier
       Identifier = URI | XRI      ;  Identifer is specified in

typo: Identifier (in the comment)

                                   ;  Sec. 7.2 of the OpenID 2.0 spec.

ABNF should be using "/", not "|" to delimit alternatives.

3.3.  Authentication Request

   The SASL Server sends an OpenID message that contains an openid.mode
   of either "checkid_immediate" or "checkid_setup", as specified in
   Section 9.1 of the OpenID 2.0 specification.

   As part of this request, the SASL server MUST append a unique
   transaction id to the &quote;return_to" portion of the request.  The

Typo in the source XML ("&quote;")?

   The client now sends that request via an HTTP GET to the OP, as if
   redirected to do so from an HTTP server.

What does such request include as far as HTTP operation is concerned?
I.e. which header fields are required? Is Referer header field required?

   The client MUST handle both user authentication to the OP and
   confirmation or rejection of the authentiation of the RP.

Is this process fully prescribed by the OpenID spec?

   After all authentication has been completed by the OP, and after the
   response has been sent to the client, the client will relay the
   response to the Relying Party via HTTP or SSL.

HTTP and SSL are not interchangeable, so I don't know what this means.

Also, I am a bit confused at this point: what is the corresponding section 2
step number for this operation? If this is the step 9, then I don't 
understand
why the client is involved in this at all? Figure 1 doesn't seem to show
this interaction path.

3.4.  Server Response

         sreg_word    = 1* ( unreserved / pct-encoded )
                        ; pct-encoded from Section 2.1 of RFC 3896
                        ; unreserved from Section 2.3 of RFC 3896

s/3896/3986 (twice)

   If the application protocol allows, openid.error and
   openid.error_code and any other useful diagnostic information SHOULD
   be included in authentication failures.

Why wouldn't it allow? (This doesn't read normative and I think it should.)

In Section 5:

 IMAP and SASL-IR need Informative references.

6.2.  RP redirected by malicious URL to take an improper action

   In the initial SASL client response a user or host can transmit a
   malicious response to the RP for purposes of taking advantage of
   weaknesses in the RP's OpenID implementation.  It is possible to add
   port numbers to the URL so that the outcome is the RP does a port
   scan of the site.  The URL could send the connection to an internal
   host or even the local host, which the attacker would not normally
   have access to.  The URL could contain a protocol other than http or
   https, such as file or ftp.

Should HTTP/HTTPS be mandatory to implement URI schemes for such responses?

7.  Room for Improvement

   We note one area where there is possible room for improvement over
   existing OpenID implementations.  Because SASL is often implemented
   atop protocols that have required some amount of provisioning, it may
   be possible for the SASL client to signal the browser that it should
   increase scrutiny of invalid credentials.  How this would be done is
   beyond the scope of this specification, but may be the subject of
   future updates.  For instance, the browser may wish to fail the
   request entirely if the certificate is invalid and has not been
   accessed prior to this point.  One thing that this would require
   would be the exposure of a "return_to" URL by the SASL server in case

Exposure to which entity?

   of such failures, so that the authentication is not left hanging.

Other comments:

I am missing some text saying that a SASL authorization identity can
be used with this mechanism. This follows from the definition of the GS2
bridge, but I think it would be worth stating that explicitly.

This SASL mechanism is using 3 round trips! I am wondering if we can do 
better.
(I haven't though too much on this question, so maybe the answer is "no")

Best Regards,
Alexey

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 Apr 2011 14:09:05 +0200

Alexey,

> Strictly speaking all of these need Informative references.

Added.
> An Informative reference is missing here.

Added.
> Are references to RFC 5280 and RFC 6125 missing here?

Added.
> Informative references are missing.

Added.
> Is any specific version of HTML required here?

4.01.  Added.

>   2.   The client initiates a SASL authentiation and transmits the
Fixed.

>   3.   After normalizing the User-Supplied Identifier,

Added reference to OpenID spec (and section).

> Where is this described normatively? The text seems fairly informative.

Added reference to OpenID spec and section.

> on the client side. I think this is a problem.

This is the nature of federated authentication through the web.  How the
IdP/OP authenticates the user (and visa versa) is passed by OpenID to
control of the OP for all intents and purposes.
> is deprecated and 3.0 might follow the same path.)

Changed to HTTP or HTTPS.

> Isn't this necessary to implement?

Yes, and it is described below.

> Can you provide expanded examples?

There is an example included.

> applicability statement upfront is needed.

Added.

> is only implementable by invoking one of the 5 major (and some number
> of less

Fixed.

> ABNF should be using "/", not "|" to delimit alternatives.

Fixed.

> Typo in the source XML ("&quote;")?

Fixed.

> I.e. which header fields are required? Is Referer header field required?

No specific header fields are required, and no referrer is required.

> Is this process fully prescribed by the OpenID spec?

Yes.

> HTTP and SSL are not interchangeable, so I don't know what this means.

Changed to HTTPS (meant to encompass current forms of communication). 
Also added specific normative recommendation to clarify which URIs
should be allowed.

> why the client is involved in this at all? Figure 1 doesn't seem to show

Extraneous text removed.

>                        ; unreserved from Section 2.3 of RFC 3896

Fixed (twice).

> Why wouldn't it allow? (This doesn't read normative and I think it

This issue remains opened for now.  There is no specific means to
communicate additional information as part of SASL.  That doesn't mean
people don't, but it's not there in the libsasl.a or in dovecot, and so
IMHO making it mandatory would be a bit excessive.

> IMAP and SASL-IR need Informative references.

Added.

> Should HTTP/HTTPS be mandatory to implement URI schemes for such

Yes.  Added in security considerations.

> Exposure to which entity?

This text has been rewritten.  There was room for improvement.

> This SASL mechanism is using 3 round trips! I am wondering if we can
> do better.

Nature of the beast.  Control needs to pass to the SASL server to
indicate success or failure, but the actual transaction continues
through the browser with information that the server itself had to provide.

Assuming people are comfortable with the above, if we can close the one
open issue on diagnostics, then I'll publish an updated draft.

Eliot