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

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

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
> 
> At 01:20 AM 12/31/02 -0500, Charlie_Kaufman@notesdev.ibm.com wrote:
> >There has been a lot of traffic about avoiding MITM attacks when
> >incorporating legacy authentication into IKEv2. For a long time, I didn't
> >understand it. Now I think I do. That does not imply I really do. I'm
> >writing this note both to summarize the other notes here and to find out
> >whether I really understand it by giving everyone a chance to stomp on me
> >if I don't.
> ...
> >If we were to add stronger legacy authentication mechanisms (e.g. CRAM-MD5,
> >Kerberos, SRP), we should at that time design MITM protection. There are
> >several plausible mechanisms. My favorite would be to generate some sort of
> >key identifier for the IKE connection and wind that in to the legacy
> >authentication mechanism rather than taking a key generated by the legacy
> >authentication and winding it into IKE. But either would work.
> >
> >OK, guys. How much of this did I get wrong.
> >
> >          --Charlie
> 
>