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

[Nicolas Williams <[e-mail]>]

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

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