Re: "legacy" confusion (was Re: Summary of MITM attacks with legacy authentication)

[David Jablon <dpj@xxxxxxxxxxxx>]

Hugo,  I do understand the concept of running a client authentication
method as is.  But as much as it is an important concern in designing
a general framework, the ability to run a method "as is" is hardly a
unique aspect or useful discriminator for the definition of
"legacy method".  I believe overuse of the "legacy" modifier has
caused a lot of this confusion over conflicting or irrelevant distinctions.

Your comments on trivial solutions do not address my point that the
issue of "mixed runs" is not the only issue of concern when binding
authentication to keying material. I posted a proposal in a related thread
that discusses other general benefits of solutions that bind both client
and server authentication to keying material, for example, to address
server-spoofing attacks that take advantage of user error.

I agree that we may have the luxury of a number of several easy solutions,
but we should clarify where these solutions cover different sets of potential
problems.  Charlie's post noted two classes of solutions that serve the
common goal of binding client authentication to the session key:

(1) to bind authentication keying material into the IKEv2 keys.
(2) to bind the IKEv2 server-authenticated key into client authentication.

For what it's worth, one reason to favor class (1) over class (2) is
that (1) could support any key-generating EAP method "as is".

-- David


At 01:12 AM 1/1/03 +0200, Hugo Krawczyk wrote:
>David, in your description below you are missing one of the main aspects
>of *legacy* methods, namely, that you run them "as is" (i.e. as a "plug
>in" and without modifications). If you could modify or redesign them
>then, as said many times, you can trivially solve all these irritating
>mitm issues in mixed runs by binding the authentication to the protocol's
>context (server name, encapsulating tunnel protocol, etc).
>
>Hugo
>
>On Tue, 31 Dec 2002, David Jablon wrote:
>
>> Charlie's summary valiantly dispels some confusion in this discussion,
>> and yet it still perpetuates some of it in too-loosely using the term "legacy".
>> > "Legacy" seems to have a clear and useful meaning within "legacy credentials".
>> There it means something other than a shared key or private/public
>> key pair, like a static password or one-time password, essentially any
>> non-key data that has historically been simply transmitted to prove
>> identity in olden-days.
>> 
>> But "legacy" has no clear meaning in "legacy authentication method".
>>  From various threads of discussion, this phrase can be interpreted to
>> mean a method with almost any combination of the following characteristics:
>> 
>> -- uses a "legacy credential" for authentication
>> -- requires secure transmission of the credential
>> -- does not require a key
>> -- does not establish a key
>> -- has been widely used (defined arbitrarily)
>> -- has been in use since Month Day, Year (fill in as desired)
>> 
>> The term "Secure Legacy Authentication" is especially confusing
>> when it is limited to encompass *only* methods that have historically
>> used legacy credentials in *insecure* ways.
>> 
>> This confusion is perpetuated further in reference to Kerberos, MD5-CRAM,
>> and SRP as "stronger legacy mechanisms".  "Legacy" in what sense? 
>> "Stronger" than what, and in what ways? Discussions will likely continue
>> to circle in unproductive ways until our legacy jargon is replaced.
>> 
>> The common theme seems simple:  methods that use passwords as credentials,
>> including both re-usable passwords and one-time passwords (e.g. SecurID).
>> 
>> In discussions of threat scenarios it certainly makes sense to distinguish
>> between sub-classes of such methods.  But when discussing a framework
>> for how they can be plugged-in to IKEv2, it seems to make more sense to treat
>> them as a comprehensive class in so far as there is no technically
>> compelling reason to subdivide.
>> 
>> -- David