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

From: Brian Weis <[email-masked]>
Date: Mon, 8 Nov 2010 09:33:09 +0800

Hi Mark,

Many thanks for your thoughtful comments and suggestions. I believe  
we've addressed them all in version -07. Please let us know if any of  
them are not satisfactory.

Thanks,
Brian, Sheela, and Thomas

On Sep 6, 2010, at 5:53 PM, Mark Baugher wrote:

> 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.

Good catch, thanks.

>
> 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.

Actually, the harmonization is mentioned as the 6th bullet in Appendix  
B. But it's definitely a good idea to specifically call out the GAP  
payload as well.

>
> 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.

There are two SHOULDs in this section. The first one makes sense as a  
SHOULD, because when authorization credentials are restricted to use  
with just one group, that's actually an implicit authorization. But I  
think you meant the second SHOULD. Making this a MUST foils the  
Meadows attack, so that's a great suggestion. We'll change the second  
SHOULD to 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.

We'll look into adding more terms to Section 1.2.

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

OK.

>
> 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."

This text is not quite right. The main point meant here was that a  
rekey protocol is actually an ISAKMP protocol, not that it was a phase  
1 protocol. We'll re-word this to say as much.

>
> 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.

Good point. How about we replace this with "At the culmination of a  
GROUPKEY-PUSH exchange the key server has sent group policy to all  
authorized group members, allowing receiving group members to  
participate in secure group communications."

>
> 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.

OK, good point. We'll re-work this section. However, the video  
broadcast application is a good example of a simple use case that we'd  
like to include.

>
> 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.

This section was intending to convey that there are different choices  
that can be made in the use of a Rekey SA based on the application  
type. We'll clarify this.

>
> 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.

A couple of points here. LKH isn't mandated ("normative"), but it is  
listed as a SHOULD in Section 6.1, so it's a reasonable request that  
implementers "should" be able to find guidance.

Section 5.4 of RFC 2627 does describe the basic operations required to  
implemented LKH, and the draft references this section several places.  
The only LKH processing that is required to be described in the GDOI  
Update document is the format for distributing key packets to group  
members, group member processing of the key packets, and the group  
member semantics for deriving a new KEK.

Thomas' and Lakshminath's book "Multicast and Group Security" has a  
helpful discussion of how to use LKH and we've added that as a  
reference.

>
> 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).

We'll add a section for the Delete payload in Section 5 and reference  
it here.

>
> 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.

Thanks ... we've added a MUST here.

>
> 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?

This sentence is misleading and will be removed.

>
> 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?

We've clarified that the two values are independent.

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

We've added some discussion on possible SID values.

> cheers, Mark

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