Subject: [MSEC] Comments on draft-ietf-msec-gdoi-update-06

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Sep 2010 17:53:20 -0700

I took some time this weekend to review draft-ietf-msec-gdoi-update-06.  I thought it was a good job with several improvements over RFC 3547.  I think I found a few problems that you might want to consider changing.  And I have a number of other comments for your consideration.

Sec. 1.4: "A future RTP security protocol may benefit from using GDOI to establish group SAs" is now an anachronism since RFC 3711 was published after RFC 3547.  In fact, SRTP has had a GDOI data security I-D and even an implementation.  This work has not been completed since other means of keying SRTP are being standardized and published in the IETF.  I would remove this sentence.

Appendix B:  SA GAP is arguably a significant change that probably should be in your list.  Harmonization of GDOI with RFC 5374 might also be worthy of mention.

Sec. 3.1: If we no longer have a Phase 2 CERT and POP payloads, then I think you might consider making the SHOULD into a MUST.  

Sec 1.3: This section defines terms used in Sec 1.0, the Introduction, which uses terms (e.g. rekey SA) without defining them or pointing to where they are defined in the document.

Sec 1.0:  The last paragraph contains two paragraphs:  The sentence that begins "In summary" should start a new paragraph.

Sec 1.0, bottom of page 3: I don't understand this sentence from point 2, "It is treated as a ISAKMP phase 2 protocol, where the "phase 1" cryptographic policy and keying material is included in the group policy distributed by the GCKS in the GROUPKEY-PULL exchange."

Sec 1.0, top of page 4: "exchange, all authorized group members have received and installed updates to group policy" reads strange to me since this process is not ack'd and it is possible that some authorized grup members have not received or have not installed the updates due to e.g. network partition.

Sec 1.3:  Ten years ago, it could be argued that GDOI is applicable to video broadcast key management.  But it was not picked up by anyone for this application over the years including the IPTV Forum ATIS and the previously-mentioned SRTP.  I do know that it is used in large-scale VPNs and it is probably more likely to be used for managing a large number of CPEs like settop boxes than it is for protecting video broadcast.  I think that shipped has sailed and the more real and more promising applications might be mentioned instead.

Sec 1.3, last sentence: "In all cases, the relevant policy is defined on the GCKS and relayed to group members. Specific policy choices possible by the GCKS depends on each application and further discussion of policy is beyond the scope of this memo" is a little misleading since there is a lot of policy including the new SA GAP that is defined in the memo.

Sec 3.3: "If the KD payload included an LKH array of keys, the initiator takes the last key in the array as the group KEK. The array is then stored without further processing."  Ten years ago we were optimistic that group member management would emerge as an important application.  This has not matured but we have done some LKH prototyping IIRC, but there is no published specification for how to do this.  The problem I have with the LKH normative language is that there is no specification or best practices to guide implementers.  It's not clear to me how to implement LKH based on RFC 3547 or this update.

Sec 4.0, second paragraph: The delete payload is used here but defined below.  This happens several times in this document.  It would help the reader to define the terms when they are used, or to at least reference them (RFC 2409 in this case).

Sec 4.0: "If the SA defines an LKH KEK array or single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair" seems to be a normative statement but does not use normative language.

Sec 5.4.1: "If a group member receives a TEK with an ATD value, but discovers that it has no current SAs matching the policy in the TEK, then it SHOULD create and install SAs from the TEK immediately."  I don't understand this.  Doesn't the SA GAP precede the TEK that it applies to?

Sec 5.4.2: The relationship between ATD and DTD is not mentioned.  Is the DTD value the number of seconds of activation?  Does DTD start when the SA is activated, in which case the de-activation time is ATD + DTD or not?

Sec 5.4.3.1: How does a GCKS allocate all possible SID values if the number space is up to 2^256?

cheers, Mark