Subject: [eap] [Issue] Changes to EAP methods

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Sep 2003 22:47:09 -0700 (PDT)

---------- Forwarded message ----------
Date: Wed, 3 Sep 2003 08:09:02 +0300 (IDT)
From: Hugo Krawczyk <[email-masked]>
To: [email-masked]
Subject: ipsec story

Hi Bernard, a week ago I sent the attached msg to the ipsec list in
rleation to the on-going discussion on whether to prohibit non-kg methods.

I received no response in the list and probably rightly so since this
issue belongs more to the eap wg than ipsec. Is there any reason why eap
could not standarized the proposed "context" field? Or do you see any
reason why this wouldn't be a simple and practical solution to the mitm
problem?

Your feedback would be much appreciated.

Hugo

---------- Forwarded message ----------
Date: Tue, 26 Aug 2003 07:12:43 +0300 (IDT)
From: Hugo Krawczyk <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Theodore Ts'o <[email-masked]>, IPsec WG <[email-masked]>
Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues)

On Wed, 20 Aug 2003, Jari Arkko wrote:

> Theodore Ts'o wrote:

> > So given this, I propose that we open a 48-hour discussion on this
> > issue.Should we (a) say nothing about non-kg types, thus implicitly
> > allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP
> > types, or (c) specify that vendors MUST NOT use non-kg EAP types?
>
> I'd prefer very much (c), but can live with (b).
>
> I think (c) is the best match to IKEv2's secure design.
> Weknow the MITM problem exists, and we know how to avoid
> it. According to the Bernard's method and RADIUS server
> information, we don't appear to have to suffer too much
> from choosing the secure approach...
>
> --Jari

Let me suggest that kg vs. non-kg should not be the issue here.

For this let me re-iterate a proposal I made in the past (in public and
private forums), namely, that EAP should add a new field called "context"
for all its methods. The value of "context" will be a protocol identifier
(or some other IANA generated value) that will indicate the context in
which the authentication method used. For example, when run as part of
802.xy the context will indicate an identifier pointing to 802.xy, when
run as part of some legacy application the context will be set
accordingly, and when run as part of ikev2 the context field will point to
"ikev2", etc.

By doing so, ANY CHALLENGE-RESPONSE EAP mechanism (either key-genrating or
not) can be immunized against the type of mitm attacks we are discussing.
Indeed, by including the "context" field under the information being
authenticated by the EAP method the whole mitm issue is solved!

This of course is not a sufficient solution for truly-legacy
authentication methods (which do not include this context field) but
neither are kg methods part of this "true legacy" systems.
Otoh, ALL legacy methods can be trivially sanitized (against "credential
abusing" mitm attacks) by simply including the context under the
authentication. This is much simpler (and architecturally correct, and
cryptographically sound, and much harder to misdeign!) than key-generating
methods. (The only method not saved by this addition is the simple user
name/passwd transmission; however for this protocol there is no way to
make it right: if it's run outside a tunnel then the passwd is available
to the attacker anyway)

Moreover, recent msgs from the EAP experts (Jari and Bernard)  suggested
that truly-legacy is not an issue since most systems are upgrading to
support newer methods (something they have to do anyway to enjoy the
benefits of kg methods).. If that's the case, then why not standarize this
"context" field as part of EAP and  put this (irritating) mitm issue
to rest forever?

Note that if such a field existed already we could have avoided the
additional AUTH fields in IKEv2-EAP.  Not only this would have been a
better solution in IKEv2 but a better solution for ALL situations where
this mitm issues arise. I claim that resorting to key-generating protocols
for solving this problems is:

(1) overkill: the tunnel protocols (such as IKEv2) generate their
own keys and trust those better than the "imported" keys from the
underlying EAP method

(2) complex and prone to design flaws: as we witnessed in IKEv2 there was
a need to add the additional AUTH fields to multiple msgs since one of the
peers (the initiator, I believe) cannot predict which one is the last msg
in the protocol, and different methods may generate the needed key at
different stages of the protocol run. Moreover, it was not really clear
which key from the EAP to take for producing these additional AUTH values
(and, as we learn from the recent posting to this lisr, these are not the
"right keys" from the standarized EAP perspective).

[This is indeed a very dangerous aspect of the "key binding" techniques
suggested for EAP: you need to make absolutely sure that the key you use
in the binding is NOT used for other purposes.]

The "capital sin" of the proposed EAP "tunnel binding" methods
is its layer violation (from which all the above defects follow):
a forced (blind) marriage that may not be expected to produce happy
children :)
That is what the "context" method tries to avoid.

