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

[Flemming Andreasen <[e-mail]>]

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).

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

>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).
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.


>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