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

confusion about identity



I am trying to understand identity payload in ISAKMP, Oakley, and
their combination.  These are some notes from this exercise.

The documents use several not-quite-identical terms that I'm reading
as equivalent:  Identification Payload, ID payload, and identity
payload.  Is there an important difference?  If not, I suggest that
a single term be used everywhere.

draft-ietf-ipsec-isakmp-oakley-05.txt, section 5 "Exchanges" says the
following (I quote a fair bit to give context, but you needn't read
it to get my point):

   To authenticate either exchange the initiator of the protocol
   generates HASH_I and the responder generates HASH_R where:

    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

   For authentication with digital signatures, HASH_I and HASH_R are
   signed and verified; for authentication with either public key
   encryption or pre-shared keys, HASH_I and HASH_R directly
   authenticate the exchange.  The entire ID payload (including ID type,
   port, and protocol but excluding the generic header) is hashed into
   both HASH_I and HASH_R.

The first word of the second last line is the only use of the word
"port" in the document.  As such, it seems out of place.

I find port mentioned in draft-ietf-ipsec-ipsec-doi-06.txt, section
4.6.2 "Identification Payload Content".  Port is recorded in a field
that is marked as "reserved" (and hence required to be zero) in
draft-ietf-ipsec-isakmp-08.txt section 3.8 "Identification Payload".
This conflict looks serious to me: one or the other document should
be altered.

In describing port, 4.6.2 of draft-ietf-ipsec-ipsec-doi-06.txt says:

   During Phase I negotiations, the ID port and protocol fields MUST be
   set to zero or to UDP port 500.  If an implementation receives any
   other values, this MUST be treated as an error and the security
   association setup MUST be aborted.  This event SHOULD be auditable.

The only time we use HASH_I and HASH_R (described in the long quote
above) is during phase 1.  I wonder why one would put UDP port 500
here when it causes a contradiction between the documents and yields
no useful information (as far as I can tell).

This draft-ietf-ipsec-isakmp-oakley-05.txt section 5.4 says the
following, which does not address the issue but may be relevant:

   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. Aggressive Mode
   allows for a wider range of identifiers of the pre-shared secret to
   be used. In addition, Aggressive Mode allows two parties to maintain

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253


Follow-Ups: