Re: [Sip] Where Dean Went Wrong With Signing P-Asserted-Identity

["Dan Wing" <dwing at cisco.com>]

> On 7/17/08 7:23 PM, Dean Willis wrote:
> >
> > -------
> > I've been informed that despite what I incorrectly thought, 
> > transitive  signing doesn't require any modification to RFC 4474.
> >
> > The 4474 spec requires that the subject of the cert used to sign  
> > correspond to the domain of the From. This is different from 
> > requiring  that the common names match. So any SBC can re-sign 
> > anything at any  time and break nothing, at the expense of 
> some crypto 
> > work.
> >
> > So, let's say adam at nostrum.com calls mat at cisco.com. Nostrum's AS 
> > might  sign Adam's INVITE.  Cisco's SBC might verify the signature, 
> > munge the  fields, mint itself a cert with a subject of 
> "nostrum.com" 
> > (using its  well-known Cisco CA key to sign that cert!) , and then 
> > sign the  request (replacing the Nostrum signature) using the new 
> > cert. Then mat at cisco.com  would verify Cisco's signature, and 
> > transitive trust is created. Of  course this doesn't say anything 
> > about why Michael should trust that  signature, although in this 
> > simplest case the rationale is obvious.  But for a 3rd service 
> > provider "in the middle", it is much less obvious.
> > ------
> >
> > I hastily typed "using its well known Nostrum CA key" instead of 
> > "using its well known Cisco CA key" in the last paragraph. 
> I knew what 
> > I meant, I just typed the wrong word. Sorry.
> >
> > This (as corrected) AFAIK cryptographically works. But it 
> doesn't work 
> > any better than P-Asserted-Identity and TLS. It still lacks a 
> > reversible chain-of-trust that is visible to the end user.
> >
> > I suppose the advantage is that, in the absence of an evil 
> > crypto-mangling SBC, you'd still get the benefit of 
> end-to-end (or at 
> > least authentication server to verifier) RFC 4474, which 
> MIGHT involve 
> > less transitive trust. But that doesn't seem too useful to 
> me. I think 
> > it would be much better to just patch RFC 4474 to work 
> through the SBC.
> 
> 
> The key difference is that one merely requires an explanation of how 
> things can be made to work;

Publishing a document that describes how RFC4474 is expected to work
with SBCs would be very valuable.  Such a document is long overdue.

-d


> the other requires development of Another 
> Way To Do The Same Thing, which (in protocols) is pretty much 
> always a 
> bad thing -- to be reasonably interoperable, implementations 
> are forced 
> to implement both (or all of) the defined mechanisms.
> 
> /a
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip