A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
draft-ietf-kitten-sasl-openid-08

[Ballot discuss]
Hiya!

1) s2 contains the following:

4. 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.

If the association is an encrypted channel how is it used to sign subsequent messages? I think this is an HMAC and it ain't a signing operation. r/sign/mac and r/signature/mac.

Then again didn't Elliot offer some text in response to the secdir review that's even more specific?

2) s3.1: It's unclear to me that the changes suggested during the secdir review have been incorporated in to s3.1.  I think that Simon & Steve agreed to remove the following from s3.1:

  The GS2 header carries the optional authorization identity.

and make the last paragraph:

  The syntax and semantics of the "gs2-header" is specified in
  [RFC5801], and we use it here with the following limitations.  The
  "gs2-nonstd-flag" MUST NOT be present.  The "gs2-cb- flag" MUST be
  "n" because channel binding is not supported by this mechanism.

(i.e., removing the last sentence)

but then Jeff came back with another suggestion.  Just want to make sure this gets properly resolved.

3) This one I got from Alexey OpenID specifies the use of Base64 but it doesn't say which alphabet is to be used. Must this document specify which alphabet is used?

[Ballot discuss]
[Updated 2012-02-27 to reflect closure on issue #1. There are still some topics I'd like to chat about...]

[1. Addressed via discussion with the AppsDir reviewer.]

2. Section 2 states:

        OpenID defines two methods
        for indirect communication, namely HTTP redirects and HTML form
        submission.  Both mechanisms are not directly applicable for
        usage with SASL.

Why are these mechanisms not applicable? Because the SASL client here might not contain or be able to invoke a full browser? Because the SASL server can't handle HTTP redirects or HTML forms? For some other reason? (A forward reference to Section 2.2 might be useful, if appropriate.)

The same paragraph goes on to state:

        To ensure that a standard OpenID 2.0 capable
        OP can be used a new method is defined in this document that
        requires the OpenID message content to be encoded using a
        Universal Resource Idenitifier (URI).

How will a standard OpenID Provider be able to use a new mechanism?

Are there security concerns with encoding the message in a URI (e.g., inclusion of credentials or transaction-ids or other sensitive data, given that URIs might leak out of a secure context)?

[Ballot discuss]
[Updated with a second topic of conversation.]

1. The Apps Area Review by William Mills on 28-Nov-2011 raised
  three major technical issues and two minor technical issues.
  These issues merit a response.  The review was sent to the
  KITTEN WG list and can be found here:
 
  http://www.ietf.org/mail-archive/web/kitten/current/msg02858.html

2. Section 2 states:

        OpenID defines two methods
        for indirect communication, namely HTTP redirects and HTML form
        submission.  Both mechanisms are not directly applicable for
        usage with SASL.

Why are these mechanisms not applicable? Because the SASL client here might not contain or be able to invoke a full browser? Because the SASL server can't handle HTTP redirects or HTML forms? For some other reason? (A forward reference to Section 2.2 might be useful, if appropriate.)

The same paragraph goes on to state:

        To ensure that a standard OpenID 2.0 capable
        OP can be used a new method is defined in this document that
        requires the OpenID message content to be encoded using a
        Universal Resource Idenitifier (URI).

How will a standard OpenID Provider be able to use a new mechanism?

Are there security concerns with encoding the message in a URI (e.g., inclusion of credentials or transaction-ids or other sensitive data, given that URIs might leak out of a secure context)?

[Ballot discuss]
The Apps Area Review by William Mills on 28-Nov-2011 raised
  three major technical issues and two minor technical issues.
  These issues merit a response.  The review was sent to the
  KITTEN WG list and can be found here:
 
  http://www.ietf.org/mail-archive/web/kitten/current/msg02858.html

[Ballot comment]
The Gen-ART Review by Brian Carpenter on 24-Nov-2011 includes a
  request for better clarity.  Please consider this comment.

  > 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 ensure that the
  >    authentication can be completed.

  This language remains rather loose. At least, I believe, "fancy" and
  "fairly rich" need to be replaced by more specific terms such as
  "complex" and "sufficiently powerful" respectively. I think there may
  be interoperability issues hidden here in any case, but that is
  probably inevitable.

[Ballot discuss]
Hiya!

1) s2 contains the following:

4. 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.

If the association is an encrypted channel how is it used to sign subsequent messages? I think this is an HMAC and it ain't a signing operation. r/sign/mac and r/signature/mac.

Then again didn't Elliot offer some text in response to the secdir review that's even more specific?

2) s3.1: It's unclear to me that the changes suggested during the secdir review have been incorporated in to s3.1.  I think that Simon & Steve agreed to remove the following from s3.1:

  The GS2 header carries the optional authorization identity.

