[anonsec] draft-richardson-btns-ikeextensions-00

[Yaron Sheffer]

Mostly nits, some bigger comments.

* If the use of Raw RSA is "clarified", shouldn't this draft
"update" RFC 4306 (or worse, RFC 4718)?
* Sec. 2: "It *SHOULD be sent in after *the phase 1 SA has become
private," - I guess you mean "SHOULD be sent *only* after.
* Typo: "Aggressive mode *is *SHOULD NOT".
* Sec. 3: "This code point is hereby defined for IKEv1" - this
should also go into the IANA Considerations.
* KEY is capitalized a number of times.
* Sec. 5: "It details the order in which to look for authentication
data for a protocol which does not in itself require any
authentication data." This sentence baffled me. What do you mean?
Does this imply that no further security analysis is required?

Thanks,

Yaron


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070404/2edd4baf/attachment.html

[Michael Richardson]

Post by Yaron Sheffer
Mostly nits, some bigger comments.
* If the use of Raw RSA is "clarified", shouldn't this draft
"update" RFC 4306 (or worse, RFC 4718)?

I guess so.

Post by Yaron Sheffer
* Sec. 2: "It *SHOULD be sent in after *the phase 1 SA has become
private," - I guess you mean "SHOULD be sent *only* after.

fixed.

Post by Yaron Sheffer
* Typo: "Aggressive mode *is *SHOULD NOT".

fixed.

Post by Yaron Sheffer
* Sec. 3: "This code point is hereby defined for IKEv1" - this
should also go into the IANA Considerations.

I'm not certain about this because we never created all the appropriate
IKEv1 registries.

Post by Yaron Sheffer
* KEY is capitalized a number of times.

bad habit from doing DNS related drafts...

Post by Yaron Sheffer
* Sec. 5: "It details the order in which to look for authentication
data for a protocol which does not in itself require any
authentication data." This sentence baffled me. What do you mean?
Does this imply that no further security analysis is required?

This document doesn't change IKE. (BTNS itself does though) So, if the
protocol was secure before, then it is secure now. It simply tells one how
to interpret a key found in a particular type of certificate payload.
It also provides an indication (for a human), that the peer thinks it is
doing BTNS. The node receiving that message may or may not be in BTNS mode,
but none of the contents of the IKE payload would change that for the peer.

If you think more discussion needs to go into this document, tell me what
kind of things you think go here.


http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-ikeextensions-01.txt
(not yet submitted)