Subject: (another) WGLC started for "RSVP Security Groupkeying" ID

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Jul 2010 11:48:04 -0500

TSVWG

This is to let everyone know we've initiated a new WGLC for the "RSVP 
Security Groupkeying" ID here.

http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/

This ID has had some significant modifications based on the SecDir 
review by Stephen Kent.  Please reread this ID to verify these 
changes are appropriate, and do not introduce new issues or concerns.

Once you have reviewed this version, please send a note to the list 
with an indication whether or not this doc should proceed to the IESG 
for RFC consideration. We chairs need to gauge WG interest before 
this (or any) document progresses towards publication.

Because of the IETF meeting so close, this is an extended WGLC, 
lasting 4 weeks - ending August 11th, 2010.

Please do review this document and let us/the list know what you think.

James & Gorry
TSVWG chairs

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 27 Jul 2010 17:42:33 +0100

James, Michael, Francois,

Here's my review,

I've only looked at the diffs from -05, which I already reviewed. So 
this review doesn't imply I've re-checked overall readability.

S.4.1
"Static keys are preconfigured, either manually, or through a network 
management system, and not negotiated via a protocol."
Delete: ", and not negotiated via a protocol" (the NMS uses a 
protocol and implying it somehow does not creates complacency - see 
next point).

"The provisioning of static keys requires either manual operator 
intervention on each node, or a network management system performing 
the same task."

Would it be worth pointing out (or is it obvious?) that, if an NMS is 
giving nodes static keys, it needs to regularly change the keys it 
uses to verify that it is talking with the nodes it thinks it is 
talking with? This recursion has to stop somewhere!

S.4.2.1
It's interesting that the following has been deleted. "However, 
existing key negotiation protocols such as IKEv1 [RFC2409] or IKEv2 
[RFC4306] may not be appropriate in all environments because of the 
relative complexity of the protocols and related operations."

Operational complexity is why Jonny can't encrypt, but we're not 
allowed to say why Jonny can't encrypt?!

I would argue that something ought to remain of this sentiment, 
rather than deletion. Perhaps "Although it is recognised that 
existing key neg protocols RFC[...] are operationally complex to 
deploy, the security they provide compared to ad hoc manual 
alternatives is worth the effort invested."

S.6.1
"A router implementing GDOI and the AH and/or ESP protocols is 
therefore able to implement this policy."

The 'and/or' implies the ESP protocol alone could be enough. This 
needs to refer forward to the limitations of ESP discussed in 
Security Considerations. (except they aren't there any more - see next point)

S.6.3.
"In the case of ESP the new, outer IP header however is not 
cryptographically secured in this process.  This has consequences 
when group keying is used; see the Security Considerations section 
for details."

There is nothing about ESP in the Security Considerations section. 
And the re-routing attack previously described in Section "6.2. Using 
IPsec ESP" that I think this refers to has been deleted. Has this 
attack been proven to not exist, or was losing this text a mistake?

S.6.5.
"  Tunnel mode with address preservation, in conjunction with group
    keying, allows the use of AH or ESP for protection of RSVP even in
    cases where non-RSVP nodes have to be traversed.  This is because it
    allows routing of the IPsec protected packet through the non-RSVP
    nodes in the same way as if it was not IPsec protected.
"
If we still intend to talk about the reservation re-routing attack 
(see previous point), we also need to refer to it here (once we have 
reinstated the text that talks about it). Because a reservation can 
be redirected by a non-RSVP hop in the address-preserving case as in 
other cases using ESP.

S.10.1
Another "Subverted Nodes" attack occurs to me that uses the weakness 
of ESP vs AH. Using a group key, a subverted node could turn round a 
PATH message back to the previous node that the subverted node 
received it from, thus pretending the PATH had traversed the rest of 
the path when in fact the subverted node has just been holding on to 
it for a while. Thus the sending half of the nodes think the 
reservation has been set-up, while the receiving half never saw it.

The point of mentioning these attacks is that, with group keying, a 
subverted node can change which direction it sends messages 
(sideways, backwards), not just subvert the messages it forwards.

Nits
====
S.2
"If a group key is used, the authentication granularity becomes group 
membership, not (individual) peer authentication."
You might want to make it clear that you are talking about a group of 
nodes not humans ('group membership' is ambiguous). But I'm not 
insisting - it's unlikely to be misunderstood.

s/...whether authentication or encryption (or both) are used.
  /...whether authentication or encryption (or both) is used./
Change it back to the correct English: the verb shouldn't match the 
phrase in the parenthesis.

S.2. Penultimate para:
s/We note that if this handshake is taking place,
  /We note that if this handshake has taken place,/

S.3.1
s/INTEGITY
  /INTEGRITY/

S.6.3.
"This has consequences when group keying is used; see the Security 
Considerations section for details."

s/consequences/negative consequences/

S.6.5.
"it is not possible to use tunnel-endpoint destination address"
s/tunnel-endpoint
  /a tunnel-endpoint/

Bob

At 10:27 25/07/2010, Bob Briscoe wrote:
>James,
>
>I can try to have a look by the deadline.
>
>
>Bob
>
>At 17:48 14/07/2010, James M. Polk wrote:
>>TSVWG
>>
>>This is to let everyone know we've initiated a new WGLC for the 
>>"RSVP Security Groupkeying" ID here.
>>
>>with an indication whether or not this doc should proceed to the 
>>IESG for RFC consideration. We chairs need to gauge WG interest 
>>before this (or any) document progresses towards publication.
>>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design