Re: Fixing identity and cert-sending

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

Some folks have asked me if the new identity/cert proposal deals with 
"legacy authentication" (which is just a negative-sounding codeword 
for "authentication that doesn't involve public key crypto"). The 
answer is yes, definitely. Note the terms used for one of the 
identity types:

>6  IDForSharedSecret -- This is only for use with shared secrets. It is an
>      ASCII string (all octets are 31 < x < 127) of any length.

That's "shared secret", not "preshared secret". Neither IKEv2 not JFK 
tie the secret to the IP address, so there is no need to preshare the 
key.

A legacy auth system usually returns an authentication item, either 
to the user or to some other system (such as the IPsec gateway). As 
long as that authentication item has two parts that are 
cryptographically separate, it can be used with the new proposal.

As simple scenario is username-and-password. The IDForSharedSecret is 
the username, and the key added to the HMAC is the password. When 
receiving this message, the system looks up the password based on the 
username, possibly using something like RADIUS.

A more complex scenario involves a hardware token that doesn't do 
public key crypto. Typically, the user does some challenge-response 
dance with the authenticating server and is then authenticated. At 
that point, as long as the user has two pieces of authentication 
information, they can use them in an HMAC. For systems that only 
return one item (such as a long hash), there must be some agreement 
on how to split that into two items, such as "80 bits and 80 bits". 
That can be done by the legacy auth vendor, possibly instantiated in 
an informational RFC.

--Paul Hoffman, Director
--VPN Consortium