Subject: Speaking in support of Scott's SAML proposal

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 19:15:37 -0400

Scott's most recent mail caused me to realize I had not explicitly
indicated support for his proposal once Shawn indicated we needed to ask
that question.

I definitely think that especially if we add CB to Scott's proposal, it
will be a good tool.
I think Simon has volunteered to help with this.
If not, I'd be happy to help as well.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 18:24:48 -0500

> I definitely think that especially if we add CB to Scott's proposal, it

+1.  But, should it be in-charter, or left to be included in a future
re-charter?  I'm assuming the latter, with an excellent chance of
adopting the work if a sufficiently fleshed out proposal materializes.

> If not, I'd be happy to help as well.

I'd review it.

---

From: "Scott Cantor" <[email-masked]>
Date: Thu, 12 Aug 2010 20:43:17 -0400

> I think Simon has volunteered to help with this.

Simon donated GS2 text to the OpenID and SAML browser mechanisms that I
think is the initial step, but as I understood the wording, it does not
allow CB, it just explains you can't have them. I was confused by this given
what I read in the GS2 RFC, which seemed to imply that all such mechanisms
had to support CB. Simon tried to explain that in email, but I don't think I
understood the explanation.

In any case, if a first step is adding the GS2 material without CB, I can do
that fairly soon.

> If not, I'd be happy to help as well.

I think a starting point will probably need to be me spending some time
reading up on CB, and perhaps getting a straw man from somebody with some
rudimentary SAML knowledge who could suggest what the basic outline of it
would have to look like.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Aug 2010 10:58:44 +0200

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

> allow CB, it just explains you can't have them.

Right.  This was an initial strawman.  I have not seen a way to support
channel bindings with OpenID, but with SAML there should certainly be a
way.  The text in the SAML spec were just copied from the OpenID text
that I wrote, and eventually I don't think they can be exactly the same
so they will need to be somewhat difference down the line.

> I was confused by this given what I read in the GS2 RFC, which seemed
> to imply that all such mechanisms had to support CB. Simon tried to
> explain that in email, but I don't think I understood the explanation.

Here is the short version:

GS2 requires that the GSS-API mechanism that GS2 wraps supports channel
bindings on the GSS-API level.  This is essential to the GS2 design and
there is no way to make anything work (securely) without it.  This is
not channel binding to a TLS session or anything like that, this is just
the basic support for doing channel binding to application-provided
data.

A GS2 mechanism does not have to support channel binding on the SASL
level, but it is recommended.

Consider real examples: The Kerberos GSS-API mechanism supports channel
bindings (and mutual authentication), so it is possible to wrap it in
GS2 so that the result becomes a SASL mechanism.  This SASL mechanism
can support binding to a TLS channel, or it can be used without binding
to a TLS channel.  This is the SASL level channel binding.  GS2
negotiates whether the SASL level channel binding support through the
GS2-KRB5 and GS2-KRB5-PLUS mechanism names.  Both variants uses GSS-API
level channel binding to make the GS2 construct secure.

> In any case, if a first step is adding the GS2 material without CB, I can do

I think that would be a good start.  I'd be happy to help, although the
basics are what is done in the OpenID document already.

> rudimentary SAML knowledge who could suggest what the basic outline of it

I'll prepare something for you.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Aug 2010 11:13:18 +0200

Scott,

Below are the changes I'd like to see in draft-cantor-ietf-sasl-saml-ec
to provide initial support for GS2.  If you'd like to co-author the
document, I'd be happy to edit the XML file to include these changes,
and any more that will come.

There is more needed than what's shown below, but that can come later.
The most important outstanding issues I see are:

* It appears as if we need to define a new GSS-API name type for SAML
  identifiers.  Your document should use the same SAML GSS-API name type
  as Klaas/Eliot's SAML mechanism, so possibly this should be done in a
  separate document that you both can reference?  Or the text could be
  duplicated, of course, but that seems sub-optimal.  Alternatively,
  there could be one name type for SAML EC and one for SAML non-EC, but
  I don't see any reason for that right now, and I see some arguments
  against.

* It should be possible to get (SASL level) channel binding support with
  SAML, and this should be added.  What is needed here is to transport
  the channel binding data (or a hash thereof) integrity protected
  through the SAML assertions.  Is that possible?  My SAML-fu is weak
  here.

