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

William Mills <wmills@yahoo-inc.com> Tue, 29 November 2011 06:24 UTC

Return-Path: <wmills@yahoo-inc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475611E809A for <apps-discuss@ietfa.amsl.com>; Mon, 28 Nov 2011 22:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.392
X-Spam-Level:
X-Spam-Status: No, score=-16.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V1QEpoupmrn for <apps-discuss@ietfa.amsl.com>; Mon, 28 Nov 2011 22:24:54 -0800 (PST)
Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 8977621F8B6D for <apps-discuss@ietf.org>; Mon, 28 Nov 2011 22:24:54 -0800 (PST)
Received: from [98.139.91.65] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [98.139.91.57] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 29 Nov 2011 06:24:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 860996.96753.bm@omp1057.mail.sp2.yahoo.com
Received: (qmail 26413 invoked by uid 60001); 29 Nov 2011 06:24:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322547891; bh=NNkHqIZGSr14NpbQ7g1UMCG/5GgGEXftkQraqomPZ+0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BGzQR4JEoRclMU34nBM8NRSeIcf/1ziI3m1t4NKyORqFQ/2Q6yDNgpLb1gZzf/GLk4DrS6+/BqWY/bonVpV6FJJISDHUKdDiRFPesk/qt6rpMEGwVe+3FXm8zXCSUCNi0TaDxFM2s0JBqdIRkILTsoddHfHDiKgYPgwyiS3DaMo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nx/Kffth5avxdJsmMyr+VKofeEBmvSnvj66TCah7scFGKHbQ9b7lCYT8PBUioLNi0eYHfjiS8sK5NKsSQlVzTLx1waSq3uWfekgo4TiFoHTZI9ZXNVIZd6zF43+C+7XPPOZar0Hmqp3mij7MgBKhCK9HxLqof0FNFfWxWIqd9sM=;
X-YMail-OSG: oAfbI.EVM1l9LOQRTNENR97qWFXKO58mX2NX43bpfbivd_J 1r5IgT5zyRYVkOLD20qB9UMSKGGJCeDfSRV4U8jO73gdEtUXPCI1m3PhNj0c FgAjntANwKJ8uQLG8MWMbNnhdO0JWMbPvaFwKKuMJiPGPHoKJlEgVK4PjRTv MSfdISIKV9rzn04yjYzBH7dEdrPN35KIfnXpBXMBAIvU9QrMpfq6ziK5dhts SZNVyuEBoevz6tntPqB5VhEHzKGUpYd6Y6L3RVMH_HYcdK.WojE3ropQ0e2j o1AhsjVRXFI_ztYHIAfZZt5hYxmlehIHlI3ESt_PPsZ9vj6ZEknZIwko2CJh gAJpEqvUoGd6bCxkhgoGw2WZKcNmpQNajI8YLRDplQNNAbaWnrnjEIr7kMcz s.akoGvGyYSxN3b5W9BdiVwIjbtoAcT9KM0yTVlXzSSMD_VJY4Jje.kFhXBK AI5BieRavDY4Y0CK2XiXzz7ar1Spo2zJAY5DWFGBmN3BPtqb.lZPVZF8TiQS yDfv_A6A-
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2011 22:24:51 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
Message-ID: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 28 Nov 2011 22:24:51 -0800 (PST)
From: William Mills <wmills@yahoo-inc.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" <draft-ietf-kitten-sasl-openid.all@tools.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" <kitten@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2011 06:24:55 -0000

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). 

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.


Nits:

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.