Subject: [abfab] Two internet drafts submitted

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2010 21:42:16 -0400

As people have seen I've submitted (with chair approval) two of the
drafts called out in the charter.

These drafts are unchanged except for the name changes from the 00
versions explicitly listed as starting points in the charter.

Obviously, there are changes we wish to make. However, we need to have
the necessary WG discussions for those changes.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Thu, 14 Oct 2010 11:11:41 +0200

> the necessary WG discussions for those changes.

Thanks for getting the ball rolling Sam!

	Cheers Leif

---

From: Gabriel Lopez <[email-masked]>
Date: Thu, 14 Oct 2010 12:24:31 +0200

Without enter in details, two comments on the gss-eap-00 doc:

- SAML is mentioned in the introduction, but it is not clearly described 
what is purpose of using it in the proposed scenario. Indeed, I would 
suggest to remove SAML from this draft and to focus on the EAP-GSS 
integration. A more detailed document describing how SAML could fit 
here, or even in the eap-naming-00 document would be better.
     If it is a key point in this document, then, it should appear in 
the document title, something like draft-....-gss-eap-saml-00.txt

     - SASL is mentioned in 1.1 and 5.1, but it is not clear the role of 
SASL in the scenario. Is it required? why do you need a SASL registry? 
Sorry, maybe a should read more about SASL, it is just my feeling 
reading the doc :)

     Best regards, Gabi.

El 14/10/10 03:42, Sam Hartman escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de IngenierÌa de la InformaciÛn y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Luke Howard <[email-masked]>
Date: Thu, 14 Oct 2010 21:33:51 +1100

> Thanks for getting the ball rolling Sam!

I can also informally document the assumptions I made in building an implementation, regarding the bits that aren't yet specified.

Off the top of my head:

* enctype to mechanism OID mapping
* RFC 4121 key derivation from MSK
* SASL GS2 mechanism names (EAP-AES{128,256})
* format of channel binding token
* format of extension tokens (TLV, used to contain CBT)
* RADIUS attributes for acceptor names
* GSS name attribute format for RADIUS value-pairs
* format of exported names (identical to Kerberos so far)
* format of exported composite names (this is allowed to be implementation dependent but may be nice to standardise)
* context error token format/codes (added for better error reporting)

I'm sure there's more. I should have kept a list.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Thu, 14 Oct 2010 21:35:54 +1100

>    - SASL is mentioned in 1.1 and 5.1, but it is not clear the role of SASL in the scenario. Is it required? why do you need a SASL registry? Sorry, maybe a should read more about SASL, it is just my feeling reading the doc :)

Should be sufficient just to reference RFC 5801 and indicate the SASL mechanism names. But this could also be in a separate (very brief) document.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Oct 2010 08:31:30 -0400

Luke, Your list aligns fairly well with a list I sent to the chairs
yesterday:-) You had a couple of extra items.
I may have to go through all the mail I've received from you--that could
be fun:-)

--Sam

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Oct 2010 09:43:39 +1100

Sam,

OK, allow me to summarise in a terse form that can be translated by you more loquacious draft writers. :-)

> * enctype to mechanism OID mapping

Consists of a OID prefix, currently 1.3.6.1.4.1.5322.22.1, concatenated with the RFC 3961 encryption type.

> * RFC 4121 key derivation from MSK

K = truncate(L, T1 || T2 || .. || Tn)
L = output RFC 4121 key size
Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap")
KMSK = random-to-key(MSK)

> * SASL GS2 mechanism names (EAP-AES{128,256})

EAP-AES128
EAP-AES256

> * format of channel binding token

Currently a RFC 4121 wrap token where the input is the application-data field. Using Unwrap and compare (as opposed to VerifyMIC) allows the acceptor to ignore the channel bindings information without disturbing the sequence state. However I'm not opposed to changing this to a MIC token.

The channel binding token is encapsulated in an initiator extension token.

> * format of extension tokens (TLV, used to contain CBT)

The last round-trip consists of an exchange of extension tokens, whose innerContextToken is defined below (EXT_REQ from initiator, EXT_RESP from acceptor):

TOK_ID || E1 || E2 || .. || En
TOK_ID = EXT_REQ | EXT_RESP
EXT_REQ = 06 03
EXT_RESP = 06 04
En = T || L || V
T = extension type as 32-bit integer in network byte order
L = extension length as 32-bit integer in network byte order
V = extension value as octet string

