Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt

From: Colin Perkins <[email-masked]>
Date: Wed, 09 Apr 2003 00:45:28 -0400

I've just completed a detailed read-through the the key management
extensions draft, and have a number of comments:

 - In section 3.1, first paragraph after bullet points on page 6, what
   happens if the key management protocol accepts the data in some
   attributes, and rejects the others? For example if a media level 
   key management attribute is valid but the session level isn't? 

 - In the second paragraph on page 8, does "The offer MUST then abort the
   security setup" mean that the entire session is aborted? Or does it go
   ahead without security?

 - I don't understand the discussion of resynchronization in the last
   paragraph of section 3.2. Can you clarify what is intended?

 - Given the risks identified in the third paragraph of section 5, it's not
   clear to me why the entire SDP message doesn't need to be authenticated?
   Are attacks possible by manipulating the non-authenticated parts of the
   SDP?

I also have a number of editorial suggestions, which I'll forward to the 
authors.

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

---

From: "Fredrik Lindholm (EAB)" <[email-masked]>
Date: Mon, 14 Apr 2003 08:36:32 +0200

<snip...>
> >I have never understood why people don't apply security to 
> things :-) 
> >However, when it comes to SDP, the protection of the SDP will 
> >very much depend on the protocol carrying SDP and what security 
> >features are implemented (and defined as necessary). So it is out 
> >of the scope of this document to specify how to protect the SDP, 
> >and that is also why we only give a recommendation that you should 
> >apply some form of protection to the SDP.
> 
> But if the SDP has to be transferred by a secure channel, 
> what is the point
> of MIKEY?  

The SIP/SDP may only be protected hop-by-hop (i.e. between the 
SIP proxies and SIP proxy - terminal). MIKEY is then needed to provide 
end-to-end security for the media streams. More or less, you only 
need to trust the proxies to provide a reliable transport, but 
you do not need to trust the proxies for your media.

An almost analogous example would be email. You may use SSL to your 
mail server (to secure your session and account), but if you like 
end-to-end protection, you do not rely on this but apply something 
like S/MIME... 

> >If you, by attacks, are referring to attacks towards the key 
> management 
> >and the secured media, I would say no.
> 
> But is may be possible to redirect a media stream, for example?

Of course (note though that there are plenty of other methods to 
do re-direction attacks of streams if you happen to be "on-the-path"...).  

Fredrik

---

From: Mark Baugher <[email-masked]>
Date: Tue, 15 Apr 2003 11:26:07 -0700

Jon,

At 04:45 AM 4/15/2003 -0400, Peterson, Jon wrote:
<...>

>This of course speaks only to carrying SDP in SIP. But is it true that all
>of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME
>types, and consequently could use S/MIME if needed?

SAP is to a group so we won't get confidentiality but would get authentication.

Mark

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Apr 2003 15:26:41 -0400

[snip]
> SAP is to a group so we won't get confidentiality but would 

I imagine that for redirection attacks targeting m= lines, and similar
mischief, the properties we really want are authentication and integrity,
which do seem achievable for SAP.

Jon Peterson
NeuStar, Inc.