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

[Magnus Westerlund <[e-mail]>]

Tim Polk skrev:
> 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.
> 

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

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