Critical extensions have the high bit set. One critical extension type is defined for channel bindings and has the value zero (not including the critical bit).

> * RADIUS attributes for acceptor names

VENDOR  UKERNA                          25622

BEGIN-VENDOR UKERNA

ATTRIBUTE       GSS-Acceptor-Service-Name       128     string
ATTRIBUTE       GSS-Acceptor-Host-Name          129     string
ATTRIBUTE       GSS-Acceptor-Service-Specific   130     string 
ATTRIBUTE       GSS-Acceptor-Realm-Name         131     string 
ATTRIBUTE       SAML-AAA-Assertion              132     string 

END-VENDOR UKERNA

They should be mostly self explanatory; GSS-Acceptor-Service-Specific is a slash-separate set of service-specific components. A Kerberos-like principal name string  is assembled as:

GSS-Acceptor-Service-Name || "/" GSS-Acceptor-Host-Name [ || "/" GSS-Acceptor-Service-Specific ] "@" GSS-Acceptor-Realm-Name

> * GSS name attribute format for RADIUS value-pairs

"urn:ietf:params:gss-eap:radius-avp urn:x-radius:" || attrID

where attrID is the string representation of the RADIUS attribute ID.

> * format of exported names (identical to Kerberos so far)

Identical to Kerberos, as noted. The MECH_OID excludes the last (encryption type) OID element as names are not specific to encryption types.

> * format of exported composite names (this is allowed to be implementation dependent but may be nice to standardise)

CN = TOK_ID || MECH_OID_LEN || MECH_OID || N || A1 || A2 || .. || An
TOK_ID = 04 02
MECH_OID = OID without encryption type
N= principal name string
An = T || L || V
T = attribute type as 32-bit integer in network byte order
L = attribute length as 32-bit integer in network byte order
V = attribute value as octet string

ie. this is the non-composite exported name with RADIUS attributes concatenated to the end

> * context error token format/codes (added for better error reporting)
 
Error tokens allow the acceptor to indicate a context error to the initiator. They are not protected because they are omitted before context establishment, and are informational only; the initiator may choose to ignore them.

TOK_ID || MAJOR || MECH [ || DESC ]
TOK_ID = 06 06
MAJOR = GSS major status code in network byte order
MECH = GSS EAP mechanism code
DESC = optional octet string containing more information

Mechanism codes to be defined

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Oct 2010 18:00:12 -0500

On Fri, Oct 15, 2010 at 09:43:39AM +1100, Luke Howard wrote:
> Consists of a OID prefix, currently 1.3.6.1.4.1.5322.22.1,
> concatenated with the RFC 3961 encryption type.

+1.

> KMSK = random-to-key(MSK)

The rage in KDFs seems to be to apply an entropy extraction step first;
see RFC5869.  Now, I don't think that really matters here, but, it's
worth considering this now.  (It's too late for the rest of Kerberos,
including the krb5 GSS PRF.)

> > * SASL GS2 mechanism names (EAP-AES{128,256})

+1.

> Currently a RFC 4121 wrap token where the input is the
> application-data field. Using Unwrap and compare (as opposed to
> VerifyMIC) allows the acceptor to ignore the channel bindings
> information without disturbing the sequence state. However I'm not
> opposed to changing this to a MIC token.
> 

+1.

Will this mechanism have initiator and acceptor sub-keys, like RFC4121?

> The last round-trip consists of an exchange of extension tokens, whose
> innerContextToken is defined below (EXT_REQ from initiator, EXT_RESP
> from acceptor):
> 
> Critical extensions have the high bit set. One critical extension type
> is defined for channel bindings and has the value zero (not including
> the critical bit).

Any way to optimize round-trips away?

> Identical to Kerberos, as noted. The MECH_OID excludes the last
> (encryption type) OID element as names are not specific to encryption
> types.

+1.

If the exported name token format is identical to RFC1964's but the
names are not Kerberos names per-se, then this is fine.

> > * format of exported composite names (this is allowed to be
> > implementation dependent but may be nice to standardise)

Yes.

> ie. this is the non-composite exported name with RADIUS attributes

Is T here from a Radius namespace?  If so, you could add a meta-type
field for non-Radius attributes, no?

> Error tokens allow the acceptor to indicate a context error to the
> initiator. They are not protected because they are omitted before
> context establishment, and are informational only; the initiator may
> choose to ignore them.
> 

