On Nov 7, 2007, at 5:17 AM, Elwell, John wrote:
Dan,
Speaking as an individual (not on behalf of another SDO), I don't
believe it is possible to satisfy R24.
With method a, the network element will not be able to provide
appropriate credentials to satisfy a user that he is in communication
with the remote user. Assuming RFC 4474 is used as the basis for
authentication, the certificate provided by the Authentication Service
acting on behalf of user A will sign the request and any self-signed
certificate from UA that will be used in the DTLS handshake. Any
substitution of that certificate by a network element would break the
signature. Any attempt at changing the From URI and Identity header
field by an Authentication Service acting on behalf of the network
element would presumably use a certificate for that domain, not a
certificate for user A's domain, so it would be clear to user B
that the
call has come via that middle domain and is encrypted only as far as
that middle domain.
With method b, as already stated one of the users has to agree to
disclose its key.
Right. I think R24 is awkwardly worded, and should be something like:
R24: The media security key management protocol SHOULD NOT allow
end users to determine whether a specific end-to-end
interaction is being or will be lawfully intercepted.
We know that all calls in a 3GPP-type network are subject to lawful
interception. The question is "Is this specific call being
intercepted or is it more likely to be intercepted than any other call?"
This means that any visible mechanism (keys have to be disclosed or a
decrypting relay agent) must be exercised for every call, otherwise
the act of asking for a key on a specific would reveal that there is
unusual interest in intercepting that specific call.
So, if we (IETF) were to define a mechanism whereby a caller could
electively disclose session keys to a 3rd party (such as a recorder),
and some service provider (or national regulator) were to make use of
this mechanism mandatory for all calls over specific infrastructure,
I think everybody would be as satisfied as they're going to get.
This does raise all sorts of questions like "What happens when two
nodes cheat and report invalid session keys to the LI mechanism?",
something that is obviously doable. But if you ponder it awhile, you
realize that there's really nothing that can prevent two colluding
nodes from applying a secondary encryption, just as there is no real
way to prevent two speakers from talking in code. I once used a
scrambler that clamped over a regular analog handpiece, did a A to D
conversion, encrypted, converted the stream into FSK (sounded like
fax), and inversed the process at the other end. That's why some
countries made it illegal to use unlicensed fax machines and modems
for a while -- anybody who was communicating securely needed to be
investigated. It may also be why some countries originally refused to
upgrade their filters and echo cancelers to support 14.4 modems. But
that cat has long since gotten out of the bag and wandered off
someplace. So the best the LI community can hope for is that the
majority of nodes will cooperate and that auditing mechanisms will
have some chance of detecting those that don't.
--
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
