Subject: [AVT] RFC4568 session parameter negotiation

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Apr 2008 11:45:53 -0700

Hi All,

I'm trying to understand the proper way to negotiate RFC4568 crypto
attribute
session parameters such as UNENCRYPTED_SRTP.  In section 5.1.2,
Generating the Initial Answer -Unicast Streams, the RFC says

    When the answerer receives the initial offer with one or more crypto
   attributes for a given unicast media stream, the answerer MUST either
   accept exactly one of the offered crypto attributes, or the offered
   stream MUST be rejected.

and

   Furthermore, any session parameters that are negotiated MUST be
   included in the answer.  Declarative session parameters provided by
   the offerer are not included in the answer; however, the answerer may
   provide its own set of declarative session parameters.

So this seems like maybe the answerer can insert its own declarative
session parameters into the crypto attribute in the answer, along with
its keying material, but I'm not clear if it is proper to insert a
negotiated
parameters such as UNENCRYPTED_SRTP, into a crypto attribute in the 
response.  

For example, suppose one receives an SDP offer like the following:

  v=0
  o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
  s=Session123
  i=A test session
  c=IN IP4 10.248.0.239
  t=0 0
  m=audio 5004 RTP/SAVP 0 8
  a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4

and the receiver of this offer is not willing to support SRTP encryption.
Then should
the offer be rejected outright and the call terminated, or is it OK (not in
violation of the
RFC) to respond with an answer that inserts the UNENCRYPTED_SRTP parameter 
inserted into the answer crypto attribute as follows:

v=0
o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
s=Session323
i=A test session
c=IN IP4 10.248.0.240
t=0 0
m=audio 5004 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:
Ukdkw1gfjslkeUvksjelKKkdjwekslkejLKE11dk|2^20|1:4 UNENCRYPTED_SRTP

In other words, per the RFC is it incumbent upon the offerer to explicitly
indicate
a willingness to do unencrypted SRTP, but a preference for encrypted SRTP,
by including
two crypto attriubutes as in

  v=0
  o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
  s=Session123
  i=A test session
  c=IN IP4 10.248.0.239
  t=0 0
  m=audio 5004 RTP/SAVP 0 8
  a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4
  a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:ya3k283klkWWdkjwFek2932ckdejlklkelksl233|2^20|1:4 UNENCRYPTED_SRTP

So then if such a parameter is not present in the offer the answerer can
assume that the offerer
is not willing to support it.

This seems better since it forces offerers to explicitly indicate what
they're willing to negotiate, but
I wanted to make sure whether or not inserting a negotiated session
parameter like UNENCRYPTED_SRTP
into a response is valid.  I'm certainly hoping that it isn't valid since it
would simplify the logic and
probably greatly increase the chances of successful negotiation. 

Regards,

Mike Taylor

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 12:22:23 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mike Taylor
> Sent: Friday, April 11, 2008 11:46 AM
> To: [email-masked]
> Subject: [AVT] RFC4568 session parameter negotiation
> 
> Hi All,
> 
> I'm trying to understand the proper way to negotiate RFC4568 
> crypto attribute
> 
> its keying material, but I'm not clear if it is proper to 
> insert a negotiated
> 
> the offer be rejected outright and the call terminated,

Yes; it is the "m=" line itself, which says RTP/SAVP, that causes the
rejection.  That is not specific to RFC4568.

