[Sip] RE: Review of draft-ietf-sip-media-security-requirements-00

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]] 
> Sent: Saturday, October 06, 2007 3:24 PM
> To: IETF SIP List; 'Dan Wing'; Hannes Tschofenig; Fries, 
> Steffen; Francois Audet
> Subject: Review of draft-ietf-sip-media-security-requirements-00
> 
> High-level comments are in the body of this message.  More detailed 
> comments in the attached RTF file.

Thanks, and please accept my apologies for my delay.

I believe the only outstanding issues are around requirements R23-R25;
see below for details.

> --Richard
> 
> -------------------------------------------------------
> Document: draft-ietf-sip-media-security-requirements-00
> Reviewer: Richard Barnes, BBN
> Review Date: 06 September 2007
> -------------------------------------------------------
> 
> 1. As a document proposing requirements for a security protocol,
>    this document needs more discussion of the system being protected
>    and the level of protection that the desired protocol is to
>    support. Section 5 is a good start on this, and it should be
>    moved forward to be just after the Terminology section.

I have moved this section in -01.


> 2. I think the fundamental security requirement that you're driving
>    at is that the protocol should have a mode of operation in which
>    an attacker must mount active attacks on BOTH the signaling and
>    media path in order to gain access to the keys being negotiated
>    by the protocol, and that even in this case, the attack should be
>    detectable by the endpoints.  This is essentially what's being
>    encoded in requirements R1, R2, and R17, but this should be made
>    clearer in these requirements, and in the security analysis
>    section (i.e., Section 5).

R17 in -00 said:

	The media security key management protocol SHOULD require 
	the adversary to have access to the data as well as the 
	signaling path for a successful attack to be launched.  An 
	adversary that is located only along the data or only along 
	the signaling path MUST NOT be able to successfully mount 
	an attack.  A successful attack refers to the ability for 
	the adversary to obtain keying material to decrypt the SRTP 
	encrypted media traffic.

which I think is sufficiently clear on this point.  Let me know if
you still feel it should be repeated elsewhere.


> 3. Requirements R23, R24, R25 are inappropriate for this document,
>    in that they conflict directly with the security requirements
>    (R1, R2, R17).  A well-designed key-exchange protocol *should* be
>    able to detect a middle-man, authorized or not.  Lawful intercept
>    should be handled outside of the key management protocol, as in
>    draft-wing-sipping-srtp-key.

For reference in this response, R23, R24, and R25 are:

  R23:   The media security key management protocol SHOULD support
          recording of decrypted media.

          Media recording may be realized by an intermediate nodes.  An
          example for those intermediate nodes are devices, which could
          be used in banking applications or for quality monitoring in
          call centers.  Here, it must be ensured, that the media
          security is ensured by the intermediate nodes on the
          connections to the involved endpoints as originally
          negotiated.  The endpoints need to be informed that there is
          an intermediate device and need to cooperate.  A solution
          approach for this is described in [I-D.wing-sipping-srtp-key].

R23 refers only to recording of media.  This is necessary in many 
business environments such as banks, stock brokers, catalog ordering call
centers, and so on.  This is a requirement for many businesses.  It
is not yet clear if draft-wing-sipping-srtp-key (or something like it) 
meets requirement R23.

   R24:   The media security key management protocol SHOULD NOT allow
          end users to determine whether their end-to-end interaction is
          subject to lawful interception.

I agree R24 refers to lawful intercept.  This is a requirement from
other SDOs that need to provide lawful intercept with their solutions.

Another email on R24 lawful intercept will be forthcoming shortly.

   R25:   The media security key management protocol MUST work when
          there are intermediate nodes, terminating or processing media,
          between the end points."

R25 reference to 'intermediate nodes' is to transcoders and SBCs which
handle signaling and media traffic.  It seems important that any keying
mechanism work with such intermediate nodes, as those intermediate nodes
are common on many SIP networks.


> 4. This document needs several more terms defined in the
>    Terminology. The three I spotted were: "media path", "signaling
>    path", and "perfect forward secrecy".  PFS is already defined in
>    the requirements; this text should just be moved to the
>    Terminology section.

Added to -01, thanks.


> 5. If we intend this document to move quickly toward RFC status, it
>    seems like the evaluation appendices will have to be deleted, or
>    at least the parts of them that refer to protocols that are not
>    RFCs or not on their way.

This evaluation captures the protocols under consideration at the 
time that this evaluation occurred.  It is valuable to describe why
some protocols were not selected.  If there are specific protocols
you'd like deleted, please enumerate them; each seems to have its
place (although I do agree several are minor tweaks on other 
protocols).


> 6. Section 3.1 and 3.3 do not appear to be directly related to the
>    requirements as stated.  They should be moved to sections B.2 and
>    B.3, respectively (like the text on SSRCs and ROCs).

Section 3.1 is "Clipping Media Before Signaling Answer" and 
refers to requirement R5:

   R5:    The media security key management protocol SHOULD avoid
          clipping media before SDP answer without requiring PRACK
          [RFC3262].

Section 3.2 is "Retargeting and Forking" and refers to requirements
R1, R2, and R3:

   R1:    The media security key management protocol MUST support
          forking and retargeting when all endpoints are willing to use
          SRTP without causing the call setup to fail, unless the
          execution of the authentication and key exchange protocol
          leads to a failure (e.g., an unsuccessful authentication
          attempt).

   R2:    Even when some end points of a forked or retargeted call are
          incapable of using SRTP, the key management protocol MUST
          allow the establishment of SRTP associations with SRTP-capable
          endpoints and / or RTP associations with non-SRTP-capable
          endpoints.

   R3:    The media security key management protocol MUST create
          distinct, independent cryptographic contexts for each endpoint
          in a forked session.

In -01, I have added text to the beginning of 3.1 and 3.2 to make this
clearer.


> 7. Sections C.1 and C.3 should be deleted.  Section C.1. is
>    predicated on the notion that protocols require a PKI to be used,
>    when in reality (as was discussed extensively on rtpsec), any
>    protocol that can be used with a PKI can be used with self-signed
>    certificates if both endpoints are willing.  Section C.3. tries
>    to evaluate whether solutions can do best-effort security, while
>    ignoring the work that has been done on SDP capability
>    negotiation.

Section C.3 ("Best Effort Encryption") has been updated to 
discuss SDP Capability Negotiation; previously it only said:

     "Note: With the ongoing efforts in SDP Capability Negotiation
      [I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
      reached in this section may no longer be accurate."

which I agree was deficient.


> *. (nit) Throughout, the word "keying" is used to mean the process of 
> key negotiation/exchange or key management.  It should be replaced by 
> those terms as appropriate.

Changed in -01.


Thanks to Steffen for making a significant number of these changes to
the XML.

-d


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip