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

[Magnus Westerlund <[e-mail]>]

Hilarie Orman skrev:
> 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.

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.

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

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:
   To authenticate the sender of the audio-stream, an external mechanism
   MUST be used.

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir