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

IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt


Hi,

I understand everyone is waiting for the IPsec drafts to advance 
into RFCs. But, I am afraid, a serious flaw was uncoverd in the 
IKE draft recently (late June). I believe, this flaw needs to be 
corrected before the draft is advanced into an RFC. The issue 
came up during a discussion between Bryan Gleeson, Vipul Gupta, 
myself and others. 

I mentioned the problem on the ipsec mailing list briefly at that
time and have been trying to resolve this independently with Daniel 
harkins via private e-mail. But, to no avail. Dan is opposed to 
altering the draft. I would like the IESG to review the problem. 

Ref:      Section 5.4. Phase I authenticated with Pre-shared-key

Problem:  While Main mode of negotiation and pre-shared-key based 
	  authentication are independently stated as mandatory for 
	  IKE draft compliance, together they do not work.
	  I.e., Pre-shared-key based authentication in Main mode 
	  does not work or is seriously flawed in the way it is 
	  stated to work.
	  
Explanantion + A possible fix:

          Section 5.4 states that pre-shared-key based authentication 
	  in main mode requires either party to assume the source IP 
	  address of the partner (found in IP header) as the ID of partner. 
	  
	  This is because the SKEYID used to encrypt the ID payload is 
	  based on pre-shared-key. And, the pre-shared-key couldnt be
	  known without knowledge of the ID of the partner.  Clearly, the 
	  draft cornered itself into a chicken-and-egg problem.

          If IP-Address type was the only valid ID type,  we could take the 
	  IP address in IP header (layer 3) as a replacement for IP address 
	  in ID payload (layer 4), as the draft says.  But, that would be a 
	  layer violation (assuming layer 3 info in place of layer 4 info). 
	  Even with the layer violation, this assumption is workable only 
	  with an IP-address type ID. For an IP DOI, the ID can be many 
	  different things, including a user-name, device-name, DER encoded 
	  Distintinguished Name etc.  IKE negotiation would simply not work 
	  with these ID payloads.
    
          Suggestions that we should get around this by using aggressive 
	  mode or use a different type of authentication mode only enhance
	  the argument that the protocol is inadequate for minimally 
	  compliant IKE implementations(ie, Main mode + Pre-shared-key auth).

          One approach I could think of to fix this problem was to 
	  disassociate authentication mechanism from key derivation 
	  (SKEYID). I am not a cryptographer and I do not understand
	  why SKEYID is evaluated differently based on authentication 
	  schemes used. I would suggest making derivation of SKEYID 
	  uniform for all authentications, like 
			    SKEYID = prf (hash(Ni_b | Nr_b), g^xy)

          At a minimum, I would suggest the above SKEYID key derivation 
	  change to pre-shared-key based authentications. The 
	  chicken-and-egg problem with pre-shared-key based authentication 
	  is created because, SKEYID is derived as a function of 
	  pre-shared-key. For all other types of athentications, SKEYID 
	  derivation does not require peer ID info. 

	  Authentication based distinctions could be restricted simply 
	  to the way HASH_I and HASH_R are evaluated. For example, 
	  HASH_I and HASH_R for pre-shared key authentication could have 
	  been evaluated differently by concatenating pre-shared key to 
	  the message argument (i.e., arg2) of prf.

Thanks.

Regards,
suresh
Follow-Ups: