Re: [apps-discuss] [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07

William Mills <> Thu, 01 December 2011 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78C7C21F912D for <>; Thu, 1 Dec 2011 08:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.298
X-Spam-Status: No, score=-17.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cgi-jnFnhUCw for <>; Thu, 1 Dec 2011 08:36:35 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 25DB011E8231 for <>; Thu, 1 Dec 2011 08:36:17 -0800 (PST)
Received: from [] by with NNFMP; 01 Dec 2011 16:36:14 -0000
Received: from [] by with NNFMP; 01 Dec 2011 16:36:14 -0000
Received: from [] by with NNFMP; 01 Dec 2011 16:36:14 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 98946 invoked by uid 60001); 1 Dec 2011 16:36:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1322757373; bh=CuKY1Y0Wtx36D8p0b8+SEvXb6DHTvWFgOji9AUGGUwI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aaxyGwttkRVcT3gGj1eVH5SYadMdB1xl8y3xAdB9ZikDf0bW9mX9yEuFxClFRB/jNw464desDQMI5F33xzF8nkQWqE3GNSMsk5d49jsjXuakGHH/Jn/W565Lj3fmFauQp7hAF10gL6ZNGUqB+hLEi9MkDMxvNfnNMnkT18mYmrs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MyMqvxvjlqqbHkdIk47iVj2qTAJKKsDIj5Uct8xYtYUhW7OfQ10zy38Nz7fAvDd0+KZPoFqr1bwEzCjs6sxIfzrIfiAYgs5XT4nnCpgdZetlECixUfWwuX9Q3cUqRz0wwGd6kQjOspJMIe/UHowTreVy9tIPg4/AsD4FfHHPgNw=;
X-YMail-OSG: 7yU1PX0VM1nQMlLYTeUFCikj_dNT3ofW2KyOsQ9W86G6K0Z BceIrsfkHZsivHiShmnwIpUQXiWkOVPjv6lLziHT3l4Sp7gJcV1OHW0KRSNQ WGoAFPajw6UPeghza3vOQc7EEkE62Ghs.uxWlidNIFRil156wNWXwUCqg2mk oJthMPv7woezrQ84D5ljQ3XHCjH1ZPy050hpXZv3MrcDmGUst0RLpnkAIOtj 4dXLnS_ExMW2JrfC0iFn9wrr97gGX_c4_uEUOAE34O11HSaevKrMpxciiJ_c .yqr_4VIqIml0qJkWnR_izbDtj9C7XCfLy1IGe5xw3D8HIqssTvmwmPV3SQ1 ApiUx6ZOkX_ZRpHu0NZv3K_gv8bBtO0cqD3IVVSOjgHTrKGqbduGFz16BLg_ _FqYeIqWVc4HfUQ--
Received: from [] by via HTTP; Thu, 01 Dec 2011 08:36:13 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Thu, 01 Dec 2011 08:36:13 -0800
From: William Mills <>
To: William Mills <>, "" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-1173862516-1322757373=:30894"
Cc: "" <>, "" <>
Subject: Re: [apps-discuss] [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2011 16:36:36 -0000

I should have put a disclaimer in the review.  My weakest subject in this review is the GSS-API bridge, it looked right to me but I'm in no way authoritative there. I know Hannes and Eliot are strong there though.


 From: William Mills <>
To: "" <>; "" <> 
Cc: "" <>; "" <> 
Sent: Monday, November 28, 2011 10:24 PM
Subject: [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07
I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see 

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-kitten-sasl-openid-07
Reviewer: William J. Mills
Review Date: November 28, 2011
IETF Last Call Date:  October 25, 2011

Review Summary:

This draft is almost ready for publication as a Proposed Standard, but should address the three major issues below before proceeding.  Some minor issues and nits are also noted.

Document Summary:

This document defines a pure SASL mechanism for OpenID, but it conforms to the new bridge between SASL and the GSS-API called GS2 [RFC5801], so it defines both a SASL and a GSS-API mechanism.

Major Issues:

Section  1.2.  Applicability:  This section requires TLS but channel binding is not supported by the mechanism.  OpenID itself does not require TLS for client to relying party interactions, as integrity can be assured with a MAC signature and replayability is dealt with in the OpenID nonce.  Requiring TLS does not appear to be based on the underlying security profile of OpenID.  If TLS is ot be required channel binding should be supported.  If TLS is not required then there is the possibility of a DOS against the return_to entrypoint returned to the user, sending a false failure message.

Section 3.2 Authentication Request:  In the second full paragraph defining transaction id, the language here probably isn't strong enough.    What it says now is 

   The form of this transaction is left to the RP to decide, but 
   SHOULD be large enough to be resistant to being guessed or attacked.

(Nit: At the very least "transaction" needs to be "transaction id") I think it would be better if the current text is replaced with

   The form of this transaction id is left to the implementer, but it
   MUST be resistant to being guessed or attacked.

I think MUST is justified here because the RP is possibly open to a DOS if the value is guessable.  A paragraph in the security considerations section might be warranted to talk about how to pick good unguessable values, although this has been done many times in many different specs.  Side comment: maybe we need an RFC just for this and then everyone can cite it.

3.3.  Server Response

The problem I see here is that the result sent to the server that is "used to set state in the server accordingly" is not guaranteed to provide a username  that will be useful to the SASL endpoint.  The RP might get a full email address, or might get a bare username.  In the case of an IMAP server supporting multiple domains this may be significant.  The spec really should define how the SASL identities are determined from the response from the OP.

It's possible that this could be solved by moving 6.1 and making it 3.3.1.  Identity mapping seems to fit better here than in security considerations.

Minor issues:

User confusion on names: The problem I see is one of confusion for the user of an OpenID enabled SASL client for Mail.  Some endpoint will need to be given usrename, some will be given an dOpenID endpoint.  Clarifying language might be useful to guide the client implementer.  Is there a disocvery method that the client can use ot go from a username/domain to the OpenID endpoint ot send to the RP?

More examples:  I'd prefer to see an example of a failure flow included.  I tend to like examples though, and find them helpful in parsing the normative text.

3.3.  Server Response & 3.4.  Error Handling & 5. Example

There's an inconsistency here I think could be better.  In the Exmaple we have a success case where the client returns and empty client message in order to prompt the server to finalize the SASL negotiation.  In the error handling case we have an explicit continuation from the client sending "=".   Is the "=" sign after the error return actually required or can this simply be an empty client message.  This means if the client knows the negotiation is complete and has not gotten a result it just always sends the empty message.


Section 1, 4th para, first sentence:  I would change "As currently envisioned, this mechanism is to allow" to "This mechanism allows".

Section 1, 5th para, 2nd sentence: "will continued to be" change continued to continue.
Kitten mailing list