AW: AW: [MMUSIC] Working group last call:draft-ietf-mmusic-securityprecondition-00.txt

["Stach Thomas" <[e-mail]>]

Hi Flemming, 

thanks for the response. I think we are pretty much on the same track.

More inline.



> -----Ursprüngliche Nachricht-----
> Von: Flemming Andreasen [mailto:[e-mail]] 
> Gesendet: Mittwoch, 05. Oktober 2005 21:22
> An: Stach Thomas
> Cc: [e-mail]; Colin Perkins; IETF MMUSIC working group
> Betreff: Re: AW: [MMUSIC] Working group last 
> call:draft-ietf-mmusic-securityprecondition-00.txt
> 
> 
> 
> Stach Thomas wrote:
> 
> >Hi Fleming and Dan,
> >
> >first of all sorry for sending my comments rather late. 
> Nevertheless, I'd like to ask for some clarification since 
> details on the usage of SDP Security Description and 
> Key-Management extensions are rather scarce. You are 
> referencing SDP Security Description [SDESC] and 
> Key-Management extensions [KMGMT] as means to exchange the 
> necessary keys. 
> >Since both IDs say that preconditions are out of scope, I 
> expect the pre-conditions document to specify some necessary details. 
> >I can't find normative text on how to exactly do key 
> exchange in conjunction with the security pre-conditions. 
> >
> >My problem is how exactly shall one construct the crypto 
> line/key-mgmt line for the second offer/answer exchange? 
> >
> >The shown examples seem to indicate that in the second offer 
> the same keys shall be sent as in the first offer, which of 
> course makes sense. But since this is marked as an example I 
> can't rely.
> >I could imagine that in the second offer/answer someone 
> might send some other key material or omit the 
> crypto/key-mgmt line since the keys are already exchanged. 
> >
> By definition, SIP preconditions follow SIP offer/answer rules, and 
> offer/answer rules imply that each offer and each answer convey the 
> complete set of current media stream parameters, it is not partial, 
> differential, or anything like that, so we cannot omit the 
> crypto/key-mgt lines.
> 
> >I would rather like to see some normative language that 
> requires a certain behavior. 
> >  
> >
> In terms of offers and answers containing complete information, that 
> normative text is found in RFC 3264. I'll be happy to add a 
> reference on that point. 
> In terms of the actual value to use in the 
> subsequent offer, 
> we'll add some text (basically saying that in order to satisfy the 
> security precondition, you need to use the same key material 
> etc. in the 
> subsequent offer).

That would be great. Of course 3264 must be satisfied. Therefore, this document could concentrate on the security preconditon handling. 
> 
> >Furthermore, assuming that the second offer contains the 
> same key material as the first, I would also expect to find 
> the same data in the second answer as in the first one, 
> especially when I use Diffie-Hellmann key exchange.
> >  
> >
> Offer/answer does not require the same answer to be given, to 
> the same 
> offer, however, in order for the security precondition to be 
> meaningful, 
> we actually want the subsequent answer to contain the same keying 
> material, etc. We'll add some text around that.

My intention was to clarify the handling of the key material.
I agree on the rest of the offer/answer exchange. 
Just for completeness, the second offer could already be different (within the constraints of the offer/answer model).
Here, I think at the one of N codec selection as mentioned in RFC 3264.

> 
> >Sending again the same MIKEY message in the second offer can 
> interfere with the replay attack handling of MIKEY. Of course 
> we don't want to regard the second message as a replay. 
> >How should that be handled? 
> >Maybe it is fine to e.g. hide the second MIKEY message from 
> the MIKEY handler and just check if it is identical to the first one? 
> >Or I could also imagine that some one updates the time stamp 
> for the second MIKEY message? But will/should that be 
> interpreted as re-keying by the MIKEY handler? Remembering 
> postings on implementor's lists I could imagine other weird 
> interpretations too.
> >
> >  
> >
> There are two issues here really:
> 1. kmgmt is a container that can be used to carry pretty much 
> anything, 
> so I'm not sure we can come up with a set of procedures that are 
> guaranteed to work for everything here. Some general statements will 
> probably have to be provided with a note that specific requirements 
> above and beyond those may have to be provided by the actual key 
> management protocol being used. In the current document, we 
> have simply 
> noted that the details depend on the actual key management protocol 
> being used, but we can probably say a bit more than that 
> (specifically 
> on subsequent offers and answers).

Fully agreed. 

> 2. MIKEY is an example of a specific key management protocol 
> used with 
> the kmgmt extensions, and, as you point out, we should probably say 
> something about how to deal with MIKEY in here.  If you have any 
> specific suggestions for how to deal with MIKEY here, they 
> would be very 
> welcome.
> 

I guess you want some proposal before the cut-off for IETF-64. 
I'll try to send it during next week, if that's alright.


Kind Regards
Thomas

> 
> >More comments:
> >I'm missing RFC2119 as a normative reference although it is 
> mentioned in sec 1.  Please add.
> >
> >The MIKEY examples show the same key-mgmt lines in the offer 
> and answer which is not the case. 
> >
> >  
> >
> Will fix both of these.
> 
> Thanks for the comments.
> 
> -- Flemming
> 
> >Kind Regards 
> >
> >Thomas
> >
> >
> >
> >  
> >
> >>-----Ursprüngliche Nachricht-----
> >>Von: [e-mail] [mailto:[e-mail]] 
> >>Im Auftrag von Colin Perkins
> >>Gesendet: Montag, 01. August 2005 18:05
> >>An: IETF MMUSIC working group
> >>Betreff: [MMUSIC] Working group last 
> >>call:draft-ietf-mmusic-securityprecondition-00.txt
> >>
> >>This is to announce a working group last call on the Security  
> >>Preconditions for SDP <draft-ietf-mmusic- 
> >>securityprecondition-00.txt>.  Please send any final comments 
> >>on this  
> >>draft to the <[e-mail]> mailing list by 29th August 2005.
> >>
> >>If no substantive issues are raised by that time, we will 
> >>request the  
> >>IETF publish this draft as a Proposed Standard RFC.
> >>
> >>Colin
> >>
> >>
> >>_______________________________________________
> >>mmusic mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/mmusic
> >>
> >>    
> >>
> >
> >  
> >
> 

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic