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

[Bob Briscoe <[e-mail]>]

Michael,


At 10:08 23/09/2010, Michael H. Behringer wrote:
>WGs,
>
>Thanks to the reviewers for their feedback on this draft.
>
>The only suggestions we got from the WGLC came from Bob, and below you can
>see how we addressed them in the just submitted version 7.
>
>We believe to have now addressed all comments following the WGLC, and would
>like the chairs to move this document forward.
>
>Thanks,
>Michael, Francois, Brian
>
>
>On 27/07/2010 18:42, "Bob Briscoe" <[e-mail]> wrote:
>
> > 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).
>
>Deleted the sub-phrase.

Good

>
> > "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!
>
>I'd argue that would end in a longer discussion on this topic, which is
>really not helping the subject of the document significantly. So we made no
>change here.

Understood & OK.


> > 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."
>
>The question that was raised was "what does 'complex' mean?", which would
>lead to a significantly longer discussion, which is not really the focus of
>the document. So we suggest to not change this section.

Well, you did originally change the section - you deleted any mention 
that IKEv* is complex.

The original sentence was a good justification for group keying, so I 
think you should push harder to keep it, even tho it would make your 
life easier to just avoid criticism of other approaches.

If you still believe your original sentence, I would support you 
keeping it, even if you cannot define what complexity means. 
Otherwise we could demand that all the text is removed from security 
area RFCs because no-one can define security either.

This could be perceived as the security area censoring operational 
criticism of their protocols. I don't think removing the criticism is 
justified just because you can't strictly define complexity.

But it's your call.


> > 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?
>
>We provided new text to clarify this.

I'll look at the diffs shortly, but must dash now.

Cheers



Bob


> > 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.
>
>We provided new text to clarify this.
>
> > 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.
>
>Also addressed in the new text.
>
> > 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.
>
>Changed the sentence to "... the authentication granularity becomes group
>membership of devices, not (individual) peer authentication between
>devices."
>
> > 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.
>
>Changed.
>
> > S.2. Penultimate para:
> > s/We note that if this handshake is taking place,
> >   /We note that if this handshake has taken place,/
>
>Not changed. (I believe the present tense is more readable here)
>
> > S.3.1
> > s/INTEGITY
> >   /INTEGRITY/
>
>Changed.
>
> > S.6.3.
> > "This has consequences when group keying is used; see the Security
> > Considerations section for details."
> >
> > s/consequences/negative consequences/
>
>Changed.
>
> > S.6.5.
> > "it is not possible to use tunnel-endpoint destination address"
> > s/tunnel-endpoint
> >   /a tunnel-endpoint/
>
>Changed.
>
> > 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.
> >>>
> >>> 
> 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
> >>
> >> ________________________________________________________________
> >> Bob Briscoe,                                BT Innovate & Design
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design
> >

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design