Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt

From: [email-masked]
Date: Tue, 28 Feb 2012 08:58:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : SAML Enhanced Client SASL and GSS-API Mechanisms
	Author(s)       : Scott Cantor
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-saml-ec-01.txt
	Pages           : 27
	Date            : 2012-02-28

   Security Assertion Markup Language (SAML) 2.0 is a generalized
   framework for the exchange of security-related information between
   asserting and relying parties.  Simple Authentication and Security
   Layer (SASL) and the Generic Security Service Application Program
   Interface (GSS-API) are application frameworks to facilitate an
   extensible authentication model.  This document specifies a SASL and
   GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
   SAML-aware "enhanced client" to address significant barriers to
   federated authentication in a manner that encourages reuse of
   existing SAML bindings and profiles designed for non-browser
   scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-01.txt

---

From: Jim Basney <[email-masked]>
Date: Tue, 28 Feb 2012 16:41:51 -0600

The changes in draft-ietf-kitten-sasl-saml-ec-01 look good to me. Thanks
for adding the clarifying text.

My next question is about this paragraph:

   The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism.
   The messages are the same, but a) the GS2 header on the client's
   first message 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).

I'd appreciate if you could confirm if I understand this right.

Section 4.2 gives the initial client response as:

   holder-of-key = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"
   initial-response = gs2-cb-flag "," [gs2-authzid] "," [holder-of-key]

I think the GS2 header part is:

   gs2-header = gs2-cb-flag "," [gs2-authzid] ","

So if we exclude the GS2 header and we don't support holder-of-key, then
our first output_token from gss_init_sec_context() is the GSS-API
initial context token tag (using OID 1.3.6.1.4.1.11591.4.6) with an
empty mechanism-defined token object:

0x60 0x0b 0x06 0x09 0x2b 0x06 0x01 0x04 0x01 0xda 0x47 0x04 0x06

And if we do support holder-of-key, then our first output_token from
gss_init_sec_context() has
"urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" as the mechanism-defined
token object, which adds 44 bytes to our initial context token for a
total length of 55 (0x37) bytes, giving:

0x60 0x37 0x06 0x09 0x2b 0x06 0x01 0x04 0x01 0xda 0x47 0x04 0x06 0x75
0x72 0x6e 0x3a 0x6f 0x61 0x73 0x69 0x73 0x3a 0x6e 0x61 0x6d 0x65 0x73
0x3a 0x74 0x63 0x3a 0x53 0x41 0x4d 0x4c 0x3a 0x32 0x2e 0x30 0x3a 0x63
0x6d 0x3a 0x68 0x6f 0x6c 0x64 0x65 0x72 0x2d 0x6f 0x66 0x2d 0x6b 0x65 0x79

Have I got that right?

Thanks,
Jim

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Feb 2012 18:31:03 -0600

> empty mechanism-defined token object:

The GSS-API does not permit empty tokens.  I'm not sure if an initial
context token that is empty but for the pseudo-ASN.1 header is OK.
However, I think the right thing to do is to add one constant byte to
this one token.

> 0x6d 0x3a 0x68 0x6f 0x6c 0x64 0x65 0x72 0x2d 0x6f 0x66 0x2d 0x6b 0x65 0x79

Er, I've not checked that the above starts with the right pseudo-ASN.1
header, but assuming it does, then yes.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Feb 2012 00:35:29 +0000

>   gs2-header = gs2-cb-flag "," [gs2-authzid] ","

I think the GS2 header is the entire set of options in that section.
That's SASL-specific material for GS2 as a SASL mech. At least, that's
been my understanding.

I don't believe the holder of key signaling is usable in GSS alone, I put
it into the SASL header just because I could. There are out of band means
to control use of HoK without needing it to be negotiable inline, I just
did it because it was convenient and matched up with the PAOS variant.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Feb 2012 18:39:47 -0600

> did it because it was convenient and matched up with the PAOS variant.

RFC5801 defines the gs2-header like this:

    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","

The gs2-nonstd-flags and gs2-cb-flag are single-character valyes, and
the gs2-authzid is "a=" saslname.

Everything else after that trailing comma in the gs2-header can only
be part of the GSS initial security context token.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Feb 2012 00:41:34 +0000

>However, I think the right thing to do is to add one constant byte to

I copied that text from the other SAML mechanism (though I don't see it
there literally anymore), and Simon ok'd it, so I would assume that it is
ok to omit the constant byte. If not, I'll specify something in the next
draft.

Also, I'm not sure that OID is "official". In fact, I would guess it's
not. The SAML mech currently says in draft-09 that the mech OID is TBD, so
I would imagine this one is too. I can't honestly even say where it came
from.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Feb 2012 00:45:12 +0000

>be part of the GSS initial security context token.

Ok, my mistake. Then the initial token content as currently defined would
be either empty or the HoK constant, and I'll fix the empty case if need
be.

-- Scott