Subject: [abfab] Message Integrity for gss-eap

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2011 04:03:23 -0400

Folks, during today's meeting we discussed the need for protecting
information exchanged during the context exchange.

An example of this need would be protecting context flags from the
client to the server.
Some server implementations require that certain context flags be set.
As an example ssh servers following RFC 4462 require the mutual flag be
set.
This needs to be integrity protected.

There are a number of possible options:

1) Integrity protect each token separately. Down side: more complex
especially if tokens need integrity protection that are exchanged before
a key is available.

2) Extend our mechanism to depend on a specific hash function.
Disadvantage: requires us dealing with crypto primitives directly . Adds
complexity to specificiation of the mechanisms.

3) Provide a gss_getmic or similar of the entire conversation.  The
disadvantage here is that the client needs to maintain state sufficient
to hold a copy of the conversation. If there is a stateless server, this
ever-increasing state needs to be transported back and forth for each
message.

--Sam

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2011 11:48:23 +0200

Hi Sam,

I was not able to follow the discussion about this particular topic, but I would like to ask a question. The use of EAP authentication over an unprotected link is something we can see over there. In fact, the use of EAP methods that export key material are used to bootstrap a security association at EAP lower-layer.

I was wondering what are the exact implications of not protecting the information until the EAP authentication ends up with  a key. If certain particular flags are unset during the conversation because it is not protected, the negotiation should fail, right?. So some sort of denial-of-service problem will raise. Is that what you had in mind?. 

I say this because, as you may know, there are some EAP lower-layers which does not need to assume that there will be a pre-established protected channel to exchange EAP. 

Best regards.

El 31/03/2011, a las 10:03, Sam Hartman escribió:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Luke Howard <[email-masked]>
Date: Thu, 31 Mar 2011 21:06:27 +1100

> I was wondering what are the exact implications of not protecting the information until the EAP authentication ends up with  a key. If certain particular flags are unset during the conversation bec…

Right, it should fail. If there is no integrity protection of, in this case, the client-requested-mutual-authentication flag, then it would silently succeed.

-- Luke

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 31 Mar 2011 13:22:06 +0200

Sam,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Thursday, March 31, 2011 10:03 AM
> To: [email-masked]
> Subject: [abfab] Message Integrity for gss-eap
> 
> 
> 
> An example of this need would be protecting context flags from the client
to
> the server.
set.
> especially if tokens need integrity protection that are exchanged before a
> key is available.

I think there is another possible downside here that needs to be considered,
without having a mic on all of the data that you are trying to protect,
there is a possibility that either something that should be mic-ed isn't or
something that is mic-ed is removed from the set.

Jim

> disadvantage here is that the client needs to maintain state sufficient to
hold
> a copy of the conversation. If there is a stateless server, this
ever-increasing
> state needs to be transported back and forth for each message.
> 
> --Sam

---

From: Luke Howard <[email-masked]>
Date: Thu, 31 Mar 2011 22:30:55 +1100

> something that is mic-ed is removed from the set.

Right, although a MIC that requires ordering (i.e. has sequence numbers) can mitigate against this. I do think though that if we can find an inexpensive way to protect the entire conversation, it simplifies things considerably, and will make it easier to add extensions in the future.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2011 08:01:33 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> I was wondering what are the exact implications of not
    Rafa> protecting the information until the EAP authentication ends
    Rafa> up with a key. If certain particular flags are unset during
    Rafa> the conversation because it is not protected, the negotiation
    Rafa> should fail, right?. So some sort of denial-of-service problem
    Rafa> will raise. Is that what you had in mind?.

If we have protection. then an attacker can cause a denial of service by
changing the negotiation.
However, in the case of the mutual authentication flag, if we don't have
protection, there is a more serious attack.
In that situation, an attacker can set the mutual authentication flag
when the mutual authentication did not happen.
The server may think the client confirmed the server's identity when
that did not happen.

We can protect this after the key is established by sending some
checksum or keyed hash that covers the flag in question.

    Rafa> I say this because, as you may know, there are some EAP
    Rafa> lower-layers which does not need to assume that there will be
    Rafa> a pre-established protected channel to exchange EAP.

