Re: Secure legacy authentication for IKEv2

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

Derrell, based on your messages and other recent traffic on the list on
this issues I think that we can summarize several points of agreement
as follows: (what do other think?)

(1) do not mandate SLA in IKEv2
(2) leave SLA as a separate document 
(3) advance IKEv2 and SLA concurrently in the standards process

(4) replace the CHRE formats with standarized EAP transport
    
(5) regarding MitM attacks due to the use of mixed protected/unprotected
runs of the legacy authentication, the WG has to decide on one of two ways to
go:

 (a) do not do anything about solving the problem in SLA. This has
     several possible justifications:
 
   - assume (as you said in a previous message) that the mixed authentication
   scenario does not occur in ipsec 
   [this would probably require more feedback from the list]

   - assume that even if some mixed authentication scenarios do show up
   in the ipsec world it is due to a BAD PRACTICE that should be abandoned
   (not a sin that SLA needs to help washing)

   - be "respectful" to people that use mixed authentication but tell them to
   look for a solution  elsewhere (at the legacy authentication layer or as a
   generic mechansims on top of EAP, for example).

  (b) allow for an optional mixing of key material derived from SLA and from
     the underlying authentication method in the key derivation procedure of
     SLA. This is a solution of limited scope (assumes that the legacy
     authentication produces a key and that the key can be made available to
     SLA) and it does not address at all the dangers of dictionary attacks if
     the legacy authentication is based on password (or other low-entropy
     keys). It also constitutes (as someone said) a logical layer violation.

Hugo