A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
draft-ietf-kitten-sasl-saml-09

[Ballot comment]
Thank you for addressing my comments.

As communicated by private email, I suggest the following tweaks:

Section 3.1...

OLD
  Domain name is specified in [RFC1035].  A domain name is either a
  "traditional domain name" as described in [RFC1035] or an
  "internationalized domain name" as described in [RFC5890].

NEW
  A domain name is either a "traditional domain name" as described
  in [RFC1035] or an "internationalized domain name" as described
  in [RFC5890].

Section 3.2...

OLD
  Should the client
  support Internationalized Resource Identifiers (IRIs) [RFC3987] it
  MUST first convert the IRI to a URI before transmitting it to the
  server [RFC5890].

NEW
  Should the client
  support Internationalized Resource Identifiers (IRIs) [RFC3987] it
  MUST first map the IRI to a URI before transmitting it to the
  server, as defined in Section 3.1 of [RFC3987].

[Ballot comment]
Thank you for addressing my comments.

As communicated by private email, I suggest the following tweaks:

OLD
  Domain name is specified in [RFC1035].  A domain name is either a
  "traditional domain name" as described in [RFC1035] or an
  "internationalized domain name" as described in [RFC5890].

NEW
  A domain name is either a "traditional domain name" as described
  in [RFC1035] or an "internationalized domain name" as described
  in [RFC5890].

OLD
  Should the client
  support Internationalized Resource Identifiers (IRIs) [RFC3987] it
  MUST first convert the IRI to a URI before transmitting it to the
  server [RFC5890].

NEW
  Should the client
  support Internationalized Resource Identifiers (IRIs) [RFC3987] it
  MUST first map the IRI to a URI before transmitting it to the
  server, as defined in Section 3.1 of [RFC3987].

[Ballot discuss]
The Gen-ART Review from Ben Campbell was updated on 13-Jan-2012.
  Ben provided a Gen-ART Review of -06 at Last Call, and this updated
  review covers -08.  Version -08 is considerably improved, and it
  resolved most of Ben's comments. I would like to see responses to
  these four comments;

  1) section 3.2, last paragraph:  "... needs to correlate the TCP
    session from the SASL client with the SAML authentication."

    Please elaborate on this correlation.  The author added text, but
    the new text is about correlating response with request.  The text
    that Ben mentioned was about correlating a TCP connection to a
    SAML authentication.

  2) section 4, 3rd and 4th paragraphs (paragraphs a and b) seem like
    protocol affecting differences. If so, they need elaboration, such
    as normative statements and formal definitions, or references to
    such.

    Ben did not see a response to this comment.

  3) section 5, general: The section seems to need further elaboration
    or references.

    Ben did not see a response to this comment.

  4) Also, this section compresses the interaction with the identity
    provider. Why not show the details for those steps like the others?
    (If you mean them to be out of scope, then why give as much detail
    as you do?)

    Ben did not see a response to this comment.

[Ballot comment]
f1, s2, and f2: If you're talking about the scheme isn't it HTTPS?  r/HTTPs/HTTPS

s6.1: If you're referring to 4648 then you need to specify which alphabet is to be used.

[Ballot comment]
Section 1...

s/is a modular specification that//

OLD
  As currently envisioned, this mechanism is to allow the interworking
  between SASL and SAML in order to assert identity and other
  attributes to relying parties.
NEW
  The mechanism defined in this document enables interworking
  between SASL and SAML in order to assert identity and other
  attributes to relying parties.

Question: in order for what to assert identity? An application? A client? A user?

"This specification is appropriate for use when a browser is available."
When is it not appropriate? What are its limitations?

Section 1.2...

In Section 1 we find:

  The mechanism assumes a security layer,
  such as Transport Layer Security (TLS [RFC5246]), will continue to be
  used.

However, here we find:

  "the SAML mechanism MUST only be used over channels protected by TLS"

Therefore is the "such as" in Section 1 correct? If so, then I think the
text in Section 1.2 could be reworded as follows:

  Because this mechanism transports information that should not be
  controlled by an attacker, the SAML mechanism MUST only be used over
  channels protected by TLS, or over similar integrity protected and
  authenticated channels.  In addition, when TLS is used the client
  MUST successfully validate the server certificate.

Section 2...

