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

Re: A fix for main mode with preshared keys

  This approach has been proposed (and rejeted) in the past. If you
want to use pre-shared keys and have identity protection then use
either base mode or aggressive mode with ID_KEY_ID-type identities.
This is an opaque blob that is not meaningful to an evesdropper. For
example, the pre-shared key database could be:

   ID_KEY_ID value          "real" identity         pre-shared key
  ----------------         -----------------       ----------------
    tr8gsnkdru8gsw           Barney Gumble          mekmitasdigoat
    dfnmtynioghora	     Ned Flanders           whatcertificatereally
       etc.

So if an entity sends an ID whose type is ID_KEY_ID and whose value
is tr8gsnkdru8gsw and can also prove knowledge of the pre-shared key
then that person is believed to be Barney Gumble. The "real" identity
is never transmitted.

  For those of you who are concerned about massive evesdropping on the
Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny
on Tuesday and Khartoum on Thursday, it _must_ Osama Bin Laden! Next time
you see that ID_KEY_ID go get him.") the value can change with each 
authentication by hashing with some exchange specific information like 
the nonces:

	 ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr)
	 where ID_KEY_ID[0] = the initial seeded value

Once you sucessfully authenticate using ID_KEY_ID[x] update the pre-shared
key database so the existing pre-shared key (and hidden "real" identity)
will not be associated with ID_KEY_ID[x+1].

  Dan.

On Tue, 07 Dec 1999 12:43:03 PST you wrote
> 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)
>
References: