Subject: [abfab] MIC on extension token

From: Luke Howard <[email-masked]>
Date: Fri, 20 May 2011 13:57:10 +0200

We went back and forth on the usefulness and implementability of the conversation MIC in GSS EAP. Recall that it was difficult to have more than two of hash agility, minimum state and RFC 3961 compatibility. Even the key confirmation approach would have required changes to RFC 3961 and many existing Kerberos libraries (because there is no Update function).

Instead I propose (well, Sam proposes and I implemented) the following. On the initiator extension token leg (the last token from the initiator), a MIC is sent of the mechanism OID and the extension tokens, excluding the MIC token. The acceptor verifies it and generates a MIC of its extension token to send to the initiator. The initiator verifies this.

This gives us protection of all extension tokens sent in the last round trip.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 May 2011 10:57:15 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Instead I propose (well, Sam proposes and I implemented) the
    Luke> following. On the initiator extension token leg (the last
    Luke> token from the initiator), a MIC is sent of the mechanism OID
    Luke> and the extension tokens, excluding the MIC token. The
    Luke> acceptor verifies it and generates a MIC of its extension
    Luke> token to send to the initiator. The initiator verifies this.

    Luke> This gives us protection of all extension tokens sent in the
    Luke> last round trip.

I'd like to hear comments on this.  Unless we hear objections or the
editors receive different instructinos from the chairs, we will make
this so in the next version of the gss-eap draft.

---

From: Luke Howard <[email-masked]>
Date: Tue, 31 May 2011 17:13:34 -0400

> this so in the next version of the gss-eap draft.

+1 from me.

-- Luke