It'd be nice to be able to protect protectable errors, e.g., errors
resulting from policy decisions as opposed to errors resulting from
inability to complete key exchange.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Oct 2010 18:19:58 -0500

On Fri, Oct 15, 2010 at 09:43:39AM +1100, Luke Howard wrote:
> They should be mostly self explanatory; GSS-Acceptor-Service-Specific
> is a slash-separate set of service-specific components. A
> Kerberos-like principal name string  is assembled as:

What are "service-specific components"?

> GSS-Acceptor-Service-Name || "/" GSS-Acceptor-Host-Name [ || "/" GSS-Acceptor-Service-Specific ] "@" GSS-Acceptor-Realm-Name

Presumably the GSS-Acceptor-Host-Name will be an FQDN in general?

Also, how is the GSS-Acceptor-Realm-Name determined when a name is
imported using GSS_C_NT_HOSTBASED_SERVICE is canonicalized (or passed to
gss_init_sec_context() as a targ_name)?

> where attrID is the string representation of the RADIUS attribute ID.

Seems fine to me.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Oct 2010 19:22:07 -0400

RFC 5869 says that the extract phase is unneeded if you start with a
strong pseudo-random key.
That is consistent with my knowledge.

I *thought* the EAP MSK was supposed to be such a key, but I think we
should ask the EAP community about this.  If it is, I think Luke's
construction is fine.  Otherwise we should look at what we can do.  I'm
kind of loathed to depend on a hash function though.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Oct 2010 19:28:12 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> What are "service-specific components"?

Name components specific to a particular service type
For example the MTP service has the hash of a metadata document as part
of the service specific portion along with a URI to that document.

If service-specific components are present and the IDP-side AAA proxy
does not understand them, it rejects the authentication.

    Nicolas> Also, how is the GSS-Acceptor-Realm-Name determined when a
    Nicolas> name is imported using GSS_C_NT_HOSTBASED_SERVICE is
    Nicolas> canonicalized (or passed to gss_init_sec_context() as a

Remember these are AA attributes.
They appear in two places:

1) channel bindings from the initiator to the EAP server.
There, the realm name is absent if not specified.

2) In AAA attributes from the acceptor to the EAP server via a bunch of
proxies.
There, we assume the acceptor knows its own realm name.

Proxies along the way are responsible for validating the claim the
acceptor is implicitly making--namely that the given hostname is part of
the claimed realm.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Oct 2010 18:28:58 -0500

> That is consistent with my knowledge.

Please ignore that.  'Twas a braino.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Oct 2010 18:33:07 -0500

> acceptor is implicitly making--namely that the given hostname is part of

Understood.  But remember that the GSS-API, for better or worse,
requires that one be able to canonicalize a name, then export it, and
that the resulting exported name token should be the same as the one one
would get from exporting the name for the same principal returned by
GSS_Inquire_sec_context().

Personally I'm perfectly willing to accept that if you want such
behavior then you must import the name with mechanism-specific name type
rather than generic name type, and the buffer to be imported must
contain a canonical principal name.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Oct 2010 19:36:52 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Understood.  But remember that the GSS-API, for better or
    Nicolas> worse, requires that one be able to canonicalize a name,
    Nicolas> then export it, and that the resulting exported name token
    Nicolas> should be the same as the one one would get from exporting
    Nicolas> the name for the same principal returned by
    Nicolas> GSS_Inquire_sec_context().

I *think* you generally get that.  I'm not sure you get the same
exported name on the initiator and acceptor for the same principal, but
I do believe that the ACL uses of export_name will work.  This is
certainly something to explore.

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Oct 2010 12:32:14 +1100

> Will this mechanism have initiator and acceptor sub-keys, like RFC4121?

This was discussed previously, on this list I believe, and the answer was no. (I will have more to say on this later.)

> Any way to optimize round-trips away?

We could piggy-back the server extension token to the last EAP message from the acceptor. Does EAP always have an even number of legs? If not, then we can (for odd number) piggy-back the client extension token to the last message from initiator. But I don't know if there's a way to know this in an abstraction-preserving way.

> field for non-Radius attributes, no?

Thinking about this some more, if we really want to standardise this, we need to encode authenticated-flag, complete-flag and a critical flag (must be understood by import name). e.g.

flags || type || subtype-length || subtype || value-length || value

