Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec

["Cantor, Scott" <[e-mail]>]

On 3/10/14, 2:49 PM, "Sam Hartman" <[e-mail]> wrote:

>I've reviewed the SAML EC draft.
>It was easy to read, and I appreciate the work that has gone into it.
>I would prefer to wait  for responses to these comments prior to issuing
>a WG LC.

Thank you for the review. Given the extensive comments, it's likely to
take me a little time to make changes since I'm not formally allocated any
time to work on this at the moment by my project.

Some responses at least....

>Section 1:
>
>A reference to the discovery/WAYF problem would be desirable but is not
>required.

I'm not sure any formal reference exists, other than perhaps to the actual
SAML profiles that (poorly) address it in the case of a browser.

>Section 3:
>In this mechanism, the client does not send the response to the RP at a
>location of the IDP's choosing but instead sends to a location of the
>client's choosing through SASL.
>What are the implications of this?
>
>I guess one is the attack Jim brought up and we discussed in ABFAB.

Yes, there is essentially a MITM issue if channel binding isn't done or a
session key isn't established and used.

>In the section on interactions with the IDP, there is no
>mandatory-to-implement mechanism specified for finding an IDP.  I'd
>appreciate comments from the WG on whether this lack is a problem in
>terms of guaranteeing that two implementations of this mechanism will be
>interoperable.
>Should we require something like support for static configuration of an
>IDP?

What does ABFAB require? I don't see that asking for a domain in and of
itself makes discovery happen without more infrastructure that's
presumably out of scope there.

>Section 5:
>
>SASL has an idea of mutual authentication.
>It seems like the same checks that apply to GSS-API should apply to SASL
>mutual auth too.

I didn't think SASL had an actual indicator of mutual-auth, but if it
does, it seems like the same text is probably needed there. Otherwise I'm
not sure how to work in the text. In contrast to many of the recent
discussions, I'm very SASL illiterate and much more GSS "aware" I guess,
if not expert.

>The checks in section 5 seem inadequate.  In particular, it seems like
>it should matter what identity is used to digitally sign the request,
>and  the validity of the signature should matter.

Yes, I was leaving trust out of this, but something could be said if it's
helpful.

[snip of TLS text]
>This text places normative requirements on applications using this
>mechanism.
>That's not reasonable because applications may have no knowledge of this
>mechanism.
>What happens if these checks are not performed?

That text came from some iteration of the original wording borrowed from
the SAML/OpenID mechanisms, and was basically adapted. Isn't that same
text, or a variant, essentially what Simon is adding to GS2?

All this is saying is that if the mechanism doesn't signal mutual
authentication to the initiator, then obviously it's up to the
application. What else can you do?

>Section 5.1 seems applicable to SASL as well.

Similar question as above; is there normative machinery that can be used
in SASL to regulate and signal it? I didn't think so.

>It doesn't sound like section 5.1 provides enough guidance to provide
>interoperability between multiple implementations of delegation to me.

I could make a crack about OAuth interop here (I'll leave WS-Trust out of
it, but OAuth is IETF's responsibility), but let me just say that it's
sufficient to implement *a* SAML profile of delegation, and that's
intended to be an extenstion point in the draft that doesn't preclude
delegation while leaving the gory details out. If I were to formally
specify this, it wouldn't be here because it doesn't impact the GSS work,
it's purely a SAML spec.

>Section 5.3 is inconsistent with the claim in the introduction that no
>integrity and confidentiality layer is provided.

Will fix, the intro predates all that work being added.

>Section 5.3.  I note that this is the first time I'm aware of where
>RFC 3961 enctypes' names are used in a protocol.  I'd like explicit
>review of this from the Kerberos community.  Everything we have so far
>uses numbers.

Ok, will await decision. I don't care for numbers in a text-based
protocol, but if the strings aren't formalized, that's appropriate. I
think I did look at the registry though and came to the conclusion they
were.

>Section 5.3.1:
>
>I think encryption needs to be a MUST here.
>Even if CB is used there's no confidence that the channel provides
>confidentiality.
>Consider for example a TLS cipher without confidentiality, an IPsec
>channel for ESP-null, etc.

That's true. I can make it a MUST.

>Section 5.4: RFc 4121 has multiple keys it can use: the session key, the
>subsession key, and the acceptor subsession key.
>The text in 5.4 is insufficiently detailed for interoperability.

I'd need feedback on that, I don't have the background (and it was more or
less copied, again, from some other work).

>Section 5.6.2:
>
>1) I am not sure that the guidance here is sufficient for
>interoperability and security.

Possibly not security, but I'm not sure why it's not interoperable. In
particular, I didn't go and require any kind of remapping of service names
into URLs; that would definitely not be.

As far as what it *does* for security, it binds the eventual key(s) used
by the acceptor to specific service identities that the IdP can authorize
a signed request on, and allows many such services to be associated with
one entityID (but also allows each service to have its own, as desired).

That's not perfect (the MITM thing) but it is not nothing given that a
client is at least nominally connecting with specific protocols that may
well be expressed as part of the service name (e.g. you at least couldn't
spoof an SSH server with an HTTP/host identity) since presumably the
service name is something the client isn't totally oblivious to.

>2) This section appears to place normative requirements on the IDP even
>though   the specification claims not to place normative requirements on
>the IDP.

No new requirements. This is standard comparison logic all IdPs do for ECP
and Web SSO.

>3) This section seems to apply to SASL.

Yeah, that one does.

-- Scott