Now, if I am misunderstanding the problem or the "rules of the EAP game",
please correct me.

Hugo

PS: Key-genrating EAP methods may have other well-thought purposes (for
example, establishing a secure session rather than simply authenticating
the session initiation), but this does no tmean that they add any value
(relative to authentication-only protocols) in the case of IKEv2 or other
(well designed) tunnel methods.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Wed, 3 Sep 2003 16:12:42 +0300

Hugo,

It seems that your message to the ipsec list disappeared 
somewhere (Ted said that several messages have went missing 
recently). At least it's not in the VPNC archives of the list.

Regarding your suggestion for including a "context identifier" 
in EAP methods: this has been suggested before (e.g. Jose 
Puthenkulam's Internet-draft about the "binding problem"). 
Indeed, it would fix the MITM problem for methods such as 
MD5-Challenge (CHAP).

However, it's not sufficient for mutually authenticating EAP 
methods (all of which generate keys, as far as I know). The 
AUTH payloads (based on EAP-generated key) would still be 
necessary to prevent a different MITM attack.

Consider, for instance, EAP-AKA. With current IKEv2 spec, 
the client can authenticate the server purely using AKA.
It doesn't have to use certificates at any point (it can
use the server's certificate to get some extra assurance
that it's talking to the right party, though). If the 
EAP-based AUTH payloads were removed, the server 
authentication would be based only on the certificates,
and any AKA information would be discarded (and thus we 
would lose much of the "extensibility" of EAP).

So, given that about the only EAP method helped by the "context 
identifier" would be MD5-Challenge, I don't think it's worth 
doing (it wouldn't solve the problems with OTP or GTC, and
it's not needed for key generating methods).

Best regards,
Pasi

---------- Forwarded message ----------
Date: Wed, 3 Sep 2003 08:09:02 +0300 (IDT)
From: Hugo Krawczyk <[email-masked]>
To: [email-masked]
Subject: ipsec story

Hi Bernard, a week ago I sent the attached msg to the ipsec list in
rleation to the on-going discussion on whether to prohibit non-kg
methods.

I received no response in the list and probably rightly so since this
issue belongs more to the eap wg than ipsec. Is there any reason why
eap could not standarized the proposed "context" field? Or do you see
any reason why this wouldn't be a simple and practical solution to the
mitm problem?

Hugo

> > > So given this, I propose that we open a 48-hour discussion on 
> > > this issue.Should we (a) say nothing about non-kg types, thus 
> > > implicitly allowing them, (b) specify that vendors SHOULD NOT 
> > > use non-kg EAP types, or (c) specify that vendors MUST NOT 
> > > use non-kg EAP types?
> >
> For this let me re-iterate a proposal I made in the past (in public
> and private forums), namely, that EAP should add a new field called
> "context" for all its methods. The value of "context" will be a
> protocol identifier (or some other IANA generated value) that will
> indicate the context in which the authentication method used. For
> example, when run as part of 802.xy the context will indicate an
> identifier pointing to 802.xy, when run as part of some legacy
> application the context will be set accordingly, and when run as
> part of ikev2 the context field will point to "ikev2", etc.
>
> By doing so, ANY CHALLENGE-RESPONSE EAP mechanism (either
> key-genrating or not) can be immunized against the type of mitm
> attacks we are discussing.  Indeed, by including the "context" field
> under the information being authenticated by the EAP method the
> whole mitm issue is solved!
>
> neither are kg methods part of this "true legacy" systems.  Otoh,
> ALL legacy methods can be trivially sanitized (against "credential
> authentication. This is much simpler (and architecturally correct,
> and cryptographically sound, and much harder to misdeign!) than
> key-generating methods. (The only method not saved by this addition
> is the simple user name/passwd transmission; however for this
> protocol there is no way to make it right: if it's run outside a
> tunnel then the passwd is available to the attacker anyway)
> 
> Moreover, recent msgs from the EAP experts (Jari and Bernard)
> suggested that truly-legacy is not an issue since most systems are
> upgrading to support newer methods (something they have to do anyway
> to enjoy the benefits of kg methods).. If that's the case, then why
> not standarize this "context" field as part of EAP and put this
> (irritating) mitm issue to rest forever?
> 
> additional AUTH fields in IKEv2-EAP.  Not only this would have been
> a better solution in IKEv2 but a better solution for ALL situations
> where this mitm issues arise. I claim that resorting to
> key-generating protocols for solving this problems is:
>
> (2) complex and prone to design flaws: as we witnessed in IKEv2
> there was a need to add the additional AUTH fields to multiple msgs
> since one of the peers (the initiator, I believe) cannot predict
> which one is the last msg in the protocol, and different methods may
> generate the needed key at different stages of the protocol
> run. Moreover, it was not really clear which key from the EAP to
> take for producing these additional AUTH values (and, as we learn
> from the recent posting to this lisr, these are not the "right keys"
> from the standarized EAP perspective).
> 
> [This is indeed a very dangerous aspect of the "key binding"
> techniques suggested for EAP: you need to make absolutely sure that
> the key you use in the binding is NOT used for other purposes.]
> 
> The "capital sin" of the proposed EAP "tunnel binding" methods is
> its layer violation (from which all the above defects follow): a
> forced (blind) marriage that may not be expected to produce happy
> children :) That is what the "context" method tries to avoid.
> 
> Now, if I am misunderstanding the problem or the "rules of the EAP
> game", please correct me.
> 
> Hugo
> 
> PS: Key-genrating EAP methods may have other well-thought purposes
> (for example, establishing a secure session rather than simply
> authenticating the session initiation), but this does no tmean that
> they add any value (relative to authentication-only protocols) in
> the case of IKEv2 or other (well designed) tunnel methods.

---

From: <[email-masked]>
Date: Fri, 5 Sep 2003 15:51:21 +0300

Hi,

I agree that there is little need for EAP generated keys _if_ 
the server authentication is not extensible, only client 
authentication. But I think this would be an unnecessary 
limitation. After all, if the point of EAP (which is, after all, 
the _E_xtensible Authentication Protocol) is to allow users to 
choose an authentication method that suits their needs, why 
should this be limited to client authentication?

For instance, in the EAP-AKA case, the client already has a 
perfectly good and secure way of authenticating the server 
(with AKA). If using that was forbidden in e.g. IKEv2, the 
client would be forced to use something else that's most 
likely less secure in practise. (It would require that the 
client gets the CA certificate and server's DN/FQDN from 
somewhere--and I'm not even thinking about certificate
revocation yet. And all of this would be totally unnecessary,
and would only make the whole less secure.)

So, I still think that exporting a key from EAP is the correct 
way to bind the tunnel and EAP together. The other alternative
that would also work is to import some cryptographic "context" 
from the tunnel (IKEv2) to EAP method--but this would be something 
like a hash of the first two IKEv2 packets (like in AUTH payloads),
not just a single byte saying "IKEv2". This would require changes 
not just to all EAP methods, but also to the AAA infrastructure 
(to transport the context hash from IKEv2 server to backend AAA 
server), so I think there's little reason to do that.

Best regards,
Pasi

> -----Original Message-----
> From: ext Hugo Krawczyk [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 1:19 AM
> To: Eronen Pasi (NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: [eap] [Issue] Changes to EAP methods
> 
> The addition of the "context" field will solve the mitm problem for
> ALL situations in which the tunneling application is well designed,
> well implemented, and well practiced. In these cases there is no
> need for the EAP-generated keys AT ALL (in particular, it is
> perfectly ok if the EAP method does not generate keys). In
> particular, this is the case in IKE.  Of course, I am assuming that
> in IKE the public key of the responder (the server in this case) is
> verified by the initiator (who either has the server's PK or
> verifies it against a certificate). If you run IKE without making
> sure you have the right PKs (or certificates) then you deserve the
> mitm attacks...

> Can I "officially" request that the EAP WG consider adding the
> context field? Even those that fall in love with key-generating
> methods (which certainly have many merits outside the tunneled
> applications), should still recognize that a "context" variable is a
> good cryptographic practice in any authentication situation.
> 
> Hugo
> 
> PS: I am not subscribed to the list so if you follow up on this and
> want me to see the msg please re: me.