Subject: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Oct 2006 08:39:52 +0300

Madjid,

I am responding to you on the ipsec list instead of the
other ones because this question belongs there.
> Sorry for hijacking this email for something that might seem as an unrelated
> topic. The following may be a personal misunderstanding or may be that the
> fact that many of EAP methods have not been formally standardized by IETF
> have some impact on the use of EAP elsewhere:
>
> IETF has published IKEv2 as RFC4306 less than a year ago and included use of
> EAP methods as an alternative method in performing authentications required
> for Internet key exchange. However, even though the text states (section
> 2.16):
>
>    "...this memo references [EAP] with the intent that new methods can
>    be added in the future without updating this specification..."
>
> Still in the same section it is stated:
>
>    "In addition to authentication using public key signatures and shared
>    secrets, IKE supports authentication using methods defined in RFC
>    3748 [EAP].  Typically, these methods are asymmetric (designed for a
>    user authenticating to a server), and they may not be mutual.  For
>    this reason, these protocols are typically used to authenticate the
>    initiator to the responder and MUST be used in conjunction with a
>    public key signature based authentication of the responder to the
>    initiator.  These methods are often associated with mechanisms
>    referred to as "Legacy Authentication" mechanisms."
>
> I am guessing "legacy authentication" mean EAP methods listed in 3748 and
> the text possibly refers to some specific EAP methods (at the time, such as
> possibly EAP-TLS or EAP-TTLS) that required use of public keys or it is
> actually requiring the use of public keys for every EAP method that is used
> with IKEv2.
>
> Clarification is appreciated, as EAP for IKEv2 is now being used in some WGs
> quite seriously.
I agree that the text is open for interpretation.

However, the RFC also talks about, for instance, EAP
methods that generate keys. All such methods were
defined outside RFC 3748, so this implies that the
intention is to support all methods, even beyond those
included in RFC 3748 itself.

Secondly, the text about the public key signature based
authentication refers to the *IKEv2* public key
authentication of the responder. That is, it does not
specify anything about the use of public keys within
the EAP method. See also draft-eronen-ipsec-ikev2-eap-05.txt.

Hope this helps,

--Jari

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Oct 2006 14:25:24 +0300

> > I am guessing "legacy authentication" mean EAP methods listed in 3748 and

The name "legacy authentication" comes from the history, i.e. it
refers to all kind of "legacy authentication" infrastructures
(SecurID, one time password etc) that had already existing
infrastructure that could not be used for the normal IKE
authentication methods (i.e. certificates or shared keys).

As IKEv2 wanted to solve the problem with those "legacy
authentication" the EAP was added to the IKEv2. I.e. EAP can be used
to solve the problem with the "legacy authentication", but it can also
be used for other purposes.

So the "legacy authentication" in the RFC 4306 refers to those old
authentication methods, which could not directly be used by the IKEv2,
but whose infrastructure can be used by wrapping those methods to the
EAP.

I think the 2.16 is clear enough about that.

> > actually requiring the use of public keys for every EAP method that is used

In the IKEV2 the authentication can be asymmetric, i.e. different
authentication methods can be used in different directions. The text
in the RFC4306 says that you MUST use IKEv2 signature based
authentication methods to authenticate the responder to the
iniatiator if you want to use EAP based authentication method to
authenticate the initiator to the responder.

In effect this text says that you MUST NOT use IKEV2 shared secret
based authentication methods to authenticate the responder to
initiator if you want to use EAP based method to authenticate the
initiator to the responder.

And it also means that you MUST NOT use EAP based authentication
methods to authenticate both initiator and responder to each other.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Oct 2006 14:25:46 +0300

Madjid Nakhjiri writes:
> Madjid>>I am trying to understand why this requirement was put in the text.
> Is this to allow responder to act as an EAP pass-through authenticator,
> while the initiator is authenticating to a central EAP server (behind the
> responder)? Or is it due to the assumed asymmetry in EAP methods.

The main rationale is that it makes security analysis of the protocol
much easier. I.e. if we know after first 2 packet exchanges that the
responder is indeed who we intended to talk to and that there is no
man in the middle modifying our packets, it short circuits the
security analysis there. Otherwise we would need to extend the
security analysis to the end of the EAP exchange and then try to make
sure that it actually did check against all posssible kind of attacks
(including attacks where there was man in the middle modifying the
EAP etc packets).

During IKEv2 protocol development nobody had time to make the proper
analysis that the protocol is still safe if shared secret generating,
EAP method who provides mutual authentication is used.

Also note, that most of the EAP methods (especially the those needed
for the "legacy authentication" infrastructures (SecurID, one time
passwords etc)) do not provide the security features required to make
the protocol safe without the authentication of the responder.

