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

Re: EAP Handling in IKEv2




Hugo Krawczyk wrote:

> 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.

Yes, this is also one of the proposed approaches for
dealing with MitM.

I agree that it works.

I'm not 100% sure which way is easier, certainly this
would be easier than designing a new kg method. But
it might also be the case that the RADIUS server being
used already supports EAP MS-CHAPv2 (for instance) which
can be used if you have passwords. So switching to an
existing kg method is of course even easier.

> 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.

Right.

--Jari