Subject: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt

From: Mark Baugher <[email-masked]>
Date: Fri, 20 Oct 2006 15:46:30 -0700

hi
   We wish to call you attention to this recent contribution on  
signaling SRTP crypto contexts using ISAKMP GDOI.  Please direct your  
comments about this I-D to msec.

Thanks, Mark

Begin forwarded message:

> From: [email-masked]
> Date: October 16, 2006 12:50:01 PM PDT
> To: [email-masked]
> Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: GDOI Key Establishment for the SRTP Data Security Protocol
> 	Author(s)	: M. Baugher, A. Rueegsegger
> 	Filename	: draft-baugher-msec-gdoi-srtp-00.txt
> 	Pages		: 19
> 	Date		: 2006-10-16
> 	
>    The Secure Real-time Transport Protocol (SRTP) secures unicast and
>    multicast media streams.  Multicast receivers of an SRTP stream
>    therefore share an SRTP master key for multicast message
>    authentication and decryption.  This document describes how to
>    establish a shared, "group key" for an SRTP session using RFC 3547,
>    the Group Domain of Interpretation (GDOI) and RFC 2408, the  
> Internet
>    Security Association and Key Management Protocol.  This document
>    extends GDOI for SRTP group key establishment.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi- 
> srtp-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-baugher-msec-gdoi-srtp-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 20 Oct 2006 15:46:30 -0700

hi

Thanks, Mark

---

From: Liu Ya <[email-masked]>
Date: Mon, 23 Oct 2006 10:53:18 +0800

Hi Mark,

I have a question. What are the expected useage scenarios for GDOI +
SRTP? I notice that in draft-wing-media-security-requirements-00.txt
posted last week, the "shared key conferencing" requirement has been
voted out-of-scope. It seems that the target RTPsec scenarions for
GDOI usage do not exist any more. 

Regards,
Liu Ya 

> 
> hi
> ?We wish to call you attention to this recent contribution on 
> signaling SRTP crypto contexts using營SAKMP GDOI.?Please 
> direct your comments about this I-D to msec.
> 
> Thanks, Mark
> 
> 
> Begin forwarded message:
> 
> 
> 	Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt?/SPAN>
> 	A New Internet-Draft is available from the on-line 
> Internet-Drafts?/SPAN>
> 	directories.
> 
> 
> 	牋 The Secure Real-time Transport Protocol (SRTP) 
> secures unicast and
> 	牋 multicast media streams.?Multicast receivers of an SRTP
stream
> 	牋 therefore share an SRTP master key for multicast message
> 	牋 authentication and decryption.?This document describes how
to
> 	牋 establish a shared, "group key" for an SRTP session 
> using RFC 3547,
> 	牋 the Group Domain of Interpretation (GDOI) and RFC 
> 2408, the Internet
> 	牋 Security Association and Key Management 
> Protocol.?This document
> 	牋 extends GDOI for SRTP group key establishment.
> 
> 
> 
> http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi-sr
> tp-00.txt
> 
> 	To remove yourself from the I-D Announcement list, send 
> a message to?/SPAN>
> 	[email-masked] with the word unsubscribe 
> in the body of?/SPAN>
> 	the message.?/SPAN>
> 	You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce?/SPAN>
> 	Internet-Drafts are also available by anonymous FTP. 
> Login with the?/SPAN>
> 	username "anonymous" and a password of your e-mail 
> address. After?/SPAN>
> 	logging in, type "cd internet-drafts" and then?/SPAN>
> 	http://www.ietf.org/shadow.html?/SPAN>
> 	MIME-encoded form by using the "mpack" utility.?To use this
> 	command.?To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.?Different MIME-compliant 
> mail readers

---

From: Liu Ya <[email-masked]>
Date: Mon, 23 Oct 2006 10:53:18 +0800

Hi Mark,

Regards,
Liu Ya 

stream
to

---

From: Mark Baugher <[email-masked]>
Date: Mon, 23 Oct 2006 08:09:31 -0700

hi Liu Ya,

On Oct 22, 2006, at 7:53 PM, Liu Ya wrote:

