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

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

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

> -----Ursprüngliche Nachricht-----
> Von: Flemming Andreasen [mailto:[e-mail]] 
> Gesendet: Mittwoch, 19. Oktober 2005 22:53
> An: Stach Thomas
> Cc: [e-mail]; Colin Perkins; IETF MMUSIC working group
> Betreff: Re: AW: AW: AW: [MMUSIC] Working group last 
> call:draft-ietf-mmusic-securityprecondition-00.txt
> 
> Thomas
> 
> 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
> > 
> >
> >  
> >
> >>-----Ursprüngliche Nachricht-----
> >>Von: Flemming Andreasen [mailto:[e-mail]] 
> >>Gesendet: Montag, 10. Oktober 2005 17:59
> >>An: Stach Thomas
> >>Cc: [e-mail]; Colin Perkins; IETF MMUSIC working group
> >>Betreff: Re: AW: AW: [MMUSIC] Working group last 
> >>call:draft-ietf-mmusic-securityprecondition-00.txt
> >>
> >>
> >>
> >>Stach Thomas wrote:
> >>
> >>    
> >>
> >>>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
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 

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