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

Re: Secure legacy authentication for IKEv2





On Fri, 27 Dec 2002, David Jablon wrote:

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

I don't understand your intention here.
Choice 5(b) is the one that DOES support the use of optional authenticated
key material and it IS of limited scope as explained in the parentheses
above. So what is more (or less) appropriate here?

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

I do not agree. The problem is really with legacy authentication *protocols*, 
not with legacy *credentials*. If you let me re-design even the most basic
of pswd authentication protocols such as CHAP I will do it in a way that
will change the protocol very slightly (and will use passwds the same way
CHAP uses now) but will make the modified protocol resistant to the MitM
attacks we were discussing here.  How? Simply put under the response
computation the name of the server with which you are comunicating and (if
possible) the name of the tunnel protocol under which the protocol is run
(with a special "protocol name" for "no tunneling"). Needless to say this
does not resolve dictionary attacks if the protocol is run unprotected but
that is something that NO solution can avoid (except of course for NOT
running the protocol unprotected or for switching to dictionary-attack
resistant methods (which exist of course but not as "legacy").
 
In other words, it is easy to build future or modified protocols using
legacy credentials that are not susceptible to the discussed MitM attacks.
The problem is only with existing protocols (not with legacy credentials
per se).

 
> Not all such methods are alike, so why shouldn't the solution
> be able to leverage the best qualities of any method?
> 

This is the usual generality/security/complexity trade-off discussion.
We all prefer to be beautiful and rich than ugly and poor. Here
unfortunately we cannot get it all and will have to decide where to pay
the cost and where to compromise.  It is up to the WG to decide which
trade-offs are preferred.

If you have a "beautiful and rich" solution, please suggest it.
Everyone will be happy to accept it.

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

This is not so black and white: if you "mix" keys from two protocols you
have to make sure that these keys were not used in their "parent protocol"
for functionalities that conflict with their use in the mix (e.g. making
sure you do not use for MACing a key that the parent-protocol used for
encryption). Actually, the whole issue of "importing" and "exporting" keys
is problematic, especially if the tunneling protocol wants to use the
underlying authentication in a black-box manner. Abandoning this black-box
apprach can be considered but it has a generality and complexity penalty.

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

Please explain these ramifications. I cannot see how these attacks go
beyond the mixed protected/unprotected runs. (Or how a compound
authentication as we are discussing resolves any issue beyond these
attacks).
 
Hugo

> 
> -- David
> 
> 
>