Subject: secdir review of draft-ietf-msec-gdoi-update

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Aug 2011 12:51:11 -0400

This update to the GDOI specification significantly improves clarity and
readability.
However, there is one issue that I think should be addressed prior to
publication:

At the top of page 11, the spec claims that a seq payload protects
against group members responding to groupkey-pull messages sent prior to
joining the group.
I'm reasonably sure that should be groupkey-push messages; I believe the
nonce payloads provide replay protection for the pull exchange.

Actually, it's more complicated than that.  Section 3.3 also seems to
believe the sequence number is about pull exchanges. However it says
that  a GM should always expect the push message sequence number to be
reset to 1.
Why is that reasonable? If a group is ongoing, don't we want to tell new
members what the sequence number currently is rather than having them
assume it is 1? The push message is multicast, so we cannot maintain a
separate sequence number for each member.

I think either there is some sort of error with the description of the
replay mechanisms or it requires significantly more explanation.

---

From: Brian Weis <[email-masked]>
Date: Wed, 3 Aug 2011 17:33:30 -0700

Hi Sam,

Thanks for your review.

Your first comment is pointing out a typo (groupkey-pull should be groupkey-push), which I've fixed.

The anti-replay description in Section 3.3 should not say that the push message sequence number will be reset to 1. Text earlier in this section says that the SEQ payload carries the next expected sequence number, and so when the KEK is installed that is the number that should be installed. I've adjusted the text to say this: "If this group has a KEK, the KEK policy and keys are marked as ready for use and the GM knows to expect a sequence number not less than the one distributed in the SEQ payload." Let me know if that change sufficiently clears up the confusion.

Thanks,
Brian

On Aug 1, 2011, at 9:51 AM, Sam Hartman wrote:

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Aug 2011 09:25:22 -0400

>>>>> "Brian" == Brian Weis <[email-masked]> writes:

    Brian> Hi Sam, Thanks for your review.

    Brian> Your first comment is pointing out a typo (groupkey-pull
    Brian> should be groupkey-push), which I've fixed.

    Brian> The anti-replay description in Section 3.3 should not say
    Brian> that the push message sequence number will be reset to
    Brian> 1. Text earlier in this section says that the SEQ payload
    Brian> carries the next expected sequence number, and so when the
    Brian> KEK is installed that is the number that should be
    Brian> installed. I've adjusted the text to say this: "If this group
    Brian> has a KEK, the KEK policy and keys are marked as ready for
    Brian> use and the GM knows to expect a sequence number not less
    Brian> than the one distributed in the SEQ payload." Let me know if
    Brian> that change sufficiently clears up the confusion.

Yes, all looks good.
The typo plus the text in 3e.3 caused me to wonder whether something
more complex than I had anticipated was going on with replay.
The new text is quite clear.