[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EAP Handling in IKEv2



> 
> > If so, it may be possible to keep the credentials as they are but
> > replace the existing method with a modified one when running inside IKEv2.
> > When running outside IKEv2 or other sort of "EAP tunnels", use the existing
> > method as-is.
> 
> Yes, this "modified method" approach is one of the proposals for dealing
> with non-key generating methods.
> 

I like the distinction between reusing "legacy credentials" as opposed to
reusing "legacy methods". However, this means that we are willing to
*change* the authentication methods traditionally used by the "legacy
credentials". If this is a practical approach (namely, it can gain
widespread support in corporate organizations, etc) then the solution is
very simple and does not require the design of key-generating methods. 
All is needed is that the modified methods authenticate the "context" in
which they are run. Specifically, when run with ikev2 the authenticated
information should include a unique "protocol identifier" (such as
"ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least
"intrusive" solution to the man in the middle problem while allowing use
of the same credentials in different contexts.

INPORTANT NOTE: Even in this case let's keep in mind that if the
credential used under an EAP method in ikev2 has low entropy (such as a
password) and is also used in another method that is vulnerable to
off-line dictionary attacks then its use in ikev2 becomes insecure too.

Hugo

>