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