Re: On ipsra authentication options

[Ricky Charlet <rcharlet@xxxxxxxxxxxx>]

Howdy,
	
	One small inline comment near the bottom....


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

	Or the User Level Authentication Mechanism (ULA) draft
draft-kelly-ipsra-userauth.



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



--
Ricky Charlet      rcharlet@xxxxxxxxxxxx    USA 510-795-6903