Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02

From: Klaas Wierenga <[email-masked]>
Date: Wed, 15 Jun 2011 15:26:17 +0200

On 4/9/11 11:50 PM, Alexey Melnikov wrote:

Hi Alexey,

Finally got around addressing your review comments...

Thanks for you comments! See inline.

> Shawn M Emery wrote:
> 
>> This message officially starts the Kitten Working Group Last Call for
>> the following document:
>>
>> A SASL and GSS-API Mechanism for SAML
>> http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-02
>>
>> The Working Group Last Call for this document starts today on Thursday,
>> March 31st and will end on Thursday, April 14th.
>>
>> Please send any comments to the Kitten mailing list or directly to the
>> chairs.  Feed-back from reviews that found no issues are also welcome.
> 
> While some of the generic issues are the same for this document and for
> the OpenID one, this draft is in a better shape, IMHO. At least I think

I processed your review for the OpenID draft and applied when appropriate.

> this is actually implementable without relying on some abstract
> definition of a browser.
> 
> Below are some specific comments:
> 
> 1.  Introduction
> 
>   Security Assertion Markup Language (SAML) 2.0
>   [OASIS.saml-core-2.0-os] is a modular specification that provides
>   various means for a user to be identified to a relying party (RP)
>   through the exchange of (typically signed) assertions issued by an
>   identity provider (IdP).  It includes a number of protocols, protocol
>   bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
>   [OASIS.saml-profiles-2.0-os] designed for different use cases.
> 
> Is any protocol binding mandatory-to-implement for interoperability?

added text and reference to Web Browser SSO profile (and to HTTP
redirect binding in description)

> 
>   The SAML mechanism described in this memo aims to re-use the
>   available SAML deployment to a maximum extent and therefore does not
>   establish a separate authentication, integrity and confidentiality
>   mechanism.  The mechanisms assumes a security layer, such as
>   Transport Layer Security (TLS), to protect against some attacks.
> 
> An Informative reference to TLS is needed here.

ack

> 
> 3.  Applicability for non-HTTP Use Cases
> 
>   2.  The RP sends an HTTP redirect as described in Section 10.3 of
>       [RFC2616] to the browser to the Identity Provider (IdP) or an IdP
>       discovery service with an authentication request that contains
>       the name of resource being requested, some sort of a cookie and a
>       return URL,
> 
> "URL" needs a reference.

ack

> 
>   3.  The Relying Party transmits an authentication request encoded
>       using a Universal Resource Identifier (URI) as described in RFC
>       3986 [RFC3986] and a redirect to the IdP corresponding to the
>       domain
> 
> Is this always an HTTP/HTTPS URI?

yes, changed text appropriately

> 
>   7.  The IdP will convey information about the success or failure of
>       the authentication back to the the RP in the form of an
>       Authentication Statement or failure, using a indirect response
>       via the client browser or the handler.  This step happens out of
>       band from SASL.
> 
> I think we need a mandatory to implement SAML protocol mapping here,
> otherwise this is not really implementable on the server side.

I added text to that in the descriptionj of the flow

> 
> Also, the document should be clear that the SASL server (==RP) needs to
> be able
> to talk HTTP/HTTPS.

actually, the SASL server needs to implement full SAML RP capacity, I
have added text on that

> 
>   Please note: What is described here is the case in which the client
>   has not previously authenticated.  If the client can handle SAML
>   internally it is possible that the client already holds a valid SAML
>   authentication token so that the user does not need to be involved in
>   the process anymore, but that would still be external to SASL.
> 
> Would the client need to talk to RP using an HTTP/HTTPS connection?
> I think a bit more details here would help.

I added some text, but this is the classical WebSSO case, not specific
to SASL-SAML, so I don't want to dwell too much on that.

> 
> 
> Later in this section: I think an explicit statement about the need to
> correlate
> the original TCP connection with the SAML authentication is needed.
> Also explaining how this is done in the section with an XMPP example
> would help as well.

ack

> 
> 
> 
> 6.  Channel Binding
> 
>   The "gs2-cb-flag" MUST use "n" because channel binding data cannot be
>   integrity protected by the SAML negotiation.  FIXME: Transfer channel
>   binding in SAML assertion?
> 
> Yes, this needs to be decided before the document goes to IETF LC.

this can afaik not be done today with SAML, but Scott is working on
channel binding. I have added some text describing this.

> 8.1.  Man in the middle and Tunneling Attacks
> 
>   This mechanism is vulnerable to man in the middle and tunneling
>   attacks unless a client always verify the server identity before
>   proceeding with authentication.  Typically TLS is used to provide a
>   secure channel with server authentication.
> 
> Should this  provide some details on TLS server identity verification,
> e.g. via an RFC 6125 reference?

ack

> 10.1.  Normative References
> 
> I think this section need a Normative reference to HTTPS.

ack

Klaas

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 15 Jun 2011 14:01:05 +0000

>channel binding. I have added some text describing this.

I haven't thought about it deeply, but I believe you can pull of something
involving channel binding in the "use a browser" case if you extend the
HTTP Redirect binding between the client and the IdP (you have the client
append its CB data to the URL it fires to the browser). However, that
obviously won't work with unmodified IdPs.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 15 Jun 2011 16:07:37 +0200

> obviously won't work with unmodified IdPs.

right, I wrote in the draft:

"Note: In theory channel binding data could be inserted in the SAML
flow by the client and verified by the server, but that is currently
not supported in SAML."

That seems to be the same thing you have in mind, right?

Klaas

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 15 Jun 2011 14:25:58 +0000

>That seems to be the same thing you have in mind, right?

Yes. I guess its semantics, but if I can define extensions in the manner
expected by the standard to do something, I think it's supported. Defining
new bindings and protocol extensions are compatible with the existing
profiles.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 15 Jun 2011 16:41:20 +0200

> new bindings and protocol extensions are compatible with the existing

right, what I meant to say is that there is currently no defined method
to carry whatever extra information is passed in the URL to the IdP back
to the RP. But there is no reason why you couldn't define what the IdP
should do with that blob.

Klaas

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 15 Jun 2011 14:45:03 +0000

>should do with that blob.

Technically sending the CB back to the RP isn't a requirement, but the
same syntax used to carry it from the RP to the IdP is defined for use in
the other direction in SAML Advice.

The part that's slightly broken is that I isolated the CB type from the
data, not understanding that in most cases it's munged together and opaque
to the GSS mechanism. I'll have an updated draft fairly soon I hope.

-- Scott