and make the last paragraph:

  The syntax and semantics of the "gs2-header" is specified in
  [RFC5801], and we use it here with the following limitations.  The
  "gs2-nonstd-flag" MUST NOT be present.  The "gs2-cb- flag" MUST be
  "n" because channel binding is not supported by this mechanism.

(i.e., removing the last sentence)

but then Jeff came back with another suggestion.  Just want to make sure this gets properly resolved.

3) This one I got from Alexey OpenID specifies the use of Base64 but it doesn't say which alphabet is to be used. Must this document specify which alphabet is used?

[Ballot comment]
1) It would be nice if the Figure showed that the RP is the SASL server. You use RP and SASL server and you use client and SASL client and it would be really nice if you just picked one set of terms and used it consistently in the steps in s2. For a split second step 1 made me ponder whether a fourth box was needed in the Figure.

2) It would be nice if it said to whom the response is sent in the following:

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

3) In the following I assume it's the OP who approves/disapproves the authentication:

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

so maybe:

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

4) Instead of should be expected to respond in the following:

10. 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.

maybe just: "should respond"?

[Ballot discuss]
Hiya!

1) s2 contains the following:

4. 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.

If the association is an encrypted channel how is it used to sign subsequent messages? I think this is an HMAC and it ain't a signing operation. r/sign/mac and r/signature/mac

2) This one I got from Alexey OpenID specifies the use of Base64 but it doesn't say which alphabet is to be used. Must this document specify which alphabet is used?

Just pasting in the proto write up here since I only seem to have had
it in mail otherwise.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Alexey Melnikov is the document shepherd.  I have reviewed this version,
and am satisfied that it's ready.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document has adequate reviews from the Kitten WG

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

I have no concerns.
It might be worth requesting an Apps Area review to double check HTTP
aspects of the proposal.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

I have no concerns.  There is no IPR involved.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There is consensus of the working group to publish the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

I have verified it with idnits version 2.12.12.
There is one obsoleted reference:
-- Obsolete informational reference (is this intentional?): RFC 3920
  (Obsoleted by RFC 6120)

which can be updated by the RFC Editor.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

All references are properly split.
There are 2 normative references to non-IETF documents: an OpenID
document and an OASIS document. These are intentional and should be fine.

There are no references to drafts or documents at lower maturity level.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section exists and looks correct (it registers a
new SASL mechanism name and an OID).

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

ABNF was verified with BAP.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

  Technical Summary
      Relevant content can frequently be found in the abstract
      and/or introduction of the document. If not, this may be
      an indication that there are deficiencies in the abstract
      or introduction.


OpenID has found its usage on the Internet for Web Single Sign-On.
Simple Authentication and Security Layer (SASL, RFC 4422) and the Generic Security Service Application Program Interface (GSS-API, RFC 2743) are application frameworks to generalize authentication for connection based protocols.  This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API.

  Working Group Summary
      Was there anything in WG process that is worth noting? For
      example, was there controversy about particular points or
      were there decisions where the consensus was particularly
      rough?

Nothing worth noting, this document was relatively non controversial
once the rough consensus was reached in the WG that using a browser
for some part of SASL authentication is acceptable for some deployments.

  Document Quality
      Are there existing implementations of the protocol? Have a
      significant number of vendors indicated their plan to
      implement the specification? Are there any reviewers that
      merit special mention as having done a thorough review,
      e.g., one that resulted in important changes or a
      conclusion that the document had no substantive issues? If
      there was a MIB Doctor, Media Type or other expert review,
      what was its course (briefly)? In the case of a Media Type
      review, on what date was the request posted?

At least one implementation is in progress and one is planned.

IANA understands that, upon approval of this document, there are two
actions which must be completed.

First, in the Simple Authentication and Security Layer (SASL) Mechanisms
located at:

http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml

a new SASL Mechanism will be registered as follows:

Mechanism: OPENID20
Usage: Common
Reference: [ RFC-to-be ]
Owner: IESG

Second, in the Sub-registry: SMI Security for Mechanism Codes in the
Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

the value already pre-assigned:
Decimal Name Description
16 openID20 OpenID 2.0 mechanism

will be made permanent with a revised reference of [ RFC-to-be ].

IANA understands that these two actions are the only ones that need to
be completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A SASL & GSS-API Mechanism for OpenID) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'A SASL & GSS-API Mechanism for OpenID'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  OpenID has found its usage on the Internet for Web Single Sign-On.
  Simple Authentication and Security Layer (SASL) and the Generic
  Security Service Application Program Interface (GSS-API) are
  application frameworks to generalize authentication.  This memo
  specifies a SASL and GSS-API mechanism for OpenID that allows the
  integration of existing OpenID Identity Providers with applications
  using SASL and GSS-API.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/


No IPR declarations have been submitted directly on this I-D.