abfab is such a lower layer.

    Rafa> Best regards.

    Rafa> El 31/03/2011, a las 10:03, Sam Hartman escribió:

    >> 
    >> 
    >> Folks, during today's meeting we discussed the need for
    >> protecting information exchanged during the context exchange.
    >> 
    >> An example of this need would be protecting context flags from
    >> the client to the server.  Some server implementations require
    >> that certain context flags be set.  As an example ssh servers
    >> following RFC 4462 require the mutual flag be set.  This needs to
    >> be integrity protected.
    >> 
    >> 1) Integrity protect each token separately. Down side: more
    >> complex especially if tokens need integrity protection that are
    >> exchanged before a key is available.
    >> 
    >> Disadvantage: requires us dealing with crypto primitives directly
    >> . Adds complexity to specificiation of the mechanisms.
    >> 
    >> 3) Provide a gss_getmic or similar of the entire conversation.
    >> The disadvantage here is that the client needs to maintain state
    >> sufficient to hold a copy of the conversation. If there is a
    >> stateless server, this ever-increasing state needs to be
    >> transported back and forth for each message.
    >> 
    >> --Sam _______________________________________________ abfab
    >> mailing list [email-masked]

    Rafa> ------------------------------------------------------- Rafael
    Rafa> Marin Lopez, PhD Dept. Information and Communications
    Rafa> Engineering (DIIC) Faculty of Computer Science-University of
    Rafa> Murcia 30100 Murcia - Spain Telf: +34868888501 Fax:
    Rafa> +34868884151 e-mail:
    Rafa> [email-masked] -------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2011 15:35:42 +0200

Hi Luke,

> Right, it should fail. If there is no integrity protection of, in this case, the client-requested-mutual-authentication flag, then it would silently succeed.

However, in my mind you may confirm the value of that flag seen by both parties with an integrity-protected "binding" exchange after the key material has been exported by the EAP authentication.

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 00:53:06 +1100

Hi Rafa,

> However, in my mind you may confirm the value of that flag seen by both parties with an integrity-protected "binding" exchange after the key material has been exported by the EAP authentication.

Yes, this is (more or less) what we're proposing. If you want to see an possible approach I tried, you can see the tlv-mic branch of Moonshot.

-- Luke

---

From: Leif Johansson <[email-masked]>
Date: Thu, 31 Mar 2011 15:55:01 +0200

> Yes, this is (more or less) what we're proposing. If you want to see an possible approach I tried, you can see the tlv-mic branch of Moonshot.

Luke can I get you to formulate that approach in English for those of
us who do not track moonshot code.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2011 09:55:18 -0400

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

    Nico> If this were the only unauthenticated plaintext requiring
    Nico> protection... then you could require that all such flags be
    Nico> set that the mechanism supports.

We can try to do this.
The catch comes in because the mechanism may support features the
environment does not.
For example, we will require behavior out of EAP channel binding; see
the draft.

If the server does not verify the right attributes in channel binding
then we will not indicate mutual auth to the initiator.
It's desirable especially for RFC 4462 to also not indicate mutual to
the acceptor in this case.
Thus, an authenticated flag requirement.

--Sam

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2011 16:05:03 +0200

Hi Luke,

> Yes, this is (more or less) what we're proposing. If you want to see an possible approach I tried, you can see the tlv-mic branch of Moonshot.

Yes, we had also thought about this "binding" and that it is why I was commenting it.

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 01:05:49 +1100

Leif,

On 01/04/2011, at 12:55 AM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

When the initiator has sent its last token, it calls GSS_GetMIC on the entire conversation (including the last leg excepting the MIC). The MIC is sent in a TLV-tagged token along with other extension tokens (currently only one is defined for the initiator, containing GSS channel binding information).

The acceptor verifies the initiator MIC and then, in its last leg, calls GSS_GetMIC on the entire conversation (including both last legs, excepting the acceptor MIC) and sends it in an extension token to the initiator. The initiator verifies the acceptor MIC before returning GSS_S_COMPLETE. (It is true that this approach does require the client and server to maintain the entire conversation state.)

With respect to communicating the mutual authentication state, a new TLV token type is defined containing a 32-bit integer in network byte order, which consists of req_flags as passed to GSS_Init_sec_context. These flags are masked by, currently, GSS_C_MUTUAL_FLAG before encoding. Other flags may be allowed in the future; at this stage we do not wish to reveal in plaintext anything more than the mutual authentication state.

Once the acceptor returns GSS_S_COMPLETE, it will set the received mutual authentication state in ret_flags.

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2011 16:10:42 +0200

Hi Sam,

> checksum or keyed hash that covers the flag in question.

That is precisely what I had in mind. Moreover I agree with Alper about the use of EAP methods that only requires one-way authentication are not convenient at all. Even more I cannot remember now if there is any EAP method with one-way authentication which export keys and can be considered as a secure solution. 

> abfab is such a lower layer.

I know abfab is the lower-layer, but I thought the discussion was related with the possible need to protect the abfab lower-layer BEFORE the EAP authentication.

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 01:14:24 +1100

> With respect to communicating the mutual authentication state, a new TLV token type is defined containing a 32-bit integer in network byte order, which consists of req_flags as passed to GSS_Init_s…

This token is sent in the last leg by the initiator. It is not marked critical; if the acceptor does not receive it, after verifying the initiator MIC, it should assume the client did not do mutual authentication.

