On ipsra authentication options

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

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)

  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