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

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



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