> or is 
> it OK (not in violation of the
> 
> In other words, per the RFC is it incumbent upon the offerer 
> to explicitly indicate
> 
> a willingness to do unencrypted SRTP, but a preference for 
> encrypted SRTP, by including
> 
> So then if such a parameter is not present in the offer the 
> answerer can assume that the offerer
> 
> This seems better since it forces offerers to explicitly 
> indicate what they're willing to negotiate, but
> 
> I wanted to make sure whether or not inserting a negotiated 
> session parameter like UNENCRYPTED_SRTP
> 
> into a response is valid.  I'm certainly hoping that it isn't 
> valid since it would simplify the logic and
> 

But it requires the answerer to understand RTP/SAVP, and to understand enough
of RFC4568 to generate an answer containing UNENCRYPTED_SRTP.  That seems a
pretty high bar.

draft-ietf-mmusic-sdp-capability-negotiation is the best way to increase the
chances of successful negotiation.  That draft includes some examples of SDP
offers that contain both SRTP and RTP.

-d

---

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Apr 2008 14:27:06 -0700

Hi Dan, 

Thanks for the response but I think you might have misunderstood
my concern.

> rejection.  That is not specific to RFC4568.

I think you missed the "encryption" in the "not willing to 
support SRTP encryption".  The offer says RTP/SAVP and the
answerer is willing to support SRTP (RTP/SAVP) but just doesn't
want to do encryption of the RTP.  Maybe it is a legacy phone, 
for example, and if it has to do encryption that impacts the 
audio quality to the extent that he phone isn't really usable.
Whatever the case may be, it doesn't want to do encryption
but will support authentication of RTP and RTCP.

So in other words, ideally it would like the offerer to include
UNENCRYPTED_SRTP in the offered crypto attribute but in the
example shown above it did not.

So then is the answerer allowed by RFC4568 to insert UNENCRYPTED_SRTP 
into the answer even though it wasn't present in the offer?
Or must it reject the offer under the assumption that RFC4568
dictates that if the offerer preferred to encrypt the RTP but would
be willing not to, then it would have made the offer with two
crypto attributes as shown here:

     inline:ya3k283klkWWdkjwFek2932ckdejlklkelksl233|2^20|1:4
      UNENCRYPTED_SRTP

Then the answerer could choose the second attribute since it
doesn't want to do encryption of the RTP.  If the RFC was very
explicit about this then I think the latter approach would be
better since it allows a full expression of one's preferences
and doesn't require any guesswork on the part of the answerer.
Maybe this is the intent of RFC4568 but I wanted to get 
clarification.

Regards,

Mike Taylor

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 15:37:32 -0700

> From: Mike Taylor [mailto:[email-masked]] 
> Sent: Friday, April 11, 2008 2:27 PM
> To: 'Dan Wing'; [email-masked]
> Subject: RE: [AVT] RFC4568 session parameter negotiation
> 
> Hi Dan, 
> 

Ah.  Ok.  You are right, I had misunderstood.  Thank you for
clarifying.

> example shown above it did not.

If the phone can not receive encrypted SRTP (for whatever reason),
it needs to do the same thing it would do if it cannot receive
G.938 (that is a codec that will be invented in the year 2043) --
it needs to reject the call setup request (in SIP, probably
with a 415 response code).  I believe the problem you are 
describing is similar to my made-up G.938 codec:  you want the 
offerer to send out an incomplete offer, and have the answerer 
guess that the offerer really has additional capabilities than it
advertised in its offer -- specifically, you want an offer to
only mention encrypting SRTP, and you want the answerer to
presume the offerer has the ability to send both 
encrypted+authenticated SRTP, and also has the (silent)
ability to send unencrypted, authenticated SRTP.

This is mentioned in Section 7.1.2 of RFC4568:

  "Furthermore, all parameters (crypto-
   suite, key parameter, and mandatory session parameters) MUST be
   acceptable to the answerer in order for the offered media stream to
   be accepted."

> into the answer even though it wasn't present in the offer?

Yes, so long as the phone can receive encrypted SRTP, it can go ahead
and send encrypted SRTP.  This is because UNENCRYPTED_SRTP is negotiated 
(Section 6.3.2 of RFC4568), and negotiated parameters can be different 
between the offerer and the answerer (Section 5.1.2):

   included in the answer.  

> doesn't want to do encryption of the RTP. 

Right.  That would be the best thing to do if you want to have 
unencrypted SRTP in both directions.

> If the RFC was very

Right.  It also aligns with how offers for other things (e.g.,
codecs) works -- the offer is supposed to contain everything the
offerer is willing to support.  The answerer then picks and 
chooses from that list.

-d

> > But it requires the answerer to understand RTP/SAVP, and to 
> understand
> > enough
> > of RFC4568 to generate an answer containing 
> UNENCRYPTED_SRTP.  That seems
> > a
> > pretty high bar.
> > 
> > 
> > draft-ietf-mmusic-sdp-capability-negotiation is the best 
> way to increase
> > the
> > chances of successful negotiation.  That draft includes 
> some examples of
> > SDP

---

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Apr 2008 16:28:46 -0700

Hi Dan,

>    acceptable to the answerer in order for the offered media stream to

Well, the thing is that I think the operative word here is "mandatory"
which is another aspect of RFC4568 that leaves me wanting.  It discusses
how *new* session parameters are mandatory by default, but doesn't
really say much else about what mandatory means, or if *new" refers to
the session parameters defined in the RFC itself.  

And in paragraphs 6.3.2 and 6.3.3 which discuss the UNENCRYPTED_SRTP 
et. al. parameters it certainly never says that they are mandatory, 
only that they are negotiated.  In fact, now that I search it again I 
can't find where any of the session parameters defined in RFC4568 are
described as mandatory.  However, I just came across this

   Declarative session parameters may be added to the answer as usual;
   however, the answerer SHOULD NOT add any mandatory session parameter
   (see Section 6.3.6) that might be unknown to the offerer.

So then maybe the shortcoming in the RFC is that it fails to define
exactly what a mandatory session parameter is and fails to state whether 
any of those such as UNENCRYPTED_SRTP are mandatory.  By common English
usage one would expect a mandatory parameter to be something that must
absolutely be present in the offer but clearly that isn't the case
for UNENCRYPTED_SRTP.  One might think that it doesn't bother to explain
what a mandatory session parameter is very clearly because it is defined
in RFC4566 or RFC3264 but I don't find the term defined in either of those.

> between the offerer and the answerer (Section 5.1.2):

I'm not so sure that I agree with that.  According to the RFC the
very definition of negotiated session parameters is that they apply
to the session as a whole, i.e., to the media in *both* directions.
According to Par. 4.4

   Negotiated parameters apply to data sent in both directions, whereas
   declarative parameters apply only to media sent by the entity that
   generated the SDP.

So it seems that it is not permitted to do, for example, unencrypted
SRTP in one direction and encrypted in the other direction.

So I'm afraid that I am still left wanting.  Based on the part about
how the answerer SHOULD NOT add any mandatory session parameter I am 
leaning towards believing that maybe the definition of "mandatory" is
not the common sense definition and instead is almost synonymous for
"negotiated" but I can't tell from the RFC what either of the two terms
really means and neither seems to be defined in either of the other
"core" SDP RFCs.  Have you seen formal definitions of these terms in some
other RFCs besides 4566, 4568 and 3264?  

Regards,

Mike Taylor

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 17:22:32 -0700

> Sent: Friday, April 11, 2008 4:29 PM
> Cc: 'Flemming Andreasen'

If the answerer cannot receive SRTP (due to processor limitations,
for example), I don't see a way for the answerer to accept the offer.
I think of it this way:  let's pretend the offerer said "m=holograph",
and I don't have a holography projector.  I can't send an answer that
puts "m=video" in its place, hoping the offerer will downgrade to
simple 2D video instead of a 3D holographic display.

> in RFC4566 or RFC3264 but I don't find the term defined in 

RFC3711 uses the term, but it appears to be for a different
meaning.

>    declarative parameters apply only to media sent by the entity that

You're right, thanks for catching that.

> "core" SDP RFCs. 

The text concerning 'negotiated' was added by Flemming, so I'll let
him comment.

> Have you seen formal definitions of these 
> terms in some other RFCs besides 4566, 4568 and 3264?  

Would it not be effective for your offerer to include two a=crypto lines,
one with UNENCRYPTED_SRTP, and the other without that parameter?

-d

---

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Apr 2008 17:52:21 -0700

Hi Dan,

Thanks to your feedback I think I'm starting to see the light.
First of all, I think that all of the session parameters defined
in RFC4568 are indeed mandatory.  I think that according to the
RFC optional session parameters being with "-".  So with that
understanding I reviewed the RFC again.  When I quoted this
paragraph

     Declarative session parameters may be added to the answer as usual;
     however, the answerer SHOULD NOT add any mandatory session
     parameter (see Section 6.3.6) that might be unknown to the offerer.

I failed to note that important point last time - "that might be unknown to 
the offerer".

So indeed it is OK to insert mandatory session parameters defined
in RFC4568 into an answer an answer.  Nobody implementing RFC4568 would 
find one of those to be unknown.  

However, I think it is unfortunate in a way that the RFC allows it.  I
think it would have been better to disallow it and require that when
constructing an offer the offerer should insert multiple crypto attributes 
to express situations such as "I prefer to do SRTP encryption but will 
permit unencrypted SRTP", such as in my example here, if local configuration
allows such expressions of capability.

Then it would be clear to both parties exactly what the offer is
willing to support so the answerer wouldn't have to bother with
inserting such a mandatory parameter in the hope that the offerer
just might be willing to accept it.  

Furthermore, it is interesting to note that the RFC is very clear about the 
opposite situation that occurs when the offerer is processing the
answer.  From Par. 5.1.3

   If the offer contained any mandatory negotiated session parameters
   (see Section 6.3.7), the offerer MUST verify that said parameters are
   included in the answer and support them.  If the answer contains any
   mandatory declarative session parameters, the offerer MUST be able to
   support those.

   If any of the above fails, the negotiation MUST fail.

Therefore, it seems that the RFC disallows *removal* of parameters.
Therefore, if I am an offerer who wishes to do SRTP *without* encryption
but would be willing to encrypt if the peer so desires, but I send an 
offer with only a single crypto attribute having the UNENCRYPTED_SRTP 
parameter, then if the answerer insists on encrypting the SRTP it 
cannot indicate this by *removing* the UNENCRYPTED_SRTP parameter from 
the offer when creating an answer.  Per Par 5.1.3 the offerer would be
obligated to fail the negotiation in that case!

Now this seems like a more common case, i.e., I should honor the desire
of the peer to have privacy even if I don't particularly care about it.
So in this case it seems that I really better offer two crypto attributes
to clearly express my preference for not encrypting but willingness to
encrypt.

Regards,

Mike Taylor

> From: Dan Wing [mailto:[email-masked]]
> Sent: Friday, April 11, 2008 5:23 PM
> To: 'Mike Taylor'; [email-masked]
> Cc: 'Flemming Andreasen'

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 20:42:02 -0700

> So in this case it seems that I really better offer two 
> crypto attributes to clearly express my preference for not 
> encrypting but willingness to encrypt.

Yes, I think that is exactly what you want to do in this
situation.

-d