Subject: [MSEC] Re: Submission of draft-ietf-msec-newtype-keyid-03.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 06 Jan 2006 12:12:21 -0800

At 04:47 AM 11/30/2005, Karl Norrman (KI/EAB) wrote:
>Dear Editor,
>
>please submit the new version of draft-ietf-msec-newtype-keyid-03.txt,
>work item in the msec WG.
>
>Best Regards,
>Karl Norrman
>Ericsson
>

With apologies for the delay, here is my review of the newtype-keyid 
draft with a request (as a member of the WG) for some 
clarifications.  First, I think that this version is much better than 
the previous one, especially the sec considerations section.

*** In Section 1, 3rd paragraph:

The draft says "
The rationale behind this is
    that it would be inconvenient for subscribers to publish the
    decryption keys enabling non-subscribers to view the content."

We have been in uncomfortable in MSEC on this notion.  The closest I 
came to agreeing to this is the cost of the attack (cost 
uploading/downloading keys using the unicast channel) vs. value of 
the content (subscription charge for the broadcast service) 
argument.  Perhaps that notion can be included in the draft. 
Personally I think "inconvenience" is not a strong enough argument.

*** In the last paragraph of Section 2:

Please expand DCF.  (Please expand the first occurrence of all 
abbreviations, especially the non-IETF ones).

*** In the last paragraph of Section 3:

There is a provision to include multiple Key ID types in the GenExt 
payload.  Could you please clarify the use case further?  Is the 
intent to carry MSKs and MTKs in the same MIKEY message?

*** In the security considerations section:

First a question (not specific to this section) on MSK delivery: is 
the MSK always delivered under the protection of individual MUKs?  If 
so, perhaps a statement along those lines will help (MSK delivery 
MUST be protected by MUK.  MTK delivery MUST be protected by MSK or 
something along those lines).

      ** Group authentication for MTK delivery needs more 
clarification.  Other standards have also avoided source 
authenticating group key delivery via broadcast with the reason that 
as long as the data itself is not source authenticated, not source 
authenticating the key delivery will only make it slightly (for some 
definition of slightly :-)) easier for the "insider" attacker.  (A 
side note: The problem with large broadcast groups however is that it 
is presumably easy to become an "insider").

      I propose the (some variation of the) following notes to be added:

         The threat model assumes that the data and the group key 
delivery via broadcast are integrity protected with group 
authentication.  If source authentication is applied to the data 
(using SRTP-TESLA for example), the group key delivery MUST also be 
source authenticated.  (Note: Since there is no relevant 
specification for source authenticated MTK delivery, perhaps this 
document should say that the specified extension is incompatible with 
SRTP-TESLA).

Finally, perhaps we need a section describing the compatibility of 
this extension with the main MIKEY spec and other extensions to 
MIKEY.  I mentioned the SRTP-TESLA extension in the previous 
paragraph.  My recollection of 3830 is that it explicitly states that 
there is no "rekey" protocol specified.  This extension changes that 
notion.  This draft should note that I think to help readers of MIKEY 
specs.  There are also notes in 3830 on how MIKEY fits within the 
GKMarch (4046) RFC.  Please include notes on how this extension 
differs with 3830 in that respect.

(Note: While that mind sound like many things, I think a few 
sentences can sufficiently cover everything).

Thanks again folks.  Is Elisabetta's contact information current in the draft?

best regards,
Lakshminath

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec