[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment on the ISAKMP/Oakley resolution draft
Shawn, Pau-Chen,
> Shawn, Hugo and I discovered this too. One solution Hugo has
> is to give the shared key an ID (like an SPI). This ID could
> be sent in ID payload together with KE and NONCE. Another
> possibility I could see is to augment the DOI a little bit
> and send the key ID in "situation".
If you pass an ID payload with the KE and NONCE payloads then why
do Main Mode? That sounds like an Aggressive Mode to me. And if the
ID payload is only some opaque blob of data that has meaning only
to the parties involved then there's no loss of "ID protection" in
Aggressive Mode. An ID of dharkins@cisco.com means something to a
passive evesdropper; an ID of 7a8927c5478 (like a SPI) means nothing
so why not just pass it in the clear and do an Aggressive Mode?
The problem is that IDs of type FQDN or user@FQDN (the only two that
convey any real meaning that the two parties might want to hide)
cannot be used to identifiy pre-shared keys to be used with Main Mode.
I'm not sure how big a problem this is.
The two parties must somehow agree to a pre-shared key in some out-of-band
manner, and presumably they'll also agree to some identifier for that key
(which right now can't be FQDN or user@FQDN). The IPSec DOI reserves 6 ID
types for private use. The two parties could agree that the identifier will
be some opaque blob (like a SPI) and it's ID type will be from the private
use range. Then you do Aggressive Mode with out conveying your identities
to any evesdroppers; you retain "ID protection".
Why isn't this acceptable?
The pre-shared key was put into SKEYID, and SKEYID is used as the key to the
HMAC (as opposed to part of the data to hash) on the recommendation of a
cryptographer (it's a security issue). I'm hesitant to remove it to allow
a case that I don't see as overwhelmingly compelling.
Comments?
Dan.
References: