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

[Colin Perkins <[e-mail]>]

Thomas, all,

Thanks for your comments. The working group last call has now ended  
and the draft will not be advanced at this time, pending an update to  
address these comments.

Colin



On 29 Aug 2005, at 16:50, 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. I would rather like to see some  
> normative language that requires a certain behavior.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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
>


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