RE: [MMUSIC] Re: ADs - Re: Status ofdraft-ietf-mmusic-sdescriptions-12.txt?

["Hadriel Kaplan" <[e-mail]>]

I am also in favor of changing the security preconditions piece to
Informative.  The fairly rare use of sip preconditions should be an
indicator.

Also, one your lines below I believe is misleading: "Without the answer,
there is no way to determine which crypto offer has been selected by an
answerer that sends media upon receiving the first SDP message."  That's
true, but I thought the real reason an answer has to be sent back for early
media is because the sdes offer was for the keys of the transmitting media
direction (from the offerer to the answerer) - so the offerer does not know
any of the keys to decode early received media until she gets an sdes
answer.  In other words even if only one crypto suite and one key were
offered, you would still need an answer to decrypt early media.

On a side note, I know it's too late to change, but I was always curious why
the sdes offerer sent the keys for transmitting media, instead of the ones
for receive-side as it does with everything else in SDP.  Was there a
rationale for this?

-hadriel


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Mark Baugher
> Sent: Tuesday, February 07, 2006 10:02 PM
> To: [e-mail]
> Cc: Flemming Andreasen; Dan Wing; Jon Peterson; Allison Mankin; Brian E
> Carpenter; Colin Perkins; Joerg Ott
> Subject: [MMUSIC] Re: ADs - Re: Status ofdraft-ietf-mmusic-sdescriptions-
> 12.txt?
> 
> Hello,
> 
> An issue arose during RFC Editor review of draft-ietf-mmusic-
> sdescriptions-12 just prior to publication.  An Internet Draft
> document, Security Preconditions, appears among the Normative
> references.  The authors did not intend for it to be a Normative
> reference; it should have been in the Informative References
> section.  Still, this triggered a review and discussion.  Before
> proceeding to publication, the chairs and ADs wish for the WG to
> consider some of the issues of publishing draft-ietf-mmusic-
> sdescriptions without Security Preconditions.
> 
> SDP security descriptions (sdesc) as defined in draft-ietf-mmusic-
> sdescriptions-12.txt is designed to support a variety of signaling
> protocols that use SDP.  One of the most important is SIP. The way
> sdesc is defined, an answer has to be received before incoming media
> can be processed correctly by the offerer; this is unavoidable in
> cases where there are multiple crypto suites among the SDP offers.
> Without the answer, there is no way to determine which crypto offer
> has been selected by an answerer that sends media upon receiving the
> first SDP message.  This is a problem whenever media commences prior
> to receipt of the SDP answer.
> 
> The authors recognized this problem while working on the sdesc
> specification, and as a result, two of the authors wrote Security
> Preconditions (see draft-ietf-mmusic-securityprecondition-01.txt).
> However not everyone in the SIP community likes preconditions due to
> the added state machine complexity and signaling latency.  The
> current sdesc merely offers security preconditions as one possible
> solution, however it incorrectly lists it as a Normative reference.
> One alternative has already been offered (draft-wing-mmusic-sdes-
> early-media-00.txt) and at least one more extension to sdesc to
> address these issues is in the works.
> 
>   In lieu of the above, the authors would like to change the current
> Normative reference to security preconditions to be an Informative
> reference instead. There is a concern, however, that with such a
> change, we would not have a complete normative solution for SIP.  So,
> we're asking the WG members for comments.  draft-ietf-mmusic-
> sdescriptions-12.txt has finished last call in the WG and the IESG,
> but the document that completed last call relied upon security
> preconditions, which may not be the ultimate solution.  We would like
> to know if anyone in the WG objects to progressing this I-D without
> security preconditions being normative and without another normative
> solution to address the above issues. If you object, please speak up
> and let us know what the normative solution should be.
> 
> Thanks,
> 
> Mark, Flemming & Dan
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic


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