I also prototyped an extension negotiation mechanism: at the start the initiator can send an extension token containing a set of types indicating the acceptor extensions it accepts; and the acceptor can do the converse. See below for a list of token types:

#define ITOK_TYPE_NONE                      0x00000000
#define ITOK_TYPE_CONTEXT_ERR               0x00000001 /* critical */
#define ITOK_TYPE_ACCEPTOR_NAME_REQ         0x00000002 /* TBD */
#define ITOK_TYPE_ACCEPTOR_NAME_RESP        0x00000003 /* TBD */
#define ITOK_TYPE_EAP_RESP                  0x00000004 /* critical, required, if not reauth */
#define ITOK_TYPE_EAP_REQ                   0x00000005 /* critical, required, if not reauth */
#define ITOK_TYPE_GSS_CHANNEL_BINDINGS      0x00000006 /* optional */
#define ITOK_TYPE_REAUTH_CREDS              0x00000007 /* optional */
#define ITOK_TYPE_REAUTH_REQ                0x00000008 /* optional */
#define ITOK_TYPE_REAUTH_RESP               0x00000009 /* optional */
#define ITOK_TYPE_GSS_FLAGS                 0x0000000A /* optional */
#define ITOK_TYPE_INITIATOR_MIC             0x0000000B /* required */
#define ITOK_TYPE_ACCEPTOR_MIC              0x0000000C /* required */
#define ITOK_TYPE_SUPPORTED_ACCEPTOR_EXTS   0x0000000D /* optional */
#define ITOK_TYPE_SUPPORTED_INITIATOR_EXTS  0x0000000E /* optional */

Again, this is mostly my private experimentation, it's not in the main Moonshot branch and I'm not advocating either way vis ABFAB.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 01:16:26 +1100

> I know abfab is the lower-layer, but I thought the discussion was related with the possible need to protect the abfab lower-layer BEFORE the EAP authentication.

You can protect parts of the conversation that happen before the EAP authentication, you just can't verify them until afterwards.

There was a separate question in the meeting about protecting application data that happens before EAP authentication (such as SASL mechanism negotiation), I suggested that you could use GSS channel bindings to protect this. Or you could restart the negotiation within an integrity protected channel.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 09:30:09 -0500

[resend]

> This needs to be integrity protected.

If this were the only unauthenticated plaintext requiring
protection... then you could require that all such flags be set that
the mechanism supports.

> especially if tokens need integrity protection that are exchanged before

You'd have to store or re-create those messages that come before kwy exchange.

> complexity to specificiation of the mechanisms.

Also, hash agility.  TLS 1.2 didn't do this in a well performing way
and you'd have the same problem (you can't know a priori which hash
function you'll negotiate, so you either use them all as you go or
keep the messages.

> ever-increasing state needs to be transported back and forth for each

4) Re-construct those messages near the end of the exchange, storing
only iyems such as nonces in the interim.

Nico
--

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 31 Mar 2011 16:34:16 +0200

> The acceptor verifies the initiator MIC and then, in its last leg, calls GSS_GetMIC on the entire conversation (including both last legs, excepting the acceptor MIC) and sends it in an extension to…

Maybe this is just a stupid question, but do they really need to 
maintain state of the entire conversation? I mean, both parties could 
just maintain the result of a hash over the conversation so far, built 
in an iterative way. Something like this:

state' = hash (state, new_message)

At the end of the conversation, they could compute GSS_mic over the state.

May be the overload of computing such hashes is worse than the memory 
needed to store the entire state.

Regards,
Alejandro

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 01:36:29 +1100

> only iyems such as nonces in the interim.

That's a pretty clever idea, but -- if you're talking about reconstructing the entire EAP exchange -- I don't think it would be very practical from an implementation standpoint, particularly when a AAA server is involved.

A simple option, if we keep this last-round-trip extension exchange, is to protect just that. It assumes that we'll never send an extension token in an earlier leg that requires integrity protection. (And, given we might want to do extension negotiation for something we haven't thought of yet, and avoid downgrade attacks, my gut feeling is that protecting the entire conversation is something we should bake into the protocol now if it's not too expensive.)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 01:39:21 +1100

> Maybe this is just a stupid question, but do they really need to maintain state of the entire conversation? I mean, both parties could just maintain the result of a hash over the conversation so far, built in an iterative way. Something like this:
> 
> May be the overload of computing such hashes is worse than the memory needed to store the entire state.

It's not this so much. The problem is hash agility: we want GSS EAP to use the crypto primitives provided by RFC 3961, and this does not have a primitive for incrementally updating a checksum. So, we could extend RFC 3961 (which, wearing my implementors' hat, will involve some fairly intrusive changes to the popular Kerberos implementations). Or we could use a fixed checksum algorithm, but that's brittle and makes the entire protocol vulnerable if a weakness is ever discovered. Or we could build in some mechanism for negotiating checksum algorithms, but that risks re-inventing the wheel.