This is hard to read:

  2.  The Relying Party redirects the browser via an HTTP redirect (as
      described in Section 10.3 of [RFC2616]) to the Identity Provider
      (IdP) or an IdP discovery service with as parameters an
      authentication request that contains the name of resource being
      requested, a browser cookie and a return URL as specified in
      Section 3.1 of the SAML profiles 2.0 specification
      [OASIS.saml-profiles-2.0-os].

I suggest:

  2.  The Relying Party redirects the browser via an HTTP redirect (as
      described in Section 10.3 of [RFC2616]) to the Identity Provider
      (IdP) or an IdP discovery service.  When it does so, it includes
      the following parameters: (1) an authentication request that
      contains the name of resource being requested, (2) a browser
      cookie, and (3) a return URL as specified in Section 3.1 of the
      SAML profiles 2.0 specification [OASIS.saml-profiles-2.0-os].

In the paragraph following that one (bullet point 3), what does it mean
to "authorize the authentication to the Relying Party"? What entity is
the user authorizing here? The IdP?

s/Universal Resource Identifier/Uniform Resource Identifier/

This is a bit terse:

  4.  The SASL client now sends an empty response, as authentication
      continues via the normal SAML flow.

You might consider citing the following paragraph from RFC 4422:

  Where the mechanism specifies that the server is to return additional
  data to the client with a successful outcome and this field is
  unavailable or unused, the additional data is sent as a challenge
  whose response is empty.  After receiving this response, the server
  then indicates the successful outcome.

(That is, in this case the server is waiting for information it will
receive via the SAML flow before it can indicate the successful outcome.)

We might want to expand a bit on this:

  6.  Next the client authenticates to the IdP.  The manner in which
      the end user is authenticated to the IdP and any policies
      surrounding such authentication is out of scope for SAML and
      hence for this draft.  This step happens out of band from SASL.

For example, do any specifications provide guidance here (perhaps to use
basic or digest HTTP authentication)? Also, why say "client" in the first
sentence and "end user" in the second sentence? Does that difference have
meaning?

Section 3...

  The mechanism is capable of
  transferring an authorization identity (via the "gs2-header").

Does this mean that an authorization identity can be communicated only
when GS2 is used?

  The third mechanism message is from client to the server, and is the
  fixed message consisting of "=".

You might append "(i.e., an empty response)".

  The SASL server now validates the response it received from the
  client via HTTP or HTTPS, as specified in the SAML specification

That is a bit unclear -- are we assuming that the SASL exchange takes
place over HTTP? The examples (IMAP, XMPP) belie such an assumption. Or
do you mean that the SASL server (as SAML relying party) needs to make
a connection between (1) its application-specific SASL exchange with the
SASL client and (2) its HTTP-based SAML exchange with the IdP?

Section 4...

This is a bit underspecified:

  The mutual authentication property of this mechanism relies on
  successfully comparing the TLS server identity with the negotiated
  target name.  Since the TLS channel is managed by the application
  outside of the GSS-API mechanism, the mechanism itself is unable to
  confirm the name while the application is able to perform this
  comparison for the mechanism.  For this reason, applications MUST
  match the TLS server identity with the target name, as discussed in
  [RFC6125].

In particular, see Section 13.7.1.2.1 of RFC 6120 for an example of
the kind of thing you probably ought to specify.

Section 5...

