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

From: "Stach Thomas" <[email-masked]>
Date: Thu, 13 Oct 2005 12:33:54 +0200

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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 19 Oct 2005 16:52:51 -0400

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