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

[Mark Baugher <[e-mail]>]

Hadriel,
   Thanks for your comments.

On Feb 8, 2006, at 9:57 AM, Hadriel Kaplan wrote:

> 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.

What you say is correct and thanks for the clarification.  My point  
is that it is not simply a matter of handing a bidirectional master  
key or a second, unidirectional master key to the receiver for  
sending its media so long as multiple offers are possible.  The real  
problem to the problem of early commencement of media is the presence  
of multiple offers in the SDP message not the way a key is sent.
>
> 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.

I'm not sure what you mean by "as it does with everything else in  
SDP."  There are recvonly, sendonly and sendrecv attributes in SDP  
for specifying direction semantics.  In the earliest versions of SDP  
security descriptions, we allowed a direction attribute on the key so  
an SDP sender could hand a receiver a key with which to decrypt its  
received stream, encrypt its transmitted stream, or both (the "key  
use indicator" of Section 4.4.2 in http://www3.ietf.org/proceedings/ 
03jul/I-D/draft-ietf-mmusic-sdescriptions-01.txt).  This allowed a  
key to be shared among endpoints, which we generally don't want to do  
when counter mode encryption (the SRTP default) is used.  It also  
confused a lot of people.  We decided to simplify the specification  
by removing it.  I thought at the time that we could in the future  
specify a second key for the receiver to use to encrypt its stream if  
this were needed.  As I mentioned above, however, giving the receiver  
a key does not help with the current problem.

> Was there a
> rationale for this?

We did not want to share a single key by default among two or more  
end systems because SRTP AES counter mode has a risk of counter  
overlap.  Counter overlap has the risk of exposing known plaintext in  
encrypted packets.  The probability of this happening is low:  SRTP  
uses the SSRC to make each stream unique and avoid counter overlap,  
but the SSRC can collide among endpoints.  Thus, we do not want to  
make key sharing a default behavior given this one, known weakness of  
counter mode.

So why not have the SDP offerer offer two keys? The quality of the  
encryption is greatly affected by the randomness of the key.  When  
creating keys, it is best to have each side add some randomness in  
the key derivation as is commonly done in pairwise key establishment  
protocols.  This is not possible for groups and sdesc needs to  
support groups.  Supplying an encryption key to the receiver is risky  
because in some protocols, such as SIP, the supplied key is handed to  
a group of receivers when forking occurs, thus raising the  
probability of SSRC collision.  The next best thing IMHO is to at  
least allow a sender to ensure the quality of a key for *its* data by  
supplying the decryption key for its data.  I'm not religious about  
this point.  If supplying the encryption key (rather than or in  
addition to the decryption key) to the receiver solved the problem  
described above, I'd personally support that.  But it doesn't.

Mark

>
> -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