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

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 Nov 2007 12:09:41 -0800

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 06 Nov 2007 10:24:00 -0500

Dan,

Thanks for moving quickly towards a -01 version of the draft.

>is not yet clear if draft-wing-sipping-srtp-key (or something like it) 
[MBL]: I understand the need for media recording (with the concent and 
cooperation of the end-point) in many environments. However, it is not 
clear to me that the media security key management protocol is the right 
place to solve the media recording problem. That is, regardless of which 
key management protocol I use between the endpoints, each endpoint is 
going to end up with the SRTP key. Once an endpoint who consents to 
media recording has the SRTP key, he can use a separate mechanism to 
support media recording. My fear is that integrating the media recording 
as part of the key management protocol will add significant complexity 
to the key management protocol to solve a problem that could easily be 
solved with a separate protocol mechanism.

>other SDOs that need to provide lawful intercept with their solutions.
[MBL]: I understand that other SDOs have requirements for lawful 
intercept. However, my understanding from reading RFC 2804 is that the 
IETF does not include such requirements in its documents.

>are common on many SIP networks.
[MBL]: I am confused by this requirement. Clearly, in many environments 
SBCs (and other intermediate nodes) are used to terminate and process 
media (e.g. to translate between two different codecs). However, in any 
environment where an intermediate node is processing the media, there is 
no way that end-to-end security of media can be achieved. (Indeed, from 
a security point of the view, the intermediate node who that processes 
the media stream is playing the role of a man-in-the-middle.) Therefore, 
I'm not sure what R25 is trying to require.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Nov 2007 07:56:28 -0800

> >is not yet clear if draft-wing-sipping-srtp-key (or 
> >something like it) meets requirement R23.
>
> [MBL]: I understand the need for media recording (with the concent
> and cooperation of the end-point) in many environments. However, it
> is not clear to me that the media security key management protocol
> is the right place to solve the media recording problem.  That is,
> regardless of which key management protocol I use between the
> endpoints, each endpoint is going to end up with the SRTP key. Once
> an endpoint who consents to media recording has the SRTP key, he can
> use a separate mechanism to support media recording. My fear is that
> integrating the media recording as part of the key management
> protocol will add significant complexity to the key management
> protocol to solve a problem that could easily be solved with a
> separate protocol mechanism.

I agree solving the problem within the key management protocol
may not be the right place to solve it.  However, the requirement
to have it solved remains necessary.  I don't know where
else to capture this requirement, and am open to suggestions.

I am co-author of draft-wing-sipping-srtp-key, which proposes
one solution to meet requirement R23, using PUBLISH.

> intercept. However, my understanding from reading RFC 2804 is 
> that the IETF does not include such requirements in its documents.

That is also my understanding from RFC1984 and RFC2804.

Yet, IETF has stated that it owns SIP standards.  This leaves IETF
in an interesting position which I, as an author, am unable to 
reconcile.

> [MBL]: I am confused by this requirement. Clearly, in many
> environments SBCs (and other intermediate nodes) are used to
> terminate and process media (e.g. to translate between two different
> codecs). However, in any environment where an intermediate node is
> processing the media, there is no way that end-to-end security of
> media can be achieved. (Indeed, from a security point of the view,
> the intermediate node who that processes the media stream is playing
> the role of a man-in-the-middle.) Therefore, I'm not sure what R25
> is trying to require.

Transcoding of media by a device outside of the endpoint.  For
example, a device might be on a bandwidth-constrained link but
due to peering or interoperability requirements (such as those
that are born out of SPEERMINT), it might be necessary for the
initial Invite to offer both the highly-compressed codec and a
'typical' codec for interoperability (say, G.711).  However,
G.711 takes up too much bandwidth for the bandwidth-constrained
link.

Today, this is solvable with RTP, and being done with RTP.

We also want this solvable with SRTP.  It is well-known how
to solve this with Security Descriptions [RFC4568]; what is 
important is to provide solutions for this with other key
management protocols, such as DTLS-SRTP.

I have added "transcoding and SBC" as examples to R25, but if
there is additional wording that would be helpful, please let 
me know; perhaps we should add a section at the top (which we 
have done for some of the more complicated requirements)??

-d

---

From: Richard Barnes <[email-masked]>
Date: Tue, 06 Nov 2007 11:51:45 -0500

Dan,

I agree that R23 and R25 aren't necessarily related to lawful intercept, 
but all three requirements are related to third parties having access to 
plain-text media -- and the whole point of encrypting data is to protect 
it against access by unauthorized third parties.  In order to provide 
access to these parties (quality of service, law enforcement, or 
middleboxes) and still provide security, either (1) the protocol needs 
to have some mechanism for explicitly authorizing these users, or (2) 
there needs to be an out-of-band mechanism like draft-wing-sipping-srtp-key.

Option (1) (explicit authorization) is (IMO) the much less appealing option:
1. It directly conflicts with R24, since it enables the endpoints to be 
aware that another party is being given access.
2. It means that the requirements can only be satisfied by a multi-party 
/ multicast keying protocol (since it has to assume that there are at 
least three parties to a call).
3. It adds hard authentication requirements (so that not just anyone can 
be the listening party), which will hinder deployment

Option (2), on the other hand, requires no text in the media security 
requirements.  It provides the same functionality, with two caveats:
1. One endpoint has to be willing to transmit the keys to the listener. 
  In a enterprise network, this isn't a problem, since endpoints are 
tightly controlled.  A VSP that wants to provide lawful intercept can 
just block SRTP calls that don't provide a key.
2. The listener has to be willing to tolerate the delay induced by 
routing the keys through SIP.  AFAIK, there are no requirements for 
real-time recording or lawful intercept, but this may be a small problem 
for middleboxes.