I'm going to argue now in favour of not standardising it unless someone can come up with a compelling argument why you want to use exported composite names for anything other than interprocess exchange. If you want to do attribute-based authorisation, you should extract the attributes you're interested in explicitly.

> inability to complete key exchange.

True. But if we protect the policy error codes, then what's to stop an attacker removing the MIC and changing the policy error code to a non-policy one?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Oct 2010 12:32:40 +1100

>> where attrID is the string representation of the RADIUS attribute ID.

Well, perhaps we should get an assigned URN type for RADIUS attributes.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Oct 2010 12:40:03 +1100

Here's a complete list of token types I've used so far, FWIW.

enum gss_eap_token_type {
    TOK_TYPE_NONE                    = 0x0000,  /* no token */
    TOK_TYPE_MIC                     = 0x0404,  /* RFC 4121 MIC token */
    TOK_TYPE_WRAP                    = 0x0504,  /* RFC 4121 wrap token */
    TOK_TYPE_EXPORT_NAME             = 0x0401,  /* RFC 2743 exported name */
    TOK_TYPE_EXPORT_NAME_COMPOSITE   = 0x0402,  /* exported composite name */
    TOK_TYPE_DELETE_CONTEXT          = 0x0405,  /* RFC 2743 delete context */
    TOK_TYPE_EAP_RESP                = 0x0601,  /* EAP response */
    TOK_TYPE_EAP_REQ                 = 0x0602,  /* EAP request */
    TOK_TYPE_EXT_REQ                 = 0x0603,  /* GSS EAP extensions request */
    TOK_TYPE_EXT_RESP                = 0x0604,  /* GSS EAP extensions response */
    TOK_TYPE_CONTEXT_ERR             = 0x0606,  /* context error */
};

Note: EAP *response* is an initiator token (it's back to front).

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2010 02:13:37 -0500

On Fri, Oct 15, 2010 at 12:32:14PM +1100, Luke Howard wrote:
> This was discussed previously, on this list I believe, and the answer
> was no. (I will have more to say on this later.)

I recall (and recalled when I asked), but wanted to make sure it still
was the case.

> Thinking about this some more, if we really want to standardise this,
> we need to encode authenticated-flag, complete-flag and a critical
> flag (must be understood by import name). e.g.
> 
> I'm going to argue now in favour of not standardising it unless
> someone can come up with a compelling argument why you want to use
> exported composite names for anything other than interprocess
> exchange. If you want to do attribute-based authorisation, you should
> extract the attributes you're interested in explicitly.

If there's multiple GSS-API implementations, then a standard
inter-process token format can add value.

> True. But if we protect the policy error codes, then what's to stop an
> attacker removing the MIC and changing the policy error code to a
> non-policy one?

Nothing, of course.  But in the case of Kerberos there are a number of
errors which would have been much handier when protected.  For example,
errors about clock skew would, if protected, provide authenticate time
to the client (handy indeed!).  (Yes, I know that clients can use the
time info in KRB-ERROR to adjust their timestamps and re-try, then they
can get authenticated time with second precision.)  It's... not a big
deal, and less so for this mechanism than for Kerberos.  Feel free to
say ETOOHARD or EWHOCARES :)

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Oct 2010 18:16:32 +1100

> say ETOOHARD or EWHOCARES :)

major_status = GSS_S_UNAVAILABLE;
*minor_status = GSSEAP_TOOHARD;

:-)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 16 Oct 2010 22:24:21 +1100

Current implementation protocol error codes, some may move back to API-only codes (they were retro-fitted to existing code so they certainly can be refined).

success				0	# never seen
wrongSize			1	# incorrect buffer size
wrongMech			2	# wrong mechanism OID in token
badTokenHeader			3	# bad token header
tokenTruncated			4	# truncated token
badDirection			5	# packet replayed in wrong direction
wrongTokenID			6	# wrong token ID
criticalExtensionUnavailable	7	# critical extension unavailable
missingRequiredExtension	8	# missing required extension
keyUnavailable			9	# MSK not available
keyTooShort			10	# MSK too short to derive KMSK
radiusAuthenticationFailure	11	# RADIUS authentication failed
unknownRadiusResponse		12	# RADIUS authentication unknown resp
missingEapRequest		13	# missing EAP request in RADIUS resp
genericRadiusError		14	# other RADIUS error

-- Luke