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

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

 

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]] 
> 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.
>
> 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.

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.

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

(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

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


_______________________________________________
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