Subject: [AVT] Review of draft-ietf-avt-profile-savpf-11

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Oct 2007 17:56:18 -0500

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 last call comments.

This document does not say whether it is intended to be on the Standards
Track, Informational, etcetera.  I assume it is intended to be on the
Standards Track.

Although some of the text in this document is somewhat confusing, has a
number of grammatical and other editing errors, and in many places fails
to expand acronyms, it is a simple profile of SRTP.  The security
considerations section covers all the areas that I think needed to be
covered, except, perhaps, two things.

In section 3.4 example #2 contains symmetric key material which, as the
description correctly states, requires confidentiality protection by
whatever channel is used to obtain the given session description.  Other
examples, such as example #1, might require at least integrity
protection, but this is not discussed.  It may be that they do not
require integrity protection, but I can't tell as I'm not an expert in
MIKEY (which was used in the example) and, in any case, other key
management frameworks can be used and some might require at least
integrity protection.  For example, when unauthenticated DH key
exchanges are used I would expect integrity protection by some other
channel to be required in order to prevent MITM attacks.  A small amount
of text should cover this case.

Additionally, it's not clear to me whether whether there are any
attributes of an SDP besides a=key-mgmt: and a=crypto: which might need
integrity and even confidentiality protection.  Additional text about
this would be good.

Nico
-- 

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 Oct 2007 16:30:52 -0700

> Track, Informational, etcetera.  I assume it is intended to be on the

Just to answer this one question (I hope the other ones get answered  
too), yes this is Standards Track.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Oct 2007 09:50:35 -0500

On Tue, Oct 16, 2007 at 09:38:54AM -0400, Tim Polk wrote:
> Thanks for highlighting this in your review.   I believe that all the
> critical information is in RFC 4756, "Key Management Extensions for
> Session Description  Protocol (SDP) and Real Time Streaming Protocol
> (RTSP)", but I am not sure the  linkage is clear enough in
> profile-savpf-11.

Exactly.  The text in this I-D is missing some simple wording in the
examples, and maybe in the security considerations.  Simply stating that
the security considerations of various other RFCs should normally
suffice, but given that the text in examples 1 and 2 is inconsistent (in
terms of specifying what protection the SDPs in them require) I think at
least a small update of the description of example 1 would help a lot.

> The key management attribute (a=key-mgmt) is defined in RFC 4756.
> According to the applicability statement:
> 
> >   In contrast, this specification expects endpoints to have
> >   preconfigured keys or common security infrastructure.  It provides
> >   its own security and is independent of the protection of signaling
> >   (if any).  As a result, it can be applied in environments where
> >   signaling protection is not turned on, or used hop-by-hop (i.e.,
> >   scenarios where the SDP is not protected end-to-end).  This
> >   specification will, independently of the signaling protection
> >   applied, ensure end-to-end security establishment for the media.

Ah, I see then why example 1 might not have stated any need for
integrity protection, though it is needed.

> However, the Security Considerations section highlights the need for
> integrity protection.  The immediate relevant excerpt is:
> 
> >      ....                             However, if the SDP messages
> >      are not sent integrity protected between the parties, it is
> >      possible for an active attacker to change attributes without
> >      being detected.  As the key management protocol may
> >      (indirectly) rely on some of the session information from SDP
> >      (e.g., address information), an attack on SDP may have indirect
> >      consequences on the key management.  Even if the key management
> >      protocol does not rely on parameters of SDP and will not be
> >      affected by manipulation of these, different denial-of- service
> >      (DoS) attacks aimed at SDP may lead to undesired interruption
> >      in  the setup.  See also the attacks described at the end of
> >      this section.
> > 
> >      ...

> After reviewing this, it appears that a couple of simple changes
> could address integrity protection in profile-savpf-11.  First, it
> would be nice  if  Example 1 noted that an integrity protected channel
> was required to support the  security negotiations.   (Examples 3-5
> share that requirement, but I would  hope that careful wording in
> Example 1 could keep us from repeating ourselves.) More importantly,
> the security considerations section really needs an  explicit pointer
> to the security considerations in RFC 4576.

I'm in agreement.  Thanks,

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Oct 2007 12:57:23 -0400

This might be handled by a reference.  When the SDP document 
reviewed, some text was added to it I believe.

Russ

---

From: Tim Polk <[email-masked]>
Date: Tue, 16 Oct 2007 09:38:54 -0400

Nico,

Thanks for highlighting this in your review.   I believe that all the  
critical information
is in RFC 4756, "Key Management Extensions for Session Description  
Protocol
(SDP) and Real Time Streaming Protocol (RTSP)", but I am not sure the  
linkage
is clear enough in profile-savpf-11.

According

However, the Security Considerations section highlights the need for
integrity protection.  The immediate relevant excerpt is:

> are not sent
>    integrity protected between the parties, it is possible for an  
> active
>    attacker to change attributes without being detected.  As the key
>    management protocol may (indirectly) rely on some of the session
>    information from SDP (e.g., address information), an attack on SDP
>    may have indirect consequences on the key management.  Even if the
>    key management protocol does not rely on parameters of SDP and will
>    not be affected by manipulation of these, different denial-of- 
> service
>    (DoS) attacks aimed at SDP may lead to undesired interruption in  
> the
>    setup.  See also the attacks described at the end of this section.
>
>    The only integrity-protected attribute of the media stream is,  
> in the
>    framework proposed here, the set of key management protocols.  For
>    instance, it is possible to (1) swap key management offers  
> across SDP
>    messages, or (2) inject a previous key management offer into a new
>    SDP message.  Making the (necessary) assumption that all  
> involved key
>    management protocols are secure, the second attack will be detected
>    by replay protection mechanisms of the key management protocol(s).
>    Making the further assumption that, according to normal best  
> current
>    practice, the production of each key management offer is done with
>    independent (pseudo)random choices (for session keys and other
>    parameters), the first attack will either be detected in the
>    Responder's (now incorrect) verification reply message (if such is
>    used) or be a pure DoS attack, resulting in Initiator and Responder
>    using different keys.

After reviewing this, it appears that a couple of simple changes  
could address
integrity protection in profile-savpf-11.  First, it would be nice  
if  Example 1
noted that an integrity protected channel was required to support the  
security
negotiations.   (Examples 3-5 share that requirement, but I would  
hope that
careful wording in Example 1 could keep us from repeating ourselves.)
More importantly, the security considerations section really needs an  
explicit
pointer to the security considerations in RFC 4576.

Thanks,

Tim

On Oct 11, 2007, at 6:56 PM, Nicolas Williams wrote:

> secdir mailing list
> [email-masked]
> https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Oct 2007 11:35:37 +0200

Tim Polk skrev:
> is in RFC 4756, "Key Management Extensions for Session Description Protocol
>>    integrity protected between the parties, it is possible for an active
>>    not be affected by manipulation of these, different denial-of-service
>>    (DoS) attacks aimed at SDP may lead to undesired interruption in the
>>    The only integrity-protected attribute of the media stream is, in the
>>    instance, it is possible to (1) swap key management offers across SDP
>>    SDP message.  Making the (necessary) assumption that all involved key
>>    Making the further assumption that, according to normal best current
> After reviewing this, it appears that a couple of simple changes could
> address
> integrity protection in profile-savpf-11.  First, it would be nice if 
> Example 1
> negotiations.   (Examples 3-5 share that requirement, but I would hope that

To my knowledge MIKEY when used in SDP according to RFC 4567 it will
integrity protect the most important SDP parts also to prevent bid-down
attacks. So it is not guaranteed that full integrity protection of the
SDP is needed. However, it is of course advisable to protect against
other attacks on the SDP.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------