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