Sam or Nico can explain this better than I, I'm sure.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2011 10:45:11 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    >> The acceptor verifies the initiator MIC and then, in its last
    >> leg, calls GSS_GetMIC on the entire conversation (including both
    >> last legs, excepting the acceptor MIC) and sends it in an
    >> extension token to the initiator. The initiator verifies the
    >> acceptor MIC before returning GSS_S_COMPLETE. (It is true that
    >> this approach does require the client and server to maintain the
    >> entire conversation state.)

    Alejandro> Maybe this is just a stupid question, but do they really
    Alejandro> need to maintain state of the entire conversation? I
    Alejandro> mean, both parties could just maintain the result of a
    Alejandro> hash over the conversation so far, built in an iterative
    Alejandro> way. Something like this:

This is not a stupid question.
elThis is what I was trying to explain with my option 2 above.

The down side is you must decide on/negotiate a particular cryptographic
hash.

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 09:50:20 -0500

On Thu, Mar 31, 2011 at 9:34 AM, Alejandro Perez Mendez <[email-masked]> wrote:
> Maybe this is just a stupid question, but do they really need to maintain
> state of the entire conversation? I mean, both parties could just maintain
> the result of a hash over the conversation so far, built in an iterative
> way. Something like this:
>

That's what TLS does.  It's clever, and it works, but you get into
hash agility issues.  If you need to negotiate a hash function (and
you will), then you find yourself back at square #1 because at least
for the first N messages, where N >=1 (but probably N == 1) you don't
know what the hash algorithm will be.  Either you use all your hash
functions (whoops!  slow!) or you hold the message(s) in memory
(expensive).

The good news is that most new phones and such devices have enough
memory for this (and then some).

Nico
--

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2011 21:26:44 +0200

Hi Luke,

> You can protect parts of the conversation that happen before the EAP authentication, you just can't verify them until afterwards.

That is clear.

> 
> There was a separate question in the meeting about protecting application data that happens before EAP authentication (such as SASL mechanism negotiation), I suggested that you could use GSS channel bindings to protect this.

I see.
> Or you could restart the negotiation within an integrity protected channel.

Exactly. That integrity protected channel can be derived from the EAP key material and can be used to securely confirm the parameters exchanged during the unsecured negotiation phase.

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 14:46:04 -0500

> That's a pretty clever idea, but -- if you're talking about reconstructing the entire EAP exchange -- I don't think it would be very practical from an implementation standpoint, particularly when a…

Right, but you might be able to minimize what messages you must cache.
 Keep in mind that I'm not following all the details of your
mechanism, thus I might write something like the above that might not
make any sense in the context of your mech.

> A simple option, if we keep this last-round-trip extension exchange, is to protect just that. It assumes that we'll never send an extension token in an earlier leg that requires integrity protectio…

We've seen the unauthenticate plaintext movie, and remakes.  They
usually don't feature a happy ending.

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 09:31:56 +1100

Note with GSS EAP we don't need to negotiate the hash function inside our mechanism because it falls out of the enctype, and that in turn from the mech OID, so GSS negotiates for us. Assuming you only want to use the mandatory checksum type, of course.

Von meinem iPhone gesendet

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 17:35:19 -0500

On Mar 31, 2011 5:32 PM, "Luke Howard" <[email-masked]> wrote:
>
> Note with GSS EAP we don't need to negotiate the hash function inside our
mechanism because it falls out of the enctype, and that in turn from the
mech OID, so GSS negotiates for us. Assuming you only want to use the
mandatory checksum type, of course.

In that case I'd just bite the bullet and use a hash function and a MIC of
the hash.  There's costs to this approah, but it seems likely that those
will be more acceptable than the alternatives'.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 09:43:17 +1100

The problem with this approach is that we end up reimplementing RFC 3961. It's possible now to build an enctype-agnostic implementation, and this would make that harder, at least with the APIs provided by shipping Kerberos implementations.

-- Luke

On 01/04/2011, at 9:35 AM, Nico Williams wrote:

> In that case I'd just bite the bullet and use a hash function and a MIC of the hash.  There's costs to this approah, but it seems likely that those will be more acceptable than the alternatives'.
> 
> Nico
> --
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 18:33:29 -0500

On Thu, Mar 31, 2011 at 5:43 PM, Luke Howard <[email-masked]> wrote:
> The problem with this approach is that we end up reimplementing RFC 3961.
> It's possible now to build an enctype-agnostic implementation, and this
> would make that harder, at least with the APIs provided by shipping Kerberos
> implementations.

I don't follow.  A hash algorithm would be used entirely outside the
RFC3961 framework, and the MIC would be the same that the mechanism
surely must already support.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 1 Apr 2011 10:34:08 +1100

> surely must already support.

OK, but how do we choose the hash algorithm?

-- Luke