Subject: [secdir] draft-ietf-avt-rtp-g719-04, RTP Payload format for G.719

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 7 Dec 2008 18:37:48 -0700

Review of draft-ietf-avt-rtp-g719-04, RTP Payload format for G.719

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other review comments.

The security section discusses the implications of encrypting only
data, not headers, or of turning encryption on and off in the data
stream, or authenticating only headers, not data.  Although I agree
that these are security considerations, I have the feeling that they
are only part of a larger story about RTP security, something that is
a superset of SRTP.  If the considerations cannot be mapped to more
closely to an existing protocol, then they might be out of place in
this specification.

I'm uncertain what is intended by this statement in section 10.2:

   To authenticate the sender of the audio-stream, an external mechanism
   MUST be used. 

At first I thought that it meant that the sender of an audio-stream
MUST be authenticated, but on second reading I think it means "if you
want to authenticate the sender, you've got to use something not
specified in this document."  Clarification would help the reader.

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 09:58:05 +0100

> closely to an existing protocol, then they might be out of place in

The security for RTP has never been easy due to that it is a framework
and used in very many different environments. It is true that there
currently are no mechanism that doing security to partial payloads. But
we do have SRTP that only encrypts the payload and not the RTP header.
Due to that people use different security mechanism and may in worst
case go as far as this text implies I think it is of some value of
indicating what must be at least confidentiality protected.

As a writer of many RTP payload formats and a few other RTP extensions I
find it hard to determine what the right level is. Most RTP payload
formats have nothing special to consider. The check list is basically:
- does it contain scripts?
- does it have non-uniform processing?

If not, then confidentiality, integrity and source-authentication is the
issues and the mechanism we do have works normally works on a payload
level, RTP packet level or IP packet level.

The AVT WG do have two documents that are related to this discussion.

One document trying to explain why SRTP isn't a MUST:
http://tools.ietf.org/wg/avt/draft-ietf-avt-srtp-not-mandatory/

The other is the HOW TO guide to write RTP payload formats:

http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-howto/

Following the later this document goes further than what is recommended
there. However, this text was basically published in a previous payload
format RFC 4352.

Comments on either of documents would be appreciated.

But to conclude, I would leave the details in as they are relevant in
the larger scope. But I think we should consider if the general
recommendations for writing RTP payload formats are correctly scoped.

> specified in this document."  Clarification would help the reader.

Yes, that is the later. And I think removing the upper case MUST will
reduced the confusion. But we can also change the sentence to:

If authentication of the sender of the audio-stream is needed, an
external mechanism must be used.

Cullen, can we add an RFC-editor note for the second issue:

Section 10.2:
OLD:

NEW:
If authentication of the sender of the audio-stream is needed, an
external mechanism must be used.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Russ Housley <[email-masked]>
Date: Mon, 08 Dec 2008 12:18:25 -0500

I do not see this as a complete solution.  I'd like to see a bit of 
discussion about where this mechanism is defined.  Is there an 
example of a media stream format that includes authentication?

Russ

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Dec 2008 10:11:51 +0100

Hi,

I will add both the AVT chairs and my co-author on
draft-ietf-avt-srtp-not-mandatory into this thread. Because it does
concern the greater discussion on how to do RTP payload format security
consideration sections.

Russ Housley skrev:
> discussion about where this mechanism is defined.  Is there an example
> of a media stream format that includes authentication?

I would basically say go read
http://tools.ietf.org/wg/avt/draft-ietf-avt-srtp-not-mandatory/
why this turns into a 200-500 word essay assignment. I can do this but
the above document has been created to avoid having this happening.

So SRTP provides authentication in the sense that you can determine if
the sender is in the group or outside of it based on if it is keyed or
not. If you needed true source authentication then to my knowledge we
end up in IPsec or for point to point case TLS/DTLS with or without SRTP
 do also work. For RTP mixer and multi-point use cases there is no
solution due to that the mixer repackages the material. So the possible
trust models prevents true source authentication in this case.

And to my knowledge there are no format that include authentication,
there is one hach by ISMA that provides ADU level encryption in an
attempt to do DRM. But they use RTP packet level authentication and I
don't think anyone has suggested that you do it at a finer level. If the
current text is read to mean that then I would definitely change it.
Because I don't think the payload format is the right place to do
authentication.

>From my perspective we can resolve this in several ways:

1. Leave as it is and basically say go find a suitable solution.

2. Point to possible solutions in draft-ietf-avt-srtp-not-mandatory with
an informative reference.

3. List explicitly what potential solutions there are without going into
detail, simple provide a list and not comment on when or when they do
work. I would also put a disclaimer saying that there might be
additional solutions that also can meet the threat model one has.

4. Make the essay that tries to provide an overview of the IETF
solutions that exist. The big issue is how far into different threat
models one can go. If one starts discussing this it is soon a multi-page
document in itself.