As the EAP in IKEv2 was originally meant to mostly solve those "legacy
authentication" issues, this kind of EAP only support was not seen as
mandatory.

The reason why it only allows public keys, not shared keys, is to
discourage using group shared keys. I.e. if the initiator would
require to have unique shared secret with the gateway before it can
connect, why would it need to use EAP at all. It could then
authenticate himself already with the shared secret.

So in normal usage scenario the initiator (client) will have the CA of
the server configured, but it does not have private key and
certificate for himself, nor shared secret. It will have the "legacy
authentication" infrastructure information that will allow it to run
EAP. The CA certificate configure to the initiator is used to verify
that the signature created by the responder is valid and that will
authenticate the responder. The EAP is used to authenticate the
initiator.

There is a draft (draft-eronen-ipsec-ikev2-eap-auth-05.txt) that is
now in the RFC editor queue about this mutual authentication.
-- 
[email-masked]

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 19 Oct 2006 08:44:36 -0700

>now in the RFC editor queue about this mutual authentication.

Still in "ID exists" status from what I can tell :).  That draft does 
offer some clarification on this issue.

Some thoughts: The IKEv2-EAP model as in case of 4306 allows the EAP 
peer/IKEv2 initiator to authenticate the Authenticator/IKEv2 
responder independent of the EAP method exchange and the subsequent 
MSK.  Of course, the model comes handy especially if there is no MSK 
to be delivered (although there are security issues there -- 4306 has 
notes).  This model is also useful when the Authenticator and the AS 
are collocated.

On Madjid's question, whether or not the EAP method is a tunneled 
method is independent of the IKEv2 Responder authentication and the 
corresponding secure tunnel.  The "tunnel" end points in the two 
cases are different.

Pasi and Hannes's draft makes the model more inline with the EAP 
model of authentication, where the peer and the authenticator 
authenticate each other using the MSK.

Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Oct 2006 16:09:30 +0300

> offer some clarification on this issue.

True, mixed that with the another EAP draft from the Eronen
(multiple-auth) which is in the RFC editor queue. That happens when
you check things too quickly...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Oct 2006 12:39:40 +0300

Madjid Nakhjiri writes:
> Madjid>>Ok, so it seems that EAP as an authentication method was not quite
> established. However, it also seems that EAP was considered in its native
> (3748) 2 party sense, while it is commonly deployed in a scenario where the
> responder doing IKEv2 is actually not one of the EAP parties, but a
> pass-through (authenticator in EAP terminology).
> 
> IKEv2:  Initiator-----------------Responder
> EAP:    peer----------------------pass-through--------EAP server

In IKEv2 both EAP uses were considered, and the pass-through model is
the more common, but to make that mode secure, the pass-through
responder MUST get the keying material from the EAP server so it can
tie up the IKEv2 exchange to the EAP exchange. 

> and in that case, measures preventing MITM by responder are needed indeed,
> since the responder does not take a part in EAP authentication. Instead the
> EAP server sends a secret generated by EAP to the pass-through entity. Some
> environments that use EAP in that type of deployment do require the EAP peer
> and the pass-through entity to do an authentication exchange through which
> the pass-through entity shows that it in fact did receive that secret from
> the EAP server. It would seem that IKEv2 should do the same rather than
> relying on responder public key that is outside EAP process.

IKEv2 do mandate that method, i.e. in addition to public keys for the
responder it do require to get the MSK of the EAP exchange so it can
calculate second AUTH payload. In case the method is non-key
generating and MSK is generated, then it do allow exchange to continue
and is still somewhat secure because of the requirement of the public
key authentication of the responder.

> Having said that, there could be a requirement for using EAP in
> IKEv2: "the used EAP method must be able to produce keys".

That would be against the original idea of using EAP to solve the
problem to the "legacy authnetication" infrastructures. Those
SecureID, one time password etc methods already there do not normally
generate keys.

> Madjid>>The problem here is that some network protocols such as Mobile IP
> are using IPsec to secure signaling between a host and their agents and
> relying on use of EAP for the IKEv2 preceding IPsec. Yes, EAP will provide
> the flexibility of not issuing the clients with certs, but the above would
> mean the agents would need to be issued certificates. Less of admin burden
> but nonetheless...

Yes, but the number of private/public key pairs generated for the
agents is much smaller. Also even when shared secrets would be used
that would require generiting different shared secret for each client,
thus requiring much more adminstrative work.

EAP only method would be even less admin work, but as that is not
currently allowed in the IKEv2, you must simply generate the private /
public key pair for the agent. Note, that there is NO requirement to
use certificates there, only public key signatures, i.e. the agent can
have bare RSA key configured for it and that public key is then
distributed to the clients along with the other configuration data.
-- 
[email-masked]