[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A fix for main mode with preshared keys

I propose below a very simple fix for the following problem, which has 
been pointed out by many people: in main mode with preshared keys, the 
responder cannot decrypt IDii, the initiator's identity payload, unless 
the responder knows the preshared key, which in turn depends on the 
initiator's identity.

Two workarounds have been proposed:

(1) The use of the source-IP-address field in IP packets as identity, 
rather than the ID payload, at least in this case.

(2) The introduction of a completely new mode with different security 
properties ("IKE Base Mode", Internet draft by Yael Dayan and Sara 
Bitan).

In my opinion, (1) is a bad idea for the following reasons:

- It goes against the spirit of the ISAKMP and IPSEC protocols.  For 
example, ISAKMP has an Identity Protection exchange, of which Main Mode 
is an instance.  This exchange protects the identities of the parties 
carried in the ID payload. Ignoring the ID payload and using instead the 
source IP address in the packets defeats the nominal purpose (identity 
protection) of the exchange.  As another example, RFC 2407 (DOI), 
Section 4.6.2, says "The Identification Payload is used to identify the 
initator of the Security Association.  The identity of the initiator 
SHOULD be used by the responder to determine the correct host system 
security policy requirement for the association."

- It introduces ambiguities and creates confusion.  (When should the ID 
payload be used for identification?  When should the source IP address 
be used instead?  Should both be used for different identification 
purposes?  If both are different, should identification fail?  If a 
certificate is used, should it certify the ID payload, or the source IP 
address, or both?  Solving all these questions could take years...)

- It introduces a special case, which reduces the quality of the 
protocol, and increases its complexity.

- It doesn't work in cases where IP addresses are assigned dynamically, 
such as remote access.

The proposed IKE Base Mode would be a useful addition to IKE because it 
is based on the ISAKMP Base Exchange, which provides a different set of 
security tradeoffs than those available in the Identity Protection 
Exchange (Main Mode) and the Aggressive Exchange (Aggressive Mode).  
Specifically, it provides some protection against DoS and allows for 
negotiation of the DH group, while sacrificing identity protection.

However Base Mode does not solve the problem.  It remains impossible to 
provide identity protection (the nominal goal of the Identity Protection 
exchange used by Main Mode) while using preshared keys.

The problem comes from the fact that keying material (SKEYID_d, SKEYID_a 
and SKEYID_e) is derived from two different sources: the Diffie-Hellman 
secret g^xy, and the secret used for authentication.  This is so in the 
case of authentication by preshared key, as well as in the case of 
authentication by public key encryption.

But there is no reason why the keying material should be derived from 
these two sources.  In other protocols that use ephemeral 
Diffie-Hellman, the keying material is derived only from the 
Diffie-Hellman secret.

So I'd like to propose that we derive the keying material exclusively 
from the Diffie-Hellman secret.  One way of doing this with minimal 
change to the existing protocol is simply to change

      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

to

      SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2)

I believe this solves the problem.

Note that there is a related problem mentioned in RFC 2409, Section 5.4:

   When using pre-shared key authentication with Main Mode the key can
   only be identified by the IP address of the peers since HASH_I must
   be computed before the initiator has processed IDir.

However this is not a real problem for the following reasons.

First, the initiator should know who it wants to communicate with, and 
therefore should be able to determine the preshared key.  Granted, the 
*IKE code* may not know, but this is a software architecture issue 
rather than a protocol problem.

Secondly, the responder does not have this problem (assuming that the 
above fix has been applied, and the responder can decrypt IDii). 

The remote access problem is then solved as follows: 

- The remote client initiates contact with the security gateway at a 
known, fixed IP address.  IKE on the remote client can find the 
preshared key based on this address, or else the remote access code can 
obtain the preshared key from the user and pass it to IKE.  IKE uses it 
to compute HASH_I before sending the 5th message in the Main Mode 
exchange.   

- The remote client has a dynamically assigned IP address, but it 
identifies itself using, for example, a fully-qualified username 
(ID_USER_FQDN in the DOI) in the IDii payload.  After the gateway 
receives and decrypts the payload, it looks up the corresponding 
preshared key and uses it compute HASH_R before sending the 6th message 
of the exchange.

Francisco Corella

(francisco_corella@hp.com)
Follow-Ups: