Subject: [MMUSIC] Re: ADs - Re: Status of draft-ietf-mmusic-sdescriptions-12.txt?

From: Mark Baugher <[email-masked]>
Date: Tue, 7 Feb 2006 19:01:40 -0800

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Feb 2006 09:22:05 +0000

Folks,

In the interests of making progress, please provide any comments on  
this proposal to the mailing list before 15th February.

Colin

On 8 Feb 2006, at 03:01, Mark Baugher wrote:
> 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.
>
> However not everyone in the SIP community likes preconditions due  
> to the added state machine complexity and signaling latency.  The  
> change, we would not have a complete normative solution for SIP.   
> So, we're asking the WG members for comments.  draft-ietf-mmusic- 
> 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
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 8 Feb 2006 12:57:48 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Baugher
> Sent: Tuesday, February 07, 2006 10:02 PM
> To: [email-masked]
> 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,
>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 8 Feb 2006 11:14:32 -0800

Hadriel,
   Thanks for your comments.

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

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 8 Feb 2006 15:54:56 -0500

Comments inline...

> From: Mark Baugher [mailto:[email-masked]]
> Sent: Wednesday, February 08, 2006 2:15 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; 'Flemming Andreasen'; 'Dan Wing'; 'Jon Peterson';
> 'Allison Mankin'; 'Brian E Carpenter'; 'Colin Perkins'; 'Joerg Ott'
> Subject: Re: [MMUSIC] Re: ADs - Re: Status ofdraft-ietf-mmusic-
> sdescriptions-12.txt?

But doesn't that problem get solved with unique MKIs?  In the way
draft-wing-mmusic-sdes-early-media-00.txt handles it, or at least that's how
I read it.

> for specifying direction semantics.  In the earliest versions of SDP

Yup, sorry meant it more in the sense that when you make the offer you're
saying you can immediately receive any of the offered codecs at the offered
ports. (ie, with respect to early media)  A nit really.

> described above, I'd personally support that.  But it doesn't.

I was waiting for that, so I could say wouldn't that also apply to
draft-wing-mmusic-sdes-early-media-00.txt, since the draft allows the
offerer to tell the answerer both keys?  But thinking about this more, I
guess having both ways lets the market choose, which is preferred.

As to the overlapping SSRC problem with an offered key, I think the risk of
that happening, and happening for long enough to be cracked (in practical
terms), etc., is outweighed by the usefulness of early media.  But we'll get
there with the early-media draft, or just by 1xx responses w/SDP, so problem
solved.  :)

-hadriel

---

From: Mark Baugher <[email-masked]>
Date: Wed, 8 Feb 2006 14:12:14 -0800

> draft-wing-mmusic-sdes-early-media-00.txt handles it, or at least  

I think it's tricky to use MKIs in this way.

> ports. (ie, with respect to early media)  A nit really.

I see your point.  We chose to treat keys differently than codecs for  
the reasons I mentioned in my previous note.

> offerer to tell the answerer both keys?

I think it's fine to pass both keys to mitigate the problem of  
sending media before the answer is received.

> But thinking about this more, I
> terms), etc., is outweighed by the usefulness of early media.

I agree.

> But we'll get

We can only hope ;-)

cheers, Mark