On Nov 8, 2007, at 3:41 AM, Elwell, John wrote:
Dean,
Yes, I tend to agree that key disclosure to an authority on all calls
passing through a domain with LI capability might be the way to go,
but
even then I see problems.
No doubt.
A UA has home domain A that is not required to do LI (an enterprise,
say). On a call by call basis, the UA does not know whether the call
will be routed (directly or indirectly) to a particular domain B that
does LI (a carrier, say), so how does the UA find out that it needs to
report its key to carrier B (or C or D....)?
The domain would have to get (and submit) the key for every call sent
out through a regulated carrier.
I believe it's OK for a user to know whether a given call is being
routed over a private network/Internet or is going through a
regulated carrier, and therefore to know that any call being sent
over the regulated carrier may be subject to LI.
Also, by doing this, any notion of end-to-end security has gone out of
the window. If the key is disclosed to a third party, can the call
really be used for sending banking details etc.? Surely the business
world needs end-to-end security (or at least end-domain-to-end-domain
security), as we have with HTTPS?
Banks take calls over the PSTN every day with less assurance of
integrity and privacy. The proposed approach provides much better
security -- with "how much better" being limited by the scope of the
key distribution. Optionally, one could propose the use of public-key
or identity based crypto to further defend the session key, for
example only sending it after encrypting it with the public key of
the intended recipient.
Many financial and legal operations record every call, and therefore
need a recorder that is either "in the session with a key" or on a
second session that gets a twinning of the media. Some courts might
argue that the second-session recording is inadmissible because it
might have been undetectably altered (it wasn't exactly the same
packets as received by the other end), so there are business legal
reasons to have the recorder in the main media path. Eventually we're
going to have media-level non-repudiation issues, so if you're
looking for a Ph. D. project, that would be a good place to look.
I'm sure the auditing organizations will require record keeping on
where the key goes and which systems have access to it, just as they
are beginning to require around all credit-card transactions.
Sure, I want my calls to be as secure as possible. But there are
operational environments where end-to-end crypto just isn't going to
work.
We're at a decision point here -- do we follow RFC 1984 to the
fullest extent and design a secure protocol that will have limited
applicability, or do we design a protocol with broader applicability
that has explicitly negotiated key sharing?
--
Dean
_______________________________________________
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