So on the whole, it seems to me like option (2) covers at least two of 
the three use cases you've proposed.

--Richard

> is not yet clear if draft-wing-sipping-srtp-key (or something like it) 

It seems like does, provided that (1) endpoints are willing to send key 
to authorized listeners, and (2) the delay induced by SIP is tolerable. 
  Both of these would seem to be true in the enterprise environments you 
describe.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Nov 2007 10:00:22 -0800

> Sent: Tuesday, November 06, 2007 8:52 AM
> To: Dan Wing
> Cc: 'IETF SIP List'; 'Hannes Tschofenig'; 'Fries, Steffen'; 
> 'Francois Audet'
> Subject: Re: Review of draft-ietf-sip-media-security-requirements-00
> 
> Dan,
> 

> I agree that R23 and R25 aren't necessarily related to lawful
> intercept, but all three requirements are related to third parties
> having access to plain-text media -- and the whole point of
> encrypting data is to protect it against access by unauthorized
> third parties.  In order to provide access to these parties (quality
> of service, law enforcement, or middleboxes) and still provide
> security, either (1) the protocol needs to have some mechanism for
> explicitly authorizing these users, or (2) there needs to be an
> out-of-band mechanism like draft-wing-sipping-srtp-key.
>
> 1. It directly conflicts with R24, since it enables the 
> endpoints to be aware that another party is being given access.

Disclosing the SRTP via PUBLISH (option (2)) also creates the same 
awareness.

> 2. It means that the requirements can only be satisfied by a 
> multi-party / multicast keying protocol (since it has to assume that 
> there are at least three parties to a call).

Not necessarily.  It could be accomplished with DTLS-SRTP with two
DTLS handshakes, like this diagram:

   endpoint            middlebox           remote endpoint
      |                     |                     | 
      |                     |<--DTLS ClientHello--|
      |                     |---DTLS SrvrHello--->|
      |                     | ...                 |
      |                     |<--finished--        |
      |                     |---finished--------->|
      |                     |<-SRTP with key "A"->|
      |<--DTLS ClientHello--|                     |
      |---DTLS SrvrHello--->|                     |
      | ...                 |                     |
      |<--finished----------|                     |
      |---finished--------->|                     |
      |<-SRTP with key "B"->|                     |

There are two SRTP keys (A and B), and the middlebox would need
to decrypt SRTP and re-encrypt SRTP.  I expect this is not terribly
desirable due to the computational effort to decrypt and re-encrypt
the SRTP traffic.

> 3. It adds hard authentication requirements (so that not just 
> anyone can be the listening party), which will hinder deployment

That's probably true.

> real-time recording or lawful intercept, but this may be a 
> small problem for middleboxes.

(2) isn't a significant problem, assuming DTLS-SRTP is allowed to
complete before the call is answered (and SRTP wants to start flowing).

> So on the whole, it seems to me like option (2) covers at 
> least two of the three use cases you've proposed.

I agree, which is why I have co-authored draft-wing-sipping-srtp-key.

But I'm trying to step back and ensure that it meets with everyone's
requirements regarding recording (for banks, stock brokers, etc.), 
and transcoding (compressed codecs to 'standard' codecs).  I don't
yet have a message flow for how draft-wing-sipping-srtp-key would
work well with transcoding; what I have sketched out is far 
uglier (more messages) than what everyone does for RTP transcoding 
today.

-d

---

From: Richard Barnes <[email-masked]>
Date: Tue, 06 Nov 2007 14:00:41 -0500

> Disclosing the SRTP via PUBLISH (option (2)) also creates the same 

Acknowledged.  R24 cannot be satisfied by a protocol with robust 
confidentiality protection, without the cooperation of at least one 
endpoint.  The point of confidentiality protection is to prevent access 
by parties that have not been authorized by the communicants to receive 
access -- and that's exactly what R24 requires.

Conversely, if you want to satisfy R24 with a secure protocol, you need 
at least one endpoint to give access to the communications.  That's not 
a problem for the security protocol to solve; it's more in the domain of 
regulation.

Here, let me re-label that:

>    endpoint         man-in-the-middle          remote endpoint
>       |                     |                     | 
>       |                     |<-----make keys----->|
>       |<-----make keys----->|                     |

Your diagram is exactly a man-in-the-middle attack, just with a special 
middleman.  So if you allow the above functionality, either the protocol 
can't detect MitM attacks or it can't provide end-to-end authentication.

> desirable due to the computational effort to decrypt and re-encrypt

I don't how to transcode encrypted media without decrypting and 
re-encrypting.  I think this is more or less a trade-off you have to accept.

> uglier (more messages) than what everyone does for RTP transcoding 

I'm not sure why you would think that things would be the same as for 
RTP transcoding.  You already have to have a transcoder that does crypto 
(unless there are techniques I'm not aware of).  And there's really only 
one more message to the flow (at least conceptually; two if you include 
a response) for the endpoint to deliver key to the middlbox.  For a 
simple case, just have the middlebox act as the presence server in 
draft-wing-sipping-srtp-key:

UAC         middlebox         UAS
  |              |              |
  |<-------establish keys------>|
  |---PUBLISH--->|              |
  |<----200------|              |
  |              |              |

Again here, UAC compliance is not an issue, since presumably the UAC 
wants the services of the middlebox in order for his call to go through. 
  The single major issue is latency, but since we're talking 1-2 UDP 
messages, that seems like it's about as small as you're going to get. 
Any smaller, and you'd have to communicate with the middlebox via a key 
negotiation message, which really dirty protocol design, and doesn't 
save much (it just makes the keying message bigger/slower).

So, in conclusion:
-- R24 is incompatible with secure operation, and
-- Out-of-band mechanisms seem sufficient for other requirements
-- Ergo, R23-35 don't belong in this document

--Richard