On Mar 31, 2009, at 8:27 AM, Hadriel Kaplan wrote:
RFC 4474 can be used end to end. It all depends on which cert is used
to sign the identity, where that signing occurs, and where it gets
checked. For stupid legacy phones, it can be signed and checked at
middleboxes operating under some level of transitive trust. For
smarter devices, it happens in the endpoint.
Ummm.... nafaik. If your AoR is of the form [email protected], then
even if your UA endpoint has a cert and signs the request, any
middlebox which has a cert for "domain.com", or "*.domain.com", can
willy-nilly replace your signature and do lawful interception.
Not quite.
Here's how I understand it to work:
If the signing cert is [email protected] instead of domain.com, then the
middlebox would need to work with a CA to mint a cert having that full
name. A more typical scenario would have the middlebox use a cert with
name "domain.com". The verifying node can tell the difference.
But even better, with RFC 4474 I might have a connection to AT&T. I
might use this connection to send a call with an Identity header for "[email protected]
". If you have any relationship with me at all, you know AT&T isn't
likely to have the private key for the softarmor.com CA certificate or
for my private certificate issued by that CA. So AT&T isn't a MITM
attacker in this scenario.
Of course, if AT&T's accursed SBC strips off my RFC 4474 Identity
header and inserts their own useless declamation asserting some bogus
phone number then my assertion is useless, we could have a MITM, and
I'm changing carriers.
--
dean
_______________________________________________
Sip mailing list https://www.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
