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

[Tim Polk <[e-mail]>]

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.

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

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

> 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
> -- 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://mailman.mit.edu/mailman/listinfo/secdir


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