> SRTP?

Broadcast, multicast, and conferencing are the applications that come  
to my mind.  If there is group keying for the application, then GDOI  
is one way to manage those keys.

> I notice that in draft-wing-media-security-requirements-00.txt

Personally, I see RTPsec as trying to solve problems with SIP  
signaling of SRTP.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 23 Oct 2006 08:09:31 -0700

hi Liu Ya,

Mark

---

From: Liu Ya <[email-masked]>
Date: Wed, 25 Oct 2006 16:43:59 +0800

Hi Mark,

Some comments are proposed below.

1, In paragraph 2 of section 2, the doc writes:
   "... Using this protocol extension, the GDOI Group Controller/Key
Server (GCKS) provides the cryptographic keys, policies and other
attributes to SRTP (via the API to a GDOI Member). ..."

There are different meanings in above sentence. Such an understanding
might be gotten that those parameters are directly provided from GCKS
to SRTP via the API. In fact, two steps are needed for that purpose.
Firstly, parameters are transported from GCKS to GDOI Member through
GDOI signalling channel, then provided to SRTP via the API between
SRTP and GDOI Member.

2, Two figures are given in the beginning of section 2. The first one,
Figure 2.0-1,  is explicitly explained as a logical diagram. While no
clear text is given to the second one, which is interpreted in
paragraph 3 of section 2. After reading paragraph 3, I get a strong
apprehension that Fig. 2.0-2 is a physical diagram. However, the same
illustrating method are used for the two figures. It is better to
emphasize the physical entities of SRTP source and SRTP receiver in
Fig. 2.0-2, such as, in my suggestion, illustrating the left two
logical entities into a physical sender, the right two logical ones
into a physical receiver.

3, The case of multiple SSRCs within one RTP session is considered in
both RTP [RFC3550] and SRTP [RFC3711]. When GDOI is used in such case,
it is possible that multiple SSRCs need to be transported from GCKS to
SRTP receivers. However, only one SSRC field space is assgined in
SA-TEK, which is defined in section 2.2. 

4, When interpreting the SA-TEK's MKI Leghth field in section 2.2,
page 9, the word 'indicator' is used improperly. MKI is the
abbreviation for Master Key Identifier, not Master Key Indicator
[RFC3771]. And in section 3.2.1 of RFC3711, a special parameter called
MKI indicator is defined for SRTP cryptographic context, indicating
whether an MKI is present in SRTP packets. To distinguish MKI and MKI
indicator, it's better to avoid using the word 'indicator' here.

Regards,
Liu Ya

---

From: Liu Ya <[email-masked]>
Date: Wed, 25 Oct 2006 16:43:59 +0800

Hi Mark,

Regards,
Liu Ya

---

From: Mark Baugher <[email-masked]>
Date: Sat, 28 Oct 2006 10:59:23 -0700

hi Liu Ya
   Thanks for your comments.  See inline, below...

> GDOI signalling channel, then provided to SRTP via the API between

That's what we intended.  Please propose new text if what we wrote is  
not clear enough.

> into a physical receiver.

That's our intention and that's why we introduced Fig. 2.0-2 as being  
a "physical realization".  We rely on an assumption that an API  
operates between two entities on the same computer.  I think drawing  
a box around them as you suggest in a subsequent note to this list  
adds clarity and we should include that in the next revision.

> SA-TEK, which is defined in section 2.2.

The SA-TEK is going to be changed substantially in the next draft.  I  
personally did the diagram.  Brian and Adrian suggested some  
improvements, but we ran out of time before the submission deadline.   
Adrian revised the text and you'll see that in the next revision of  
this I-D.  I do expect that we will have one SA-TEK for each session  
from a given source.  It is also possible to have one SA-TEK and one  
from other sources to a given session.

> indicator, it's better to avoid using the word 'indicator' here.

Agreed.

Thanks, Mark

---

From: Mark Baugher <[email-masked]>
Date: Sat, 28 Oct 2006 10:59:23 -0700

hi Liu Ya

Agreed.

Thanks, Mark