At the least, citing RFC 5056 ("On the Use of Channel Bindings to Secure
Channels") seems appropriate here.

Section 6...

In the XMPP flow, I would change  to
for the error that occurs if no SAML
Authentication Request can be constructed.

Later in the flow, I would also change  to
(e.g., because the credentials are wrong).

In the XMPP flow, I think you don't need Steps 8-11. That's post-auth
stuff specific to XMPP.

The IMAP example uses "xmpp.example.com" -- I assume you might want
to change that to "imap.example.com" or "mail.example.com".

Section 8...

The registration does not include all the information requested from
the template in Section 7.1.1 of RFC 4422 (e.g., intended usage).

[Ballot discuss]
This is a valuable document and I support its publication. However, in addition to the comments provided below (some of which border on DISCUSS points), I'd like to chat about internationalization. Section 3.1 states:

  Domain name is specified in [RFC1035].

Does this technology have no support for internationalized domain names
(IDNs) as defined by RFC 5890 - RFC 5894?

[Ballot discuss]
The Gen-ART Review from Ben Campbell was updated on 13-Jan-2012.
  Ben provided a Gen-ART Review of -06 at Last Call, and this updated
  review covers -08.  Version -08 is considerably improved, and it
  resolved most of Ben's comments. I would like to see responses to
  these four comments;

  1) section 3.2, last paragraph:  "... needs to correlate the TCP
    session from the SASL client with the SAML authentication."

    Please elaborate on this correlation.  The author added text, but
    the new text is about correlating response with request.  The text
    that Ben mentioned was about correlating a TCP connection to a
    SAML authentication.

  2) section 4, 3rd and 4th paragraphs (paragraphs a and b) seem like
    protocol affecting differences. If so, they need elaboration, such
    as normative statements and formal definitions, or references to
    such.

    Ben did not see a response to this comment.

  3) section 5, general: The section seems to need further elaboration
    or references.

    Ben did not see a response to this comment.

  4) Also, this section compresses the interaction with the identity
    provider. Why not show the details for those steps like the others?
    (If you mean them to be out of scope, then why give as much detail
    as you do?)

    Ben did not see a response to this comment.

[Ballot comment]
8.2.  IANA OID

  The IANA is further requested to assign an OID for this GSS mechanism
  in the SMI numbers registry, with the prefix of
  iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
  reference this specification in the registry.



What the document is actually asking IANA is to assign a new entry in the sub-registry for SMI Security for Mechanism Codes whose prefix is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5)

[Ballot discuss]
Oh dear, this document includes a Downref to RFC 2818.
I don't think this is used in a normative way, so perhaps fix with an
RFC Editor Note to move it to be an informative reference. (May be
better than redoing the IETF last call?)

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

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

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

a new SASL mechanism will be registered as follows:

Mechanism: SAML20
Usage: COMMON
Reference: [ RFC-to-be ]
Owner: [IESG]

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

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

the following code will be added:

Decimal: [ tbd ]
Name: SAML20
Description: SASL and GSS-API Mechanism for SAML
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required 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 and GSS-API Mechanism for SAML) 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 and GSS-API Mechanism for SAML'
  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 2012-01-05. 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


  Security Assertion Markup Language (SAML) 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 mechanism and a GSS-API
  mechanism for SAML 2.0 that allows the integration of existing SAML
  Identity Providers with applications using SASL and GSS-API.




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

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


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

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
Just got author's comments back on AD review. Looks like a new I-D will help.

  (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?

Shawn Emery , yes, yes

  (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 had adequate review from the WG members.  The shepherd doesn't
know of reviews by non WG members.

  (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?

No.

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

No concerns. No IPR disclosure is known to the author or the shepherd.

  (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 WG consensus 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.)

Nobody threatened to appeal.

  (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?

idnits 2.12.12 found no errors, but one warning that was a false-positive on
a non-compliant FQDN.

  (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].

There are downward normatives references made to the following OASIS 2.0
specifications:

OASIS.saml-bindings-2.0-os
OASIS.saml-core-2.0-os
OASIS.saml-profiles-2.0-os

The shepherd believes that these are stable specifications that some other
drafts have also listed some as normative references.

  (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 requests a new entry in the SASL
mechanism registry.

  (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?

There is ABNF in sections 3.1 and 3.2, which are correctly specified.

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

This document describes a Simple Authentication and Security Layer (SASL)
mechanism for the SAML 2.0 specification.

    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?

One controversial issue that may come up is in regards to another draft that
the kitten WG has adopted; draft-ietf-sasl-saml-ec.  The saml and saml-ec drafts
both use SAML as an authentication function, but have different use cases.  The
SAML solution requires less changes to the various entities than does
SAML-EC.  SAML-EC requires that the SASL client change.  For cases such as
browsers, this may not be an option in some environments.  SAML-EC also
requires that the Identity Provider support its ECP profile.  However, SAML-EC
provides a more integrated user solution and will provide additional support
for GSS-API per-message tokens. 

    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?

This protocol has been implemented in GNU SASL 1.7.0 and a number of
applications have utilized this version including SimpleSAMLPHP 1.6.2
with Jabberd server 2.2.11 and XMPPHP 0.1rc2-r77.