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

From: Flemming Andreasen <[email-masked]>
Date: Wed, 05 Oct 2005 15:22:23 -0400

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

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

---

From: "Stach Thomas" <[email-masked]>
Date: Thu, 20 Oct 2005 10:15:25 +0200

Flemming,

Thanks for incorporating the proposed text and for adressing my other comments.
I expect that further changes aren't necessary. 
Hopefully, the draft will make its further way smoothly.

Regards
Thomas

> Von: Flemming Andreasen [mailto:[email-masked]] 
> Gesendet: Mittwoch, 19. Oktober 2005 22:53
> An: Stach Thomas
> Cc: [email-masked]; Colin Perkins; IETF MMUSIC working group
> Betreff: Re: AW: AW: AW: [MMUSIC] Working group last 
> Thank you for the text, which we have incorporated and I believe 
> addresses all your comments in this area, except the 
> following, which we 
> have addressed in the upcoming -01 version as well:
> 1. Added missing reference to RFC 2119
> 2. Added note to the sdescriptions example that we use PRACK 
> instead of 
> UPDATE because the original O/A exchange is complete and the 
> precondition is satisfied immeditaly upon receiving the provisional 
> response.
> 3. Added note to the MIKEY example explaining that MIKEY 
> values differ 
> between offer and answer, however the initial part that is 
> shown is common.
> 
> Please let us know if any other changes are needed.
> 
> Thanks
> 
>        Flemming
> 
> 
> Stach Thomas wrote:
> 
> >Hi Flemming, Dan
> >
> >I propose to add the following 2 paragraphs in section 3 after 
> >the paragraph on page 4 that reads
> >"  When security preconditions are used with the Key Management 
> >   Extensions for Session Description Protocol (SDP) [KMGMT], the 
> >   details depend on the actual key management protocol being used."
> >
> >--------------------------
> >
> >After an initial offer/answer sequence in which the security 
> precondition is
> >requested, any subsequent offer/answer sequence for the 
> purpose of updating
> >the status of the precondition SHOULD use the same key 
> material as the
> >initial offer/answer sequence. This means that the key-mgmt 
> attribute lines
> >[KMGMT] or crypto attribute lines [SDESC] in SDP offers that 
> are sent in
> >response to SDP answers containing a confirm-status field 
> [RFC3312] SHOULD
> >repeat the same data as that sent in the previous SDP offer. 
> If applicable
> >for the key management protocol or SDP security description, 
> the SDP answers
> >to these SDP offers SHOULD repeat the same data in the 
> key-mgmt attribute
> >lines [KMGMT] or crypto attribute lines [SDESC] as that sent 
> in the previous
> >SDP answer. 
> >
> >Of course, this duplication of key exchange during precondition
> >establishment is not to be interpreted as a replay attack. 
> This issue may be 
> >solved if e.g. the SDP implementation recognises that the 
> key management
> >protocol data is identical in the second offer answer cycle 
> and avoids 
> >forwarding the information for further processing. 
> >
> >--------------------------
> >
> >I guess that the SHOULD will require normative reference for 
> [KMGMT] and [SDESC], 
> >which may hold up things until SDPnew is finally out.
> >If the authors want to keep informative references, the 
> normative "SHOULD" may 0
> >of course change to "should".
> >
> >Regards
> >
> >Thomas
> > 
> >
> >  
> >
> >>Von: Flemming Andreasen [mailto:[email-masked]] 
> >>Gesendet: Montag, 10. Oktober 2005 17:59
> >>An: Stach Thomas
> >>Cc: [email-masked]; Colin Perkins; IETF MMUSIC working group
> >>Betreff: Re: AW: AW: [MMUSIC] Working group last 
> >>>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.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>That would be great - thx
> >>
> >>-- Flemming
> >>
> >>
> >>    
> >>
> >
> >  
> >
>