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

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Mar 2014 14:49:46 -0400

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.

I request review of these comments from the Kerberos community as well as the SAML EC community.

I have not closely read the SAML and SAML ECP specifications, and as a
result I cannot provide sufficient review of the overall security and
interoperability of this mechanism.  We will need review of that from
folks other than the authors prior to progressing the specification.

I cannot promise doing that additional review in a timely manner.

Section 1:

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

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.

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?

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.

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.

>         If the mutual_state flag is not requested, or is not set, then the
>	    security layer managed by the application outside of the GSS-API
>	       mechanism is responsible for authenticating the acceptor.  In this
>	          case, applications MUST match the server identity from the existing
>		     security layer with the target name.  For TLS, this matching MUST be
>		        performed as discussed in [RFC6125].  For SSH, this matching MUST be
>			   performed as discussed in [RFC4462].

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?

Section 5.1 seems applicable to SASL as well.

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

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

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.

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.

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.

Section 5.6.2:

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

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

3) This section seems to apply to SASL.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Mar 2014 20:27:10 +0000

>I would prefer to wait  for responses to these comments prior to issuing

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

>A reference to the discovery/WAYF problem would be desirable but is not

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.

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

>Should we require something like support for static configuration of an

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.

>It seems like the same checks that apply to GSS-API should apply to SASL

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.

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

>review of this from the Kerberos community.  Everything we have so far

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.

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

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

>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

---

From: Simo Sorce <[email-masked]>
Date: Mon, 10 Mar 2014 17:02:56 -0400

> What happens if these checks are not performed?

This text seem to echo Section 4 of RFC 6595 however I see no reference
to 6595 in this draft, maybe I am missing something, this is the first
time I am looking as SASL/SAML drfats, sorry.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Mar 2014 21:08:11 +0000

>time I am looking as SASL/SAML drfats, sorry.

It does copy that exact text, yes, but this has nothing to do with that
mechanism, so there's no reference to it.

The text was copied to address the cross-mechanism case of not having
mutual authentication. The difference here is that you can have it at
times, whereas using the browser to login will never give it to you.

I am not at all wedded to that specific text, but presume something is
needed, but maybe it's just a security consideration.

-- Scott

---

From: Simo Sorce <[email-masked]>
Date: Mon, 10 Mar 2014 17:48:12 -0400

> mechanism, so there's no reference to it.

Is there  a document somewhere that explains the differences ?

They look pretty similar from a 30k miles view.

> times, whereas using the browser to login will never give it to you.

I would rather not support mutual then, given you cannot guarantee it
from within the mechanism.

> needed, but maybe it's just a security consideration.

Yes it probably should be.

Simo.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 11 Mar 2014 14:27:50 +0000

>Is there  a document somewhere that explains the differences ?

No, other than I suppose the ECP profile in SAML, which does outline the
difference.

>They look pretty similar from a 30k miles view.

They're not really similar.

Simply put, SAML-EC adapts the SAML profile designed for non-browser
authentication, and the other mechanism adapts the browser SSO profile. In
doing the adaptation, I researched the GSS-API requirements around
mutual-auth, channel binding, and session key establishment, and extended
ECP to support them.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Mar 2014 12:23:16 -0400

It sounds like section 5.6.1 requires that the service and client be
able to represent a GSS service name as a URI so that the IDP can verify
that the service corresponds to the entity ID and that the client can
check the service name against the endpoint in the response.

It seems like from an interoperability standpoint we need to make sure
that clients and servers will perform the same transformation on a GSS
service name and that two different implementations will do the same
thing.

I'm not seeing where that transformation is specified.
How do I go from a service name plus host name into the form that is
expected in the SOAP messages?

In response to other issues.
SASL doesn't have formalized notions of how to signal mutual auth or
discuss delegation.  However SASL implementations do generally provide
that information.
So, my recommendation is that we describe the checks both for SASL and
GSS, but the signaling to the application is vague for SASL.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 11 Mar 2014 16:43:51 +0000

>check the service name against the endpoint in the response.

No, I explicitly avoided converting it, I'm just using the service names
as "relative mailto: URIs" from a syntax point of view, but in practice
SAML IdPs don't care, they compare strings, if they do anything at all.

>service name and that two different implementations will do the same

That's why I avoided doing it.

>GSS, but the signaling to the application is vague for SASL.

Ok, I can try and finesse that. Are there other mechs that have done so
with language that can be reused?

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Mar 2014 15:30:15 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> On 3/11/14, 12:23 PM, "Sam Hartman" <[email-masked]> wrote:
    >> It sounds like section 5.6.1 requires that the service and client
    >> be able to represent a GSS service name as a URI so that the IDP
    >> can verify that the service corresponds to the entity ID and that
    >> the client can check the service name against the endpoint in the
    >> response.

    Cantor,> No, I explicitly avoided converting it, I'm just using the
    Cantor,> service names as "relative mailto: URIs" from a syntax
    Cantor,> point of view, but in practice SAML IdPs don't care, they
    Cantor,> compare strings, if they do anything at all.

So do you expect the string to be 
mailto:[email-masked] or [email-masked]?
Either way this is non-obvious to me having read the document.  I
assumed you wanted some conversion or some URI encoding.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 11 Mar 2014 16:54:19 -0400

> application. What else can you do?

That text was used in the SAML and OpenID mechanisms to attempt to
handwave around the need for a mechanism that _claims_ to have done
mutual authentication to actually _do_ mutual authentication.

Basically, what those mechanisms did was say "we're going to assert
mutual_state, but we don't actually do anything to verify the acceptor's
identity, so the application had better have done that even though we
claim to have done it".  They did that because GS2 as written fails on
mechs that don't assert mutual_state.

That's not an acceptable way for a GSS-API mechanism to behave.  It's
essentially trying to reach up through the abstraction boundary and
impose new requirements on the application depending on what mechanism
is used, and the API doesn't allow for that.

It's not necessary for a mechanism to say "if we didn't assert
mutual_state, then we didn't do mutual auth, and if the app cares, then
it had better do something about it".  That is a property of the
abstraction and is true for _every_ mechanism.

For the SAML and OpenID mechanisms, if the application does not perform
the checks in question, then badness ensues, because the application
sees mutual_state and assumes the acceptor has been authenticated, when
it really has not.  If _this_ mechanism only asserts mutual_state when
it has actually authenticated the acceptor (if ever), _and_ it doesn't
depend for its security on the application having already verified the
server's identity (as, for example, SASL PLAIN does), then there is no
problem.

> in SASL to regulate and signal it? I didn't think so.

SASL unfortunately doesn't have a well-defined abstraction.  Not all
SASL mechanisms provide mutual authentication (for example, PLAIN does
not), and the base spec doesn't really talk about it.  Over time, I
think the community mostly accepted that the usual case was to run a
SASL application over TLS, relying on TLS to authenticate the server and
using SASL to authenticate the client.

However, we have introduced the notion of channel bindings.  It's only
safe for an application to rely on CB if mutual authentication has
happened.  This is why GS2 required mutual auth, and why a new version
of GS2 which relaxes this requirement must be careful to specify that
-PLUS mechanisms must not be advertised unless mutual auth is possible,
and must not succeed if mutual auth does not happen.

So no, in the abstract, there's not really any machinery in SASL to
signal whether mutual auth happened, except for the implied indication
when channel bindings are in use.

> think I did look at the registry though and came to the conclusion they

The names of enctypes have never been protocol constants.  There have
frequently been inconsistencies in the spelling and punctuation of these
names.  There has also been confusion at various points as to what
particular names meant.  There is no formal definition of the syntax of
an enctype name, because they are never used in a case where that
matters.  Also, I think it is unwise to expect libraries which implement
RFC3961 to provide interfaces to look up enctypes by name, and
impractical and counterproductive for a mechanism implementation to
maintain a private table.

Please use the numbers; that's the namespace we've actually
standardized.

> less copied, again, from some other work).

A typical behavior would be to prefer an acceptor subkey if one was
sent, followed by an initiator subkey if one was sent, followed by the
Kerberos ticket session key.  However, this can get a bit complicated,
because an initiator does not know whether the acceptor sent a subkey
until it processes the acceptor's AP_REP.  That means you either need to
avoid the initiator having to choose until it has seen that message, or
having some way to know which key to use when.  Doing the first is not
bad, but can result in extra round trips depending on what you're doing.

-- Jeff

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 11 Mar 2014 23:18:27 +0000

>mailto:[email-masked] or [email-masked]?

The latter. Exactly the service name.

>assumed you wanted some conversion or some URI encoding.

No problem, easy to fix.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 11 Mar 2014 23:27:13 +0000

>abstraction and is true for _every_ mechanism.

Ah, ok. Will fix/adjust, thanks.

>when channel bindings are in use.

Got it.

>Please use the numbers; that's the namespace we've actually

Ok. I don't think there are any implications back on the SAML material I
wrote for this at OASIS, but I will review that as part of fixing this.

>bad, but can result in extra round trips depending on what you're doing.

Is there actually an AP_REP here? Or do you mean that euphemistically? I
didn't think reuse of those formats and encryption types implied actual
Kerberos-defined messages anywhere, but this is definitely not anything
I'm familiar with directly.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Mar 2014 14:57:55 -0400

I think on the subkey/session key/acceptor subkey space
twe need to find the right language to say "just use this key!" in the
terminology of rfc 4121.
I don't have that swapped in, b ut it's just a matter of finding the
right text.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 13 Mar 2014 20:09:07 +0000

On 3/13/14, 2:57 PM, "Sam Hartman" <[email-masked]> wrote:

>we need to find the right language to say "just use this key!" in the
>terminology of rfc 4121.

I believe the answer is to just use the so-called protocol or session key.
There's no subkey here because it's not Kerberos messages going back and
forth. That was the intent of the current language so hopefully it's just
a clarification that there's no subkey involved.

-- Scott