Re: francois' comments and why RFC4474 not used in the field

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