Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-mikey-applicability-03.txt

From: Mark Baugher <[email-masked]>
Date: Mon, 4 Dec 2006 16:26:02 -0800

Thanks for writing this I-D.  I read it quickly and have several  
comments.

1. Section 3.2 "An advantage of this approach are that the usage of  
self-signed certificates can avoid PKI."

By itself, self-signed certificates don't really do that.  It is  
necessary to employ some additional kind of authentication or a  
ceremony where the users accept each others' authenticators.  In some  
cases, additional information needs to be exchanged such as the  
fingerprint in comedia tls or the zid in zphone.

2. Section 3.6
    "5.  Provide liveliness tests when involved parties do not have a
        reliable clock"

I have not yet read this draft but I think it addresses one of my  
biggest concerns about MIKEY for Internet operation - MIKEY requires  
synchronized clocks.  Of course, you cannot do this and preserve a  
one or two message exchange.

3. From Section 4.3,"...To achieve this, MBMS uses a three-level key  
management, to distribute group keys to the clients, and be able to  
re-key by pushing down a new group key."

In msec, RFC 4046 describes and recommends some ways for doing all of  
this.

4. From Section 5  Selection and interworking of MIKEY modes

Unlike IKE, many people (viz. rtpsec) think there needs to be one  
mode for Internet operation of certain applications such as voip  
where there is no global infrastructure.  Authenticated Diffie- 
Hellman (zphone) and self-signed certs (DTLS) are two approaches to  
this problem.

Other points.

o SSRC collisions are a major problem when sharing SRTP keys.  I  
think the only secure way to do this is with a one-key-per-sender  
policy.  Otherwise, SSRC collisions are an avenue of attack on the  
system.

o Forking and early media are probably impossible to solve together  
in a one or two message protocol.

Mark
On Dec 4, 2006, at 12:50 PM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multicast Security Working Group  
> of the IETF.
>
> 	Title		: On the applicability of various MIKEY modes and extensions
> 	Author(s)	: S. Fries, D. Ignjatic
> 	Filename	: draft-ietf-msec-mikey-applicability-03.txt
> 	Pages		: 35
> 	Date		: 2006-12-4
> 	
> Multimedia Internet Keying - MIKEY - is a key management protocol
>    that can be used for real-time applications.  In particular, it has
>    been defined focusing on the support of the Secure Real-time
>    Transport Protocol.  MIKEY itself defines four key distribution
>    methods.  Moreover, it is defined to allow extensions of the
>    protocol.  As MIKEY becomes more and more accepted, extensions  
> to the
>    base protocol arose, especially in terms of additional key
>    distribution methods, but also in terms of payload enhancements.
>
>    This document provides an overview about MIKEY in general as  
> well as
>    the existing extensions in MIKEY, which have been defined or are in
>    the process of definition.  It is intended as additional source of
>    information for developers or architects to provide more insight in
>    use case scenarios and motivations as well as advantages and
>    disadvantages for the different key distribution schemes.  The use
>    cases discussed in this document are strongly related to dedicated
>    SIP call scenarios providing challenges for key management in  
> general
>    beyond them media before SDP answer, forking, and shared key
>    conferencing.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- 
> applicability-03.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-ietf-msec-mikey-applicability-03.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-ietf-msec-mikey-applicability-03.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]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 6 Dec 2006 14:02:30 +0100

Hi Mark,

thanks for the comments. I made some notes inline.

Regards
	Steffen

> Thanks for writing this I-D.  I read it quickly and have 
> several comments.
Great, if it is helpful.

> 1. Section 3.2 "An advantage of this approach are that the 
> usage of self-signed certificates can avoid PKI."
> 
> By itself, self-signed certificates don't really do that.  It 
> is necessary to employ some additional kind of authentication 
> or a ceremony where the users accept each others' 
> authenticators.  In some cases, additional information needs 
> to be exchanged such as the fingerprint in comedia tls or the 
> zid in zphone.
Agreed, I will add a comment to this.

> I have not yet read this draft but I think it addresses one 
> of my biggest concerns about MIKEY for Internet operation - 
> MIKEY requires synchronized clocks.  Of course, you cannot do 
> this and preserve a one or two message exchange.
The draft has not been submitted regarding SAML assisted DH. I basically
took the information from the 2 presentations in MSEC and a talk to Bob.
Nevertheless, I thought the approach is interesting and therefore I kept
the information in here.

> 3. From Section 4.3,"...To achieve this, MBMS uses a 
> three-level key management, to distribute group keys to the 
> clients, and be able to re-key by pushing down a new group key."
> 
> In msec, RFC 4046 describes and recommends some ways for 
> doing all of this.
We were just reflecting what the RFC4563 is about. 
 
> Unlike IKE, many people (viz. rtpsec) think there needs to be 
> one mode for Internet operation of certain applications such 
> as voip where there is no global infrastructure.  
> Authenticated Diffie- Hellman (zphone) and self-signed certs 
> (DTLS) are two approaches to this problem.
Well, I'm not sure if it is manageable with just one mode given the
multitude of key management approaches we have for voice I would be glad
if we could bring it down to 3. 
 
> Other points.
> 
> o SSRC collisions are a major problem when sharing SRTP keys. 
>  I think the only secure way to do this is with a 
> one-key-per-sender policy.  Otherwise, SSRC collisions are an 
> avenue of attack on the system.
Agreed, this would be the best way in terms of security.

> o Forking and early media are probably impossible to solve 
> together in a one or two message protocol.
You are probably right here. From my point of view at least 3 messages
are necessary.

> > This draft is a work item of the Multicast Security Working 
> Group of 
> > the IETF.
> >
> >    protocol.  As MIKEY becomes more and more accepted, 
> extensions to 
> > the
> >    This document provides an overview about MIKEY in 
> general as well 
> > as
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-ietf-msec-mikey-applicability-03.txt".
> >
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > 	"FILE 
> /internet-drafts/draft-ietf-msec-mikey-applicability-03.txt".
> >