Subject: Update to RFC4121

From: Shawn M Emery <[email-masked]>
Date: Wed, 23 Aug 2006 11:44:49 -0600

Folks,

I have completed the first revision of RFC4121.  This revision includes 
the protocol changes for channel binding's hash agility.  Refer to the 
attached diffs.  Please provide any comments or questions. 

Shawn.
--

p.s. Last call for this is scheduled for Nov, 2006.
--- rfc4121.txt	Sat Aug 12 00:26:43 2006
+++ rfc4121.txt.4	Tue Aug 22 23:23:03 2006
@@ -159,10 +159,13 @@
 
    The term "little-endian order" is used for brevity to refer to the
    least-significant-octet-first encoding, while the term "big-endian
    order" is for the most-significant-octet-first encoding.
 
+   The term "hash agility" is used to describe the ability of the protocol
+   to use a dynamic method of selecting a hash algorithm.  These algorithms
+   are inferred by the capabilities of the initiator.

@@ -454,10 +457,24 @@
 
    (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
        valid channel binding structure, the Bnd field SHALL be set to 16
        zero-valued octets.
 
+   When channel bindings are provided to GSS_Init_sec_context() [RFC2743]
+   the initiator SHALL support hash agility by populating the Bnd field
+   as previously described and by populating the extension field with the
+   following structure:
+
+       Octet	Name	Description
+       ---------------------------------------------
+	0..2	Cktype	Checksum extension type; Represented in little-endian
+			order; Currently contains the hex value 01 00 00 (1).
+	3..6	Cklgth	Number of octets in Cksum field;  Represented in little-
+			endian order.
+	7..last	Cksum	Channel binding information, as described in section
+			section 4.1.1.2.1.
+
    If the caller to GSS_Accept_sec_context [RFC2743] passes in
    GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the
    acceptor MAY ignore any channel bindings supplied by the initiator,
    returning success even if the initiator did pass in channel bindings.
 
@@ -467,10 +484,64 @@
    using major status GSS_S_BAD_BINDINGS [RFC2743].  In any case, the
    size of channel-binding data buffers that can be used (interoperable,
    without extensions) with this specification is limited to 4294967295
    octets.
 
+4.1.1.2.1 Channel Binding Extension
+
+   In order to provide hash agility for channel bindings, a checksum extension
+   SHALL be used for checksums that are non-MD4 based.  The value for this
+   extension contains the MAC based on the get_mic operation as described in
+   [RFC3961].
+
+   This value is calculated by the initiator and uses the following components:
+
+   (1) The session/sub (base) key is used to derive the specific key used
+       exclusively for channel binding extensions.  The key usage is a
+       32 bit integer and is assigned in hex, 6269 6e64 ("bind").
+       The derived key for channel binding extension checksums is:
+
+	Kc = DK(base-key, "bind" | 0x99)
+
+	where DK is the key-derivation function
+	where 0x99 is the octet that is concatenated to the key usage
+
+   (2) Based on the session/sub key the associated checksum algorithm is
+       is determined.  The following mapping lists the checksum types that
+       are discussed in [RFC3961] and for AES, [RFC3962]:
+
+	encryption type		etype	checksum type		ckval	cksize
+	----------------------------------------------------------------------
+	des-cbc-crc		1	rsa-md5-des		8	24
+	des-cbc-md4		2	rsa-md4-des		3	24
+	des-cbc-md5		3	rsa-md5-des		8	24
+	des3-cbc-sha1-kd	16	hmac-sha1-des3-kd	12	20
+	rc4-hmac		23	hmac-md5-arcfour	-138	16
+	rc4-hmac-exp		24	hmac-md5-arcfour	-138	16
+	aes128-cts-hmac-sha1-96 17	hmac-sha1-96-aes128	15	96
+	aes256-cts-hmac-sha1-96 18	hmac-sha1-96-aes256	16	96
+
+   (3) The message parameter is constructed the same way as the original
+       version described in 4.1.1.2.
+
+   The checksum function is passed the message and derived key as follows:
+
+	HMAC(Kc, message)[1..h]
+
+	where HMAC is the checksum function as defined in (2) above
+	where Kc is the specific key calculated in (1) above
+	where message is constructed in (3) above
+	where [1..h] represents 1-based indexing of leading substring output
+
+   If the acceptor receives a token that contains both the channel binding
+   extension field and the Bnd field then the Bnd field SHALL be ignored.  The
+   acceptor derives the arguments to supply the get_mic operator by
+   inferencing the session/sub key sent by the initiator and mapping this to
+   the corresponding checksum algorithm.  The acceptor then calls verify_mic
+   (decrypt and verify checksum).  This performs a comparison of the
+   initiator's MAC value to that of the acceptor's.
+
 4.2.  Per-Message Tokens
 
    Two classes of tokens are defined in this section: (1) "MIC" tokens,
    emitted by calls to GSS_GetMIC() and consumed by calls to
    GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 23 Aug 2006 17:40:51 -0700

1) you probably should populate the Bnd fields as is, to interop with
old servers without loosing the funtionality
2) can you put a typed hole in the extension fields, otherwise we will
loose the only extensible field.
3) I would like to see a typed hole added into the reply.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Shawn M Emery
Sent: Wednesday, August 23, 2006 10:45 AM
To: [email-masked]
Subject: Update to RFC4121

Folks,

Shawn.
--

---

From: Shawn M Emery <[email-masked]>
Date: Wed, 23 Aug 2006 21:13:47 -0600

> old servers without loosing the funtionality
Thanks for your reply.

The Bnd field is populated the same way as it was originally specified:
    ...
    the initiator SHALL support hash agility by populating the Bnd field
    as previously described and by populating the extension field with the
    following structure:
    ...
> loose the only extensible field.
I'll see what the consensus is for this.
> 3) I would like to see a typed hole added into the reply.
Can you give an example of when this would be used for this specific case?

Shawn.
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 24 Aug 2006 10:45:00 -0500

> I'll see what the consensus is for this.

We need extensibility.

> Can you give an example of when this would be used for this specific case?

This could be put off until we add extensions (in the request) that need
a hole in the reply.