[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: confusion about identity
I wrote:
| 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.
Lewis responded:
| I don't see your point here. Enumerating the fields of the ID payload
| seems a good way to elaborate on the intended meaning of "entire ID
| payload". "Port" is certainly an appropriate term to use to name one
| of those fields. I fail to understand why the uniqueness of the word
| in the document renders it "out of place".
and Derrell also responded:
| There are a few places when the ISAKMP/Oakley Resolution document is specific
| to the IPSEC DOI, and this is one of them. I suppose this statement really
| belongs in the IPSEC DOI, or else the IO Resolution should qualify this with,
| "For SA's negotiated under the IPSEC DOI, ..." However, we tried to keep all
| of the key agreement/key exchange protocol self-contained in one document and
| the IO Resolution is clearly the place for this. It's clearly important to
| include the full IPSEC DOI ID payloads in the hash calculations.
As a newbie struggling with the relationships between the documents, I
would have been helped by hints such as Derrell mentioned. He says
that there are a few such places. I would be helped by flagging each
of them.
I suggest rewording the following part:
The entire ID payload (including ID type, port, and protocol but
excluding the generic header) is hashed into both HASH_I and
HASH_R.
to something like:
The entire Identification Payload excluding the generic header
(and including ID type, and any DOI-specific fields such as port and
protocol for the IPSEC DOI) is hashed into both HASH_I and HASH_R.
- I've changed "ID payload" to "Identification Payload" for consistency
- I've moved "excluding the generic header" outside the parentheses
since it is not parenthetical.
- I've made explicit that all DOI-specific stuff is included. I am
presuming that this is the original intent, but I am not 100% sure
that this makes sense in phase 1. I'm not saying it is wrong, just
that I don't understand all the implications (if any).
- I've identified the port and protocol fields as DOI specific.
Later, I said:
| 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.
Derrell responded:
| The ISAKMP document also says:
|
| 3.8 Identification Payload
|
|
| The Identification Payload contains DOI-specific data used to exchange
| identification information.
|
| For the IPSEC DOI, the format is as defined in the IPSEC DOI. For other
| DOI's, the ID Payload would be defined in the relevant DOI document. For
| ISAKMP Phase I negotiations, the format is as defined in the ISAKMP document.
This I find more problematic. draft-ietf-ipsec-isakmp-08.txt clearly
states:
2.5.2 RESERVED Fields
The existence of RESERVED fields within ISAKMP payloads are used strictly
to preserve byte alignment. All RESERVED fields in the ISAKMP protocol
MUST be set to zero (0) when a packet is issued. The receiver SHOULD
check the RESERVED fields for a zero (0) value and discard the packet if
other values are found.
I think that all IPSEC DOI conforming systems will violate this ISAKMP
rule!
Section 3.8 states that the DOI-specific stuff goes in the
Identification Data variable-length field (and make no provision
elsewhere, except perhaps for the ID Type field).
It seems quite wrong to use the payload identifier assigned for an
ISAKMP Identification Payload and violate the format specified. One
right approach would be to assign a DOI-specific identifier for the
IPSEC DOI Identification Payload.
It is much to late to evict the port and protocol fields from the
IPSEC DOI version of the Identification Payload. The fix that I
strongly recommend is that section 3.8 of
draft-ietf-ipsec-isakmp-08.txt be reworded to change the RESERVED2
field to a DOI-specific field. I doubt that this word hurt anybody.
Summary: I think a simple fix to ISAKMP will make everything right
without breaking anything. I infer that this captures the original
intent.
Derrell also responded
| I added this to the IPSEC DOI document following the Ottawa IPSEC bake-off
| because there were several vendors sending Port 500 in the Phase I Main Mode
| exchange. I guess that was a mistake on my part. You're right though and
| unless there are objections raised ASAP, I'll remove it from the next draft.
| It really doesn't add anything to have Port 500 included in the hash.
I think that the changes I suggested above would together require the
Port field to be filled properly, not left zero. A change in their
logic (which may or may not be a good thing) would be required to
allow zero.
Do we wish to specify here that the port is 500? Although that is the
normal port, I play with ISAKMP OAKLEY on other ports for various
reasons. This is really two points: the 500 is specified elsewhere,
and I don't think it should be redundantly embedded in this place.
Furthermore, if an implementation happens to support other ports,
surely the port being used should appear here, not 500.
Thanks for your attention. I'm sorry to be so pedantic, but I think
that good standards require this.
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253