* Support for GSS-API per-message tokens and GSS_Pseudo_random, similar
  to what is done for SCRAM.  What is needed here is to generate a
  symmetric key securely out of the SAML negotiation, how can that be
  done securely with SAML?  Is there already specifications on this?
  This seems like a generally useful thing to have, so if there is
  nothing like this today, perhaps we could develop it.

Are there other aspects?

/Simon

* Change title + abstract + intro to mention GSS-API

* Change section 4.2 to say that clients send the GS2 header to initiate
  connection

* Add a new section like this:

X. SAML GSS-API Mechanism Specification

   This section and its sub-sections and all normative references of it
   not referenced elsewhere in this document are INFORMATIONAL for SASL
   implementors, but they are NORMATIVE for GSS-API implementors.

   The SAML SASL Enhanced Clients mechanism is actually also a GSS-API
   mechanism.  The messages are the same, but a) the GS2 header on the
   client's first message and channel binding data is excluded when SAML
   EC is used as a GSS-API mechanism, and b) the RFC2743 section 3.1
   initial context token header is prefixed to the client's first
   authentication message (context token).

   The GSS-API mechanism OID for SAML EC is 1.3.6.1.4.1.11591.4.6.

   SAML EC security contexts always have the mutual_state flag
   (GSS_C_MUTUAL_FLAG) set to TRUE.  SAML EC does not support credential
   delegation, therefore SAML EC security contexts alway have the
   deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.

   The SAML EC mechanism does not support per-message tokens or
   GSS_Pseudo_random.

X.1. GSS-API Principal Name Types for SAML EC

   SAML EC supports standard generic name syntaxes for acceptors such as
   GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).

   SAML EC supports only a single name type for initiators:
   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
   SAML EC.

   The query, display, and exported name syntaxes for SAML EC principal
   names are all the same.  There are no SAML EC-specific name syntaxes
   -- applications should use generic GSS-API name types such as
   GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743],
   Section 4).  The exported name token does, of course, conform to
   [RFC2743], Section 3.2, but the "NAME" part of the token should be
   treated as a potential input string to the SAML EC name normalization
   rules.

   GSS-API name attributes may be defined in the future to hold the
   normalized SAML EC Identifier.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 11:16:29 -0400

> the basic support for doing channel binding to application-provided

Do you mean by this that the GSS exchange is bound to the application layer,
or that the application layer is bound to the GSS? Which is "underneath", in
other words?

The TLS case I mostly understand. Two unauthenticated endpoints with a TLS
session, and you use mutual authentication at a higher layer to attach
identity to the endpoints so that the TLS session becomes usable as an
authenticated session.

I'm not sure of the analogy to what you're describing yet.

> level, but it is recommended.

Again, when you say "on the SASL level", what's being bound to what?

-- Scott

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Aug 2010 17:26:40 +0200

> Again, when you say "on the SASL level", what's being bound to what?

And here is what where we seem to have underlying confusion about
channel bindings in the context of all of this.  Before we go ripping
documents apart or adding additional text, someone needs to answer the
broader question.  Having stepped through this repeatedly with both
Simon, and others, we've always been open to document changes that
secure the protocols and whatever bindings need securing, so long as
someone can demonstrate a problem AND we do not require additional
coding on the IdP (has to integrate with what is used today).

Eliot

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 11:36:33 -0400

> and any more that will come.

I'm fine with that if you have some time. I haven't made any additional
tweaks at this point, though I had a couple planned after some questions
from Eliot, but I can do that after you take a pass.

>   I don't see any reason for that right now, and I see some arguments

I think it wants to be a separate document. I seem to recall that there was
some discussion about that in the Moonshot context as well. I haven't had
time yet to dig into GSS-API and understand what the requirements are. I
obviously know SAML naming quite well, but I haven't been prepared to weigh
in until I understand the needs better.

In particular, it's certainly possible, but ultimately rather facile, to
identify the subject of a SAML assertion based on the NameID. But that
NameID isn't always present, and it is exceedingly common for it to be
opaque, or transient, with the real identifier(s) being passed as SAML
Attributes.

>   through the SAML assertions.  Is that possible?  My SAML-fu is weak

I've been chatting with Nico and Sam in email since last night and getting
some kind of handle on it. It's possible to extend the SAML protocol to
carry CB data that the IdP could process into the assertion. It's also
possible, and may be more elegant, to do something more like the Kerberos
case, in which a key is shared, but the client just encrypts the CB data or
hash itself in the final leg to the RP.

I'm unclear which is better, and I'm unclear how the RP performs a similar
operation, or if it needs to.

>   nothing like this today, perhaps we could develop it.

I need to understand what's being generated for whom before I can answer.
The IdP and the RP generally share knowledge of each other's long term keys.
The client rarely has a key, and doing things based on the client's
credentials becomes difficult to standardize because the client's
credentials can be many different things.

If the client has to be involved, my usual thought is to get the client to
supply a key, or input to derive a key, as an extension to the dialog with
the IdP, separate from its actual authentication credentials.

>    deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.

We may want to figure out what you mean by delegation. SAML, at least,
supports delegation in a lot of different ways.

> X.1. GSS-API Principal Name Types for SAML EC

As you noted, we definitely need to think about this.

In particular, SAML RPs are always identified by SAML entityIDs (URIs).

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 11:59:10 -0400

> broader question.

I agree. For my own purposes, I would like to be able to use the client's trust in the IdP to establish trust in the RP given that I don't believe commercial TLS is a useful trust model. As a bonus, it would be useful to give the RP the ability to connect the TLS endpoint it's communicating with to the SAML assertion it's authenticated the client with.

If possible, I'd like to do this without requiring the use of XML Signature on the client (i.e. a formal signature over the SAML response), although I'm not totally averse to it.

> Having stepped through this repeatedly with both

Let me again note my difference of opinion on the last point. My IdP can change, and it will have to, I don’t see any way around that. I was going to point out in my last note that some of the various options for injecting CB into the SAML flow are perhaps better or worse for a scenario in which a browser is pulled in, but none of them can avoid the IdP changing (or even more formally the profiles involved being extended, really).

(If there's some magic way to take the weak security guarantees we have now with Web SSO and add CB, I'm all ears.)

I think it's fine, by the way, for you to have that constraint, but I don't think it's fine if I'm not able to pursue a parallel approach without the constraint. There still seems to be this reluctance to have two mechanisms on the table, but I don't see how they can be reconciled when they have such different goals.

In the SAML community, we don't expect every profile to be identical just because it uses SAML. We also think it's better if multiple profiles share common foundations, because they usually can share code.
 
-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 11:02:29 -0500

> or that the application layer is bound to the GSS? Which is "underneath", in

If you read RFC5801 you'll see that GS2 has some plaintext bits to send
"outside" the GSS-API.  For example: the SASL authzid.  There are others
as well.

Now, when we designed GS2 we knew that we need to exchange such
information as authzid and what not, and that such information had to be
"authenticated" (i.e., not modifiable by active attackers when GS2
succeeds).

In the initial iteration of GS2 we used wrap tokens to carry this
information.  But this made GS2 too complicated.  So...  we came up with
a clever alternative: all of this data on the initiator side could be
used as the channel binding input of the GSS-API mechanism.

See RFC5801 for the remaining details.

> identity to the endpoints so that the TLS session becomes usable as an

Right.  You can use GS2 without channel bindings to TLS.  But GS2
internally uses CB for its own purposes.

> Again, when you say "on the SASL level", what's being bound to what?

At the SASL level you'd be binding to a TLS (or IPsec, or whatever) channel.

GS2 is a layer as well, a layer above a GSS-API mechanism.   And GS2
uses the CB input of the GSS-API mechanism in all circumstances.

Thus, if you're designing a GSS-API mechanism and wish it to be usable
within SASL/GS2, then your GSS must provide support for channel binding.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 11:07:53 -0500

On Fri, Aug 13, 2010 at 11:59:10AM -0400, Scott Cantor wrote:
> I agree. For my own purposes, I would like to be able to use the
> client's trust in the IdP to establish trust in the RP given that I
> don't believe commercial TLS is a useful trust model. As a bonus, it
> would be useful to give the RP the ability to connect the TLS endpoint
> it's communicating with to the SAML assertion it's authenticated the
> client with.
> 
> If possible, I'd like to do this without requiring the use of XML
> Signature on the client (i.e. a formal signature over the SAML
> response), although I'm not totally averse to it.

You can do it without XML dsig on the client.

Imagine if in Kerberos we handled channel binding by putting it in an
authorization data element in the Ticket.  The client/initiator would
ask the TGS for a Ticket and would tell the TGS what the CB data are.
The acceptor would extract the CB data (or hash thereof) from the
Ticket, and compare to the CB data passed by the application.

In your case you have the IdP playing a KDC-like role, so you could well
handle CB as I described above.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 11:13:54 -0500

> hash itself in the final leg to the RP.

Either way is fine.  Note that if you put the CB data into the "ticket"
(the SAML assertion produced by the IdP for the RP's consumption) then
when the CB data are "unique" then you'll end up being unable to cache
"tickets".

(In the Kerberos world we still believe in the utility of caching
tickets, though I don't really think it's that useful anymore.  Ticket
caching is the reason that the CB are in the Authenticator instead of
the Ticket.)

In your case, is there something like an Authenticator?

> >   nothing like this today, perhaps we could develop it.

SASL/GS2 does not require GSS-API per-message tokens nor
GSS_Pseudo_random().

But many GSS-API applications do, so it's useful to provide these.
Start with CB, then let's work on the rest.

> supports delegation in a lot of different ways.

Oh, that's a whole 'nother topic.  Let's leave that for another day.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 12:46:41 -0400

> when the CB data are "unique" then you'll end up being unable to cache

This is normally not a concern because the assertions are usually short
lived. So far, they're still bearer tokens in the scenarios here (they may
or may not stay that way, but let's assume for now), so they get minted per
login to a RP.

I'm coming around to the idea of having the IdP stick it in, but I think I'm
only missing the final piece of how this authenticates the server/acceptor
end of the channel, and not just the client end.

> In your case, is there something like an Authenticator?

SAML is abstracted from the security layer in which the assertion is
presented. The abstraction is called "subject confirmation". The IdP
includes a description in the assertion of how the client has to prove its
right to use the assertion.

Often, such as in Web SSO, this is a "null proof" consisting of "bearer". I
have it (and perhaps have a particular client address), so I can use it. It
is usually a short lived window in which I can present it but that's it.

It can be something other than bearer, such as "holder of key", in which I
prove key possession by signing something or using TLS. There is a proposed
method of "Kerberos" in which a ticket + Authenticator would accompany the
assertion in the protocol. Etc.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 11:58:13 -0500

> end of the channel, and not just the client end.

You need some way to indicate to the initiator that the acceptor checked
that the CB match.  If you don't have enough message legs in your
protocol to do this, then you might have a problem :(

One possibility might be to use the RP's server cert as the CB and have
the IdP do something to confirm that the cert seen by the client is a
known cert for the RP named by the client.  This would mean that you'd
only support 'tls-server-end-point' CB, but it would get you going.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 13:15:14 -0400

> protocol to do this, then you might have a problem :(

The EC SASL mechanism as it stands now assumes that the server is signaling
the client what the outcome was. Is that what you're talking about, or
something more?

> only support 'tls-server-end-point' CB, but it would get you going.

So, what I had in mind was something like this:

1. RP includes its CB data in the SAML AuthnRequest it gives to the client
(exact means TBD). The AuthnRequest is signed with the RP's key.

2. Client adds its CB data to its message to the IdP that includes the
AuthnRequest and its credentials.

3. IdP compares them (along with verifying the request signature, and all
the other bits it does) and if they match, issues the response with the
encrypted assertion containing the CB data (again exact means TBD)

4. RP gets response from client, decrypts the assertion, checks the CB data
in the assertion as it checks the rest of the material, and if they match,
sends back the OK, else an error.

Ok, attack away. If I'm right, this is a simple addition and there's
actually a pretty good way to carry this in SAML that fits very nicely. If
not, back to the drawing board.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 12:28:58 -0500

> the client what the outcome was. Is that what you're talking about, or

The outcome of authentication signal itself needs to be authenticated,
implicitly or explicitly.  Specifically, it must be impossible for an
MITM to make a client think authentication succeeded when the real
server thought it failed.

> encrypted assertion containing the CB data (again exact means TBD)

Does the client get an indication from the IdP as to whether the CB
check passed?  Presumably the IdP won't issue the assertion if the CB
fail to match!  Assuming that, then, yes, your approach works.

> sends back the OK, else an error.

The RP doesn't have to check the CB data at this point if it trusts the
IdP to have done it.  And if the client doesn't independently pass CB
data to the RP then there's nothing the RP can do but trust that the IdP
did it.

> not, back to the drawing board.

I believe your strawman stands.

Nico
--