5. I actually uses the template text from
http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-howto/
as that seems to work fine and not be raising objections. At least it
went straight through for draft-ietf-avt-rtp-g711wb. The only thing
don't covered by the template in my mind is the interleaving issue which
is a very minor one.

I do seem to get some security discussion every time I bring an RTP
payload format onto the table. Maybe if I was better at following my own
advice in draft-ietf-avt-rtp-howto I would get less issues. It would be
good if we could get at least some current agreement about what the
right level to discuss issues at are and what additional documentation
that do needs to be published so that people doesn't have to repeat it
all the time. Even if it needs to be repeated that we agree on some
wording that we can put into the template in
http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-howto/

Cheers

Magnus Westerlund

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 9 Dec 2008 13:48:09 +0100

Hi

I would spend my 99 cents on alternative 2 below. 

This because I believe it is asking too much from the payload format author to provide with a detailed analysis of threat models and countermeasures (I would not be able to provide with this info).
The drawback with requiring too much of this in each payload format spec is also that people will in the end only copy-paste the text from older specs with the risk that the information is stale or not applicable to the particular codec or usecase. 

One must also keep in mind that it is often not the same people who do the codecs that do the security stuff. For that simple reason it would be better to allow (or maybe require ?) the payload format author to reference to a document that handles these issues. This would help the payload draft writing to become more of an automated process and reduce the time lag from first draft to an RFC.

Regards
Ingemar

> -----Original Message-----
> From: Magnus Westerlund 
> Sent: den 9 december 2008 10:12
> To: Russ Housley
> Cc: Hilarie Orman; Ingemar Johansson S; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [secdir] draft-ietf-avt-rtp-g719-04, RTP Payload 
> format for G.719
> 
> Hi,
> 
> draft-ietf-avt-srtp-not-mandatory into this thread. Because 
> it does concern the greater discussion on how to do RTP 
> payload format security consideration sections.
> 
> Russ Housley skrev:
> why this turns into a 200-500 word essay assignment. I can do 
> this but the above document has been created to avoid having 
> this happening.
> 
> So SRTP provides authentication in the sense that you can 
> determine if the sender is in the group or outside of it 
> based on if it is keyed or not. If you needed true source 
> authentication then to my knowledge we end up in IPsec or for 
> point to point case TLS/DTLS with or without SRTP  do also 
> work. For RTP mixer and multi-point use cases there is no 
> solution due to that the mixer repackages the material. So 
> the possible trust models prevents true source authentication 
> in this case.
> 
> And to my knowledge there are no format that include 
> authentication, there is one hach by ISMA that provides ADU 
> level encryption in an attempt to do DRM. But they use RTP 
> packet level authentication and I don't think anyone has 
> suggested that you do it at a finer level. If the current 
> text is read to mean that then I would definitely change it.
> Because I don't think the payload format is the right place 
> to do authentication.
> 
> 2. Point to possible solutions in 
> draft-ietf-avt-srtp-not-mandatory with an informative reference.
> 
> 3. List explicitly what potential solutions there are without 
> going into detail, simple provide a list and not comment on 
> when or when they do work. I would also put a disclaimer 
> saying that there might be additional solutions that also can 
> meet the threat model one has.
> 
> 4. Make the essay that tries to provide an overview of the 
> IETF solutions that exist. The big issue is how far into 
> different threat models one can go. If one starts discussing 
> this it is soon a multi-page document in itself.
> 
> as that seems to work fine and not be raising objections. At 
> least it went straight through for draft-ietf-avt-rtp-g711wb. 
> The only thing don't covered by the template in my mind is 
> the interleaving issue which is a very minor one.
> 
> I do seem to get some security discussion every time I bring 
> an RTP payload format onto the table. Maybe if I was better 
> at following my own advice in draft-ietf-avt-rtp-howto I 
> would get less issues. It would be good if we could get at 
> least some current agreement about what the right level to 
> discuss issues at are and what additional documentation that 
> do needs to be published so that people doesn't have to 
> repeat it all the time. Even if it needs to be repeated that 
> we agree on some wording that we can put into the template in

---

From: Russ Housley <[email-masked]>
Date: Tue, 09 Dec 2008 10:13:48 -0500

I'm happy to see the draft-ietf-avt-srtp-not-mandatory coming 
along.  I do not want to hold this document to wait for it. I do not 
know what others think, but either 3 or 5 would work for me.

Russ

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Dec 2008 12:17:03 -0700

On Dec 9, 2008, at 8:13 AM, Russ Housley wrote:

>  I do not know what others think, but either 3 or 5 would work for me.

Both of theses would work for me. 
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Dec 2008 22:06:11 +0200

