[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On ipsra authentication options
In L2TP/IPSec, a possibly low entropy password based legacy autentication
is protected by a standard IKE phase1, which could be any of the standard
I don't see the need to design yet another protocol.
On Fri, 23 Jun 2000, Hugo Krawczyk wrote:
> I was trying to sumarize to myself the main issues raised by some of
> the recent discussions in this list regarding options for ipsra
> There are two main points that I see as the basis for further decisions:
> o There is *no secure way* to use the *current* authentication modes of
> IKE with a low-entropy secret: regardless of the underlying legacy
> authentication scheme that provides the low entropy pasword the
> resultant authentication will be open to off-line guessing attacks.
> o In order to authenticate IKE (i.e., end-point authentication and DH
> exchange authentication) using low-entropy passwords there are
> two basic options:
> 1. add a new, specially designed, authentication mode to IKE
> (note that solutions where phase 1 is one-way authenticated fall
> under this option since there is no current IKE mode that supports
> one-way authentication)
> 2. come up with a protocol that on the basis of the low-entropy secret
> (or other legacy authentication schemes) provides the application run
> by the owner of the low-entropy password with a strong secret (and a
> certificate if necessary) to be used with one of the existing IKE
> authentication modes.
> From a cryptographic design point of view both options are viable and can
> offer comparable security.
> The first option is deemed unsuitable for ipsra since it means "changing IKE"
> (this is not completely accurate since you can always add an IKE mode
> that is NOT mandatory for IKE).
> The second option is less efficient in the total number of messages (from the
> moment that a user's application starts bootstrapping an ipsec connection
> until the first ipsec packet is transmitted) but it is architecturally clean
> and provides the best deployment path to certificate-based IKE authentication.
> To realize the second approach I see two options
> A. Follow one of the solutions outlined in the getcert or PIC drafts
> (and fill in the many missing details)
> B. Adopt an existing certificate enrollment protocol that supports
> enrollee authentication via a user authentication legacy system
> I do not know of any existing solution such in B, but if there is one it
> should be considered.
chinna narasimha reddy pellacuru