Subject: [MSEC] draft-blom-mm-kmgt-00.txt

From: Mark Baugher <[email-masked]>
Date: Fri, 24 Aug 2001 09:08:26 -0700

Hi
   I re-read draft-blom-mm-kmgt-00.txt and 
draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on the 
first draft now.

   Req 4.1 and 4.2 of 
http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make this 
work relevant to msec since you're concerned with an integrated key 
management for pairwise (e.g., unicast) and group (e.g., multicast) 
applications.  msec's been narrowly focused on SSM, but we're aware that 
group key management may be applied to small groups having many senders, 
which is what draft-blom-mm-kmgt-00.txt considers.  Your draft is timely 
since an msec requirements draft is in the works and your draft is 
concerned with requirements.

   I was confused by sections 2 and 3 since you do not come right out and 
say that your concern is with "security of the media streams" rather than 
"call control security."  In section 4 you say that you are concerned with 
end-to-end security of the media stream (i.e., providing keys for SRTP of 
figure 1).  The relationship between call control and media stream security 
needs more discussion in the draft IMO.

   In section 5, you claim that having more than one party derive the 
session key results in additional round trips.  This is not the case with 
an exchange such as the IKE revised public key encryption exchange.  IKE is 
not appropriate to your requirements of section 6 since IKE is two phase 
and there does not seem to be much need for a two phase key management 
protocol for multimedia session key management.   But I think the revised 
public-key exchange contradicts your point in section 5.1 (I'd like to hear 
what Ran has to say since he was a co-inventor of IKE revised public 
key).  I agree with req. 5.1, however, but not for the reason of increasing 
the round-trip exchanges but because it's the only way to key a group of 
more than two.  I'm not sure about req. 5.2 since I'm not clear on how the 
large-scale size of a PSTN impinges on end-to-end key establishment for 
multimedia sessions.  Although we may rule out IKE, I'd like to say that 
req. 5.5 requires an ISAKMP or IKE approach of separating key management 
from security protocol.

I have some more points on section 5, 6 and 7, but I'll stop here for now 
since the note is already a bit long.

thanks, Mark

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 28 Aug 2001 13:55:37 -0700

Rolf, Elisabetta, Fredrik and Jari,

    Here are the rest of my comments on the draft.

    Req 5.6 is unclear to me: SRTP, for example, associates a crypto 
context (SA) with <SSRC, dest transport address> or just <dest transport 
addr>, so in a sense it might be associated/indexed by an IP address.  A 
bigger question probably has to do with what identity is used for the 
crypto context:  Is it a name associated with a public key, a SPKI cert, 
and X.509 authorization cert, a big number, or what? Does 5.16 contradict 5.6?

   Does 5.11 require that the key management protocol support upgrade to 
new transforms and attributes?  I think you're looking for a key management 
framework since 5.5 requires it to support new security protocols.

   Many of the requirements in 6 are true in general for practically any 
protocol.  They would be more meaningful with thresholds or bounds.

   Req 7.1 is also very general.  You cite cryptographic strength but not 
the security services that are provided such as authenticity, integrity, 
confidentiality or what information is protected (Ran mentioned identity 
protection).  I think the Security Considerations section should discuss 
the threats posed and necessary responses.

Mark

At 09:08 AM 8/24/2001 -0700, Mark Baugher wrote:
> draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on 
> the first draft now.
>
>   Req 4.1 and 4.2 of 
> http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make 
> this work relevant to msec since you're concerned with an integrated key 
> "call control security."  In section 4 you say that you are concerned 
> with end-to-end security of the media stream (i.e., providing keys for 
> SRTP of figure 1).  The relationship between call control and media 
> stream security needs more discussion in the draft IMO.
>
> an exchange such as the IKE revised public key encryption exchange.  IKE 
> is not appropriate to your requirements of section 6 since IKE is two 
> phase and there does not seem to be much need for a two phase key 
> management protocol for multimedia session key management.   But I think 
> the revised public-key exchange contradicts your point in section 5.1 
> (I'd like to hear what Ran has to say since he was a co-inventor of IKE 
> revised public key).  I agree with req. 5.1, however, but not for the 
> reason of increasing the round-trip exchanges but because it's the only 
> way to key a group of more than two.  I'm not sure about req. 5.2 since 
> I'm not clear on how the large-scale size of a PSTN impinges on 
> end-to-end key establishment for multimedia sessions.  Although we may 
> rule out IKE, I'd like to say that req. 5.5 requires an ISAKMP or IKE 
> approach of separating key management from security protocol.
>