Re: Secure legacy authentication for IKEv2

[David Jablon <dpj@theworld.com>]

Regarding the "points of agreement" summary, some points of
disagreement in the presentation of (5) on the use of key material
are noted below.

At 01:23 AM 12/24/02 +0200, Hugo Krawczyk wrote:
>Derrell, based on your messages and other recent traffic on the list on
>this issues I think that we can summarize several points of agreement
>as follows: (what do other think?)
>
>(1) do not mandate SLA in IKEv2
>(2) leave SLA as a separate document 
>(3) advance IKEv2 and SLA concurrently in the standards process
>
>(4) replace the CHRE formats with standarized EAP transport
>   
>(5) regarding MitM attacks due to the use of mixed protected/unprotected
>runs of the legacy authentication, the WG has to decide on one of two ways to
>go:
>
> (a) do not do anything about solving the problem in SLA. This has
>     several possible justifications:
> 
>   - assume (as you said in a previous message) that the mixed authentication
>   scenario does not occur in ipsec 
>   [this would probably require more feedback from the list]
>
>   - assume that even if some mixed authentication scenarios do show up
>   in the ipsec world it is due to a BAD PRACTICE that should be abandoned
>   (not a sin that SLA needs to help washing)
>
>   - be "respectful" to people that use mixed authentication but tell them to
>   look for a solution  elsewhere (at the legacy authentication layer or as a
>   generic mechansims on top of EAP, for example).
>
>  (b) allow for an optional mixing of key material derived from SLA and from
>     the underlying authentication method in the key derivation procedure of
>     SLA. This is a solution of limited scope (assumes that the legacy
>     authentication produces a key and that the key can be made available to
>     SLA) and it does not address at all the dangers of dictionary attacks if
>     the legacy authentication is based on password (or other low-entropy
>     keys). It also constitutes (as someone said) a logical layer violation.

In (5)(b), it seems more appropriate to characterize as "limited scope"
the choice to NOT permit use of optional authenticated key material.

Problems arise when the concept of "SLA" is limited to
"legacy methods for authentication that do not produce key material",
rather than the more broadly useful
"authentication methods that use legacy credentials".
Not all such methods are alike, so why shouldn't the solution
be able to leverage the best qualities of any method?

As to whether using available key material constitutes a "layer violation",
I'd say the alternative is clearly the larger crime.  Choosing to discard
authenticated keying material, instead of binding it in some way to the
session key, violates several important security principles.

A key-producing SLA method may well address "dictionary attack",
and key binding can prevent other MitM attacks that may otherwise
occur when using server-only authenticated keys.

As for the summary of (5)(a), none of the "possible justifications"
presented justifies the "do nothing" approach, because the ramifications
of such a decision go beyond the lone issue of "MitM attacks due
to mixed protected/unprotected runs" as presented.

-- David