[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Quick Mode HASH(3) and optional payloads
D. Hugh Redelmeier writes:
> RFC2409 (IKE) section 5.5 (Phase 2 - Quick Mode) describes HASH(3) in
> a way that does not specify that optional payloads should be included.
> [The whole wording for hashing of optional payloads and other payload
> orders seems to be tacked on in an unfortunate way.]
> I think that optional payloads should be fed into the hash function,
> after Nr_b. This would make HASH(3) more like HASH(1) and HASH(2).
> It would also provide checking for these optional payloads.
True, and it doesn't even break anything, because I don't think there
is any optional payloads in the third packet of the quick mode defined
now...
> - am I right in thinking that optional payloads are allowed in the
> initiator's second Quick Mode message?
Which option payload you could put there? Notify payload is only thing
I can think about, and there is no currently defined use for that in
the third message. Only status notification going from the initiator
to the responder is INITIAL-CONTACT, and you can put that in the first
packet.
> - am I right that the RFC does not specify that the HASH(3) includes
> optional payloads?
At least I interpret that so.
> - is there a good reason not to include the optional payloads in
> HASH(3)?
Not really.
> - is there a good reason to include the optional payloads in HASH(3)?
Yes, to give them protection. But because there is no NEED to use any
optional payloads in the third message I think this issue can be
ignored now, and added to the TODO list for the later revisions.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: