Subject: [appsdir] Fwd: Peter Saint-Andre's Discuss on draft-ietf-kitten-sasl-saml-08: (with DISCUSS and COMMENT)

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jan 2012 17:47:33 -0700

I thought it might be interesting to forward a few of my IESG reviews to
the list here just as a point of comparison (not that they are
necessarily any better than what our AppsDir folks are providing!).

-------- Original Message --------
Subject: Peter Saint-Andre's Discuss on draft-ietf-kitten-sasl-saml-08:
(with DISCUSS and COMMENT)
Date: Tue, 17 Jan 2012 13:23:51 -0800
From: Peter Saint-Andre <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Peter Saint-Andre has entered the following ballot position for
draft-ietf-kitten-sasl-saml-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
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 <incorrect-encoding/> to
<temporary-auth-failure/> for the error that occurs if no SAML
Authentication Request can be constructed.

Later in the flow, I would also change <temporary-auth-failure/> to
<not-authorized/> (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).