Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jul 2006 22:59:21 -0700

Keep in mind a B2BUA always breaks end to end security because the  
B2BUA is the end. If C is only a proxy and does not have a b2bua,  
everything seems to work find between B and D. I think I am missing  
what the problem is here. I perfectly willing to believe there is a  
problem - I just think that I am not clear yet on the scenario you  
are thinking about.

Cullen

On Jul 11, 2006, at 10:42 PM, Hadriel Kaplan wrote:

>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>>
>> Ok, I am done't think I am manging to explaim myself. Say A has a
>> contract with B and B has a crontract with C. Now a call arrives at
>> C, it seem that C wants a assertion to be made by B. Anything A says
>> to C is clsoe to useless because C has no clue who A even is. I guese
>> I feel like we need to sort out the requirements for what we want in
>> a transit case and then we might be able to figure out a solution.
>
> One of the problems with the idea of a b2bua re-signing it is how  
> to trust
> the b2bua.  I.e., if the domain the b2bua is in is not the same as the
> From's, then you have to somehow trust the different domain.  I  
> agree with
> you there's a common model of "I trust the domain connected to me  
> directly".
>
>
> So if you have an A-B-C chain as you describe, then sure A can  
> sign, then B
> can verify A and re-sign with B-cert, and C can verify B.  Now imagine
> A-B-C-D; A and B have a b2bua, but C doesn't.  A signs, then B  
> verifies and
> signs with B-cert, C does nothing and D gets a From of A with a  
> cert of B
> and does what?
> In other words, unless they all re-sign, it's limited to a small  
> chain.  But
> if they all re-sign, we're back to hop-by-hop trust.  Well... fewer  
> hops
> because it's domain-by-domain instead of proxy-by-proxy, so it is  
> better.
>
> But is domain by domain resigning acceptable?  It breaks the end-to- 
> end
> model of identity, so I would think not.  And making every domain  
> re-sign
> would have a serious flag-day problem. (not to mention quite an  
> impressive
> performance/scale issue I suspect)  At the same time, in your  
> example C does
> not have a contract with A, so the business model is not end-to-end  
> - so I'm
> not sure why the trust would be.
>
> -hadriel

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 1 Aug 2006 19:19:44 -0400

Take a request going through A-B-C domains.  A is the originating one, and
signs the identity with A's cert.  B uses b2bua's which would break the
signature.  I think I interpreted an earlier email from you to imply that a
b2bua in a transit provider B should re-sign the identity with its own
domain's (B's) certificate, if it would break the original signature.  Was
that correct?

If so, my problem was: how would the final, receiving domain C decide to
believe the signature, since it now uses B's cert to verify, which no longer
matched the domain portion of the From URI (namely A).  I think your answer
to that, paraphrasing, was: "C has a relationship with B, not A, so C should
trust/believe B's signature".  Right?

So then my problem is A-B-C-D.  C passes the request to D.  C did not own a
b2bua, and did not need to re-sign it.  So D gets a request that still has
B's signature, and A's From URI domain.  Why should D believe B's signature,
when it only has a relationship to C?

I think the answer is "it shouldn't".  So my problem is how will we get this
mechanism off the ground, when the most applicable/beneficial use cases for
it (multi-domain transit) won't work?  I am unconvinced it has any tangible
value other than multi-domain cases.  

-hadriel

p.s. IMO, Identity already isn't end-to-end, since it allows proxies to be
the authenticator and verifier.  It's domain-to-domain.  The signing node is
most likely already either after a b2bua, or a b2bua itself, which changed
stuff (or could have).  Likewise, the receiving domain verifier can be a
b2bua or there could be one after it, which can change stuff.  Obviously
that's ok because the whole idea is the domain which signs it has "verified"
the authenticity of the message through some means, and so it's as good as
the domain's control is.  But we shouldn't describe it as end-2-end, IMHO. 

> Sent: Tuesday, August 01, 2006 1:59 AM
> To: Hadriel Kaplan
> Cc: 'Jonathan Rosenberg'; 'IETF SIP List'
> Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence
> 
>

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Aug 2006 10:29:37 -0400

> when it only has a relationship to C?
Transitive trust. D has to assume C checked B's signature and was  
satisfied enough to re-initiate the SIP dialog it got from B.
Transitive trust sucks, but given that a B2BUA is basically an  
unverifiable Turing machine this is the best you can do in the  
absence of a PKI-based chain of trust.

> value other than multi-domain cases.
I'm unconvinced why we need to support transit in the first place,  
but that's another can of very large and aggressive c.elegans.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 7 Aug 2006 13:59:53 -0400

> From: David R Oran [mailto:[email-masked]]
> Sent: Wednesday, August 02, 2006 10:30 AM
> 

Yup, so then we're back to pre-Identity, because D makes that assumption
right now.  D has no idea if C does any verifying, or supports identity.

> but that's another can of very large and aggressive c.elegans.

(hey, at least c.elegans are well-studied and understood ;-)

If we don't support transit, why do we need an Identity-type mechanism?

-hadriel

---

From: David R Oran <[email-masked]>
Date: Tue, 8 Aug 2006 10:05:12 -0400

> If we don't support transit, why do we need an Identity-type  
For retargeting.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 12 Aug 2006 13:02:44 -0400

> Sent: Tuesday, August 08, 2006 10:05 AM
> To: Hadriel Kaplan
> Cc: 'Cullen Jennings'; 'IETF SIP List'

I don't follow.  Within a domain, I presume the retargeting is achieved by
the proxies under control of the domain.  If we don't care about transit,
then again the question is why would an operator of the domain not believe
the proxies retarget appropriately, when those will be the proxies that sign
the connected-identity UPDATE message anyway.  In other words the
re-targeting path presumably follows a chain which had used whatever
mechanism the operator decided was sufficient to authenticate the new target
to begin with.  Since the domain signs the upstream UPDATE message based on
its belief that whatever authentication mechanism was used for the called
party is sufficient, why bother? 

I could see its value if the re-targeting is performed either outside the
domain, or the new target is outside the domain.  But then we're back to the
transit issues.

-hadriel