Hi,
Personally I prefer 5 since it make it easier to payload specification
writers. You can have 3 as part of 5 if you put the information in
draft-ietf-avt-rtp-howto 
Roni Even

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, December 09, 2008 9:17 PM
To: Russ Housley
Cc: Magnus Westerlund; Hilarie Orman; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [secdir] draft-ietf-avt-rtp-g719-04, RTP Payload format for
G.719

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Dec 2008 14:41:48 +0100

Hi,

So lets go with 5 this results in the following RFC-editor note:

Section 10:
OLD:

   RTP packets using the payload format defined in this specification
   are subject to the general security considerations discussed in RTP
   [RFC3550] and any applicable profile such as AVP [RFC3551] or SAVP
   [RFC3711].  As this format transports encoded audio, the main
   security issues include confidentiality, integrity protection, and
   data origin authentication of the audio itself.  The payload format
   itself does not have any built-in security mechanisms.  Any suitable
   external mechanisms, such as SRTP [RFC3711], MAY be used.

   This payload format and the G.719 decoder do not exhibit any
   significant non-uniformity in the receiver-side computational
   complexity for packet processing, and thus are unlikely to pose a
   denial-of-service threat due to the receipt of pathological data.
   The payload format or the codec data does not contain any type of
   active content such as scripts.

10.1. Confidentiality

   In order to ensure confidentiality of the encoded audio, all audio
   data bits MUST be encrypted.  There is less need to encrypt the
   payload header or the table of contents since they only carry
   information about the frame type.  This information could also be
   useful to a third party, for example, for quality monitoring.
   However, as there currently don't exist any mechanism supporting
   differential protection, this behavior isn't expected to be supported
   and requirement of the audio data will be what governs the protection
   of the RTP payload.

   The use of interleaving in conjunction with encryption can have a
   negative impact on confidentiality, for a short period of time.
   Consider the following packets (in brackets) containing frame numbers
   as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular
   continuous diagonal interleaving pattern).  The originator wishes to
   deny some participants the ability to hear material starting at time
   16.  Simply changing the key on the packet with the timestamp at or
   after 16, and denying that new key to those participants, does not
   achieve this; frames 17, 18, and 21 have been supplied in prior
   packets under the prior key, and error concealment may make the audio
   intelligible at least as far as frame 18 or 19, and possibly further.

10.2. Authentication and Integrity

   To authenticate the sender of the audio-stream, an external mechanism
   MUST be used.  It is RECOMMENDED that such a mechanism protects both
   the complete RTP header and the payload (audio and data bits).  Data
   tampering by a man-in-the-middle attacker could replace audio content
   and also result in erroneous depacketization/decoding that could
   lower the audio quality.

NEW:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile.  The
   main security considerations for the RTP packet carrying the RTP
   payload format defined within this memo are confidentiality,
   integrity and source authenticity.  Confidentiality is achieved by
   encryption of the RTP payload.  Integrity of the RTP packets through
   suitable cryptographic integrity protection mechanism.  Cryptographic
   system may also allow the authentication of the source of the
   payload.  A suitable security mechanism for this RTP payload format
   should provide confidentiality, integrity protection and at least
   source authentication capable of determining if an RTP packet is from
   a member of the RTP session or not.

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this memo may vary.  It is dependent on the
   application, the transport, and the signalling protocol employed.
   Therefore a single mechanism is not sufficient, although if suitable
   the usage of SRTP [RFC3711] is recommended.  Other mechanism that may
   be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
   also other alternatives may exist.

   This RTP payload format and its media decoder do not exhibit any
   significant non-uniformity in the receiver-side computational
   complexity for packet processing, and thus are unlikely to pose a
   denial-of-service threat due to the receipt of pathological data.
   Nor does the RTP payload format contain any active content.

My only question is if anyone thinks the second paragraph in 10.1 do
need included in the new note? I think it is a minor issue that has very
short temporal importance and are fine leaving it out.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Dec 2008 08:21:33 -0700

> short temporal importance and are fine leaving it out.

I don't feel strongly but it seems like this is worth mentioning and  
let people figure out if it is an issues or not for their application.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Dec 2008 08:24:25 -0700

I added an RFC Ed note with text below. If we decide to include the  
second para of 10.1, let me know and I will add that too.

---

From: Tim Polk <[email-masked]>
Date: Wed, 10 Dec 2008 19:11:30 -0500

Sorry to be late to the party on this one, but it shouldn't be a  
problem since I agree with everything so far...

That is, I prefer this strategy (following the template in avt-rtp- 
howto) and am happy with the text.  I am only
chiming in to say I think the  text in the second paragraph of 10.1  
*is* important to a small number of
applications, and suggest keeping that text in the RFC Editor Note.

Tim

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Dec 2008 19:51:35 -0700

I put the text into the RFC Ed Note. -  Tim, Magnus, and others, have  
a read of the note and make sure I did not mess it up.