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

From: "Fredrik Lindholm (EAB)" <[email-masked]>
Date: Wed, 9 Apr 2003 18:39:30 +0200

Hi Colin,

see comments inline.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: den 9 april 2003 06:45
> To: [email-masked]
> Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt
> 
> 
> 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?

To answer both these questions: session and media level failures 
should be treated the same way, i.e., the entire session is 
aborted (then it is up to the local policy to decide what to do). 

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

Basically, if you need to change keys during an ongoing session, 
we propose to send a new INVITE message (with new crypto parameters
inside).
 
>  - 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?

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.

>    Are attacks possible by manipulating the non-authenticated 
> parts of the
>    SDP?

If you, by attacks, are referring to attacks towards the key management 
and the secured media, I would say no.

Fredrik

> 
> 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
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Sat, 12 Apr 2003 16:16:46 -0400

>aborted (then it is up to the local policy to decide what to do). 

Okay. The draft needs clarification though.

>we propose to send a new INVITE message (with new crypto parameters

Again, okay but the text needs to be clarified.

>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?  

>and the secured media, I would say no.

But is may be possible to redirect a media stream, for example?
Colin
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic