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

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Jul 2006 10:17:47 -0700

On Jun 30, 2006, at 2:59 PM, Hadriel Kaplan wrote:

> More inline...
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>>
>> case 2) ingress B2B on terminating domain - this is fairly easy too.
>> This B2BUA resigns the incoming request. To do this it uses a cert
>> that has a wildcard for all domain - the UAS need to be configured to
>> have this cert in it root trust list. What the UAS is doing here is
>> delegating that it trust any name that the
>>   B2BUA trusts. This is the sort of trust delegation one wants to be
>> able to make.
>
> I don't know how practical that is to do on the UASs.  It seems to  
> me like
> most UASs simply trust whatever their proxy tells them, and that  
> should be
> ok if we can guarantee what their proxy tells them is true. (a big IF)

For UA that don't do Identity, I think what I proposed works with no  
changes to them. For UAs that do do Identity, they need to have a  
list or root certs they trust. It seems like when you are determining  
what the UA trusts you are setting up this list. Again, in this case  
I don't see what does not work about my proposal.

>
> If a b2bua before that proxy but in the same trust domain verified the
> identity, and can somehow tell the proxy it verified the identity,  
> and even
> tell the UAS it did as well, why do more?  That's what the PAI  
> does.  It may
> not be what it was supposed to do, but it's what it seems to now.
>

So in the case of an anonymous call where the real caller identity is  
in the PAI for malicious call trace reasons, what are you proposing  
to do. Does the proxy strip the PAI before sending it to the UAS?   
How would the proxy know? Do you deliver the PAI to the UA - this  
would violate privacy laws in Europe. I don't see how this would work.

>
>> case 3) a B2BUA in a transit provider between the originating and
>> terminating domain. There are two very different cases here - one is
>> where the transit provider is an intermediate in providing PSTN
>> termination services and using E.164 addresses. For example some
>> company, contracts its PSTN termination from say MCI who for numbers
>> in Australia perhaps uses Telstra. The company wants to see the phone
>> number asserted by MCI, not Telstra  - it is MCI they trust and can
>> make an authorization decision based on. They have no idea who
>> Telstra is so whatever telstra wants to claim is useless for the
>> company. The point is, whatever things Telstra might assert to MCI,
>> the company wants MCI to make an assertion that the company can use
>> for it authorization decision. In these cases the transit B2BUA needs
>> to resign things.
>
> And that's the rub.  The real use/value of Identity, IMHO, is for the
> transit case - period.  Within a domain or between just 2, and  
> there are
> other ways to trust, except for the really paranoid.  But the  
> longer the
> trust chain of transits is, the greater the probability the chain  
> is broken.
>
>
> When I looked at the original identity draft I thought ok - the  
> b2bua/proxy
> egress can be the signer and the ingress b2bua/proxy can be the  
> verifier.
> Of course then I immediately thought if the 2 domains are connected  
> by just
> those 2 elements, why bother doing the signing/verifying for a  
> single hop
> that is going to be TLS/IPSEC anyway??  Use the PAI you already have.
>
> But for transit cases: it requires the transit domain(s) to either  
> (1) not
> muck with contact, call-id, and bodies, or (2) support identity,  
> and to
> somehow re-sign with something that the verifier in the next domain 
> (s) will
> accept, which goes back to hop-by-hop trust kinda.  But changing  
> (1) or (2)
> is out of the local (and final) domain's control to change - they  
> need the
> transit domain(s) to change, and that's a much bigger hurdle.
>
>

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.

>> As a last note, I do think there are workable solutions for the B2BUA
>> case. Having UA accept message with a bad Identity header but that
>> have a PAI seriously breaks Identify. One of the key things that
>> Identity provides is a close to end to end integrity for the bodies.
>
> Yes, it signed the body, and contact, but I consider that its fatal  
> flaw.
> It should have stuck with the From (and Date and whatever else it  
> thinks is
> needed for a reasonable nonce).  The body I know is a hard one to  
> not sign
> (it's so tempting!).  But sign the contact?  What does that have to  
> do with
> identity?
>
>
>> This breaks this and we have no other good way to provide this. What
>> I am suggesting above provides a way to keep this integrity property
>> so that no device can tamper with the integrity other than devices
>> that the UAS or UAC explicitly trusts to tamper with the integrity. I
>> think this is a fairly important property and achievable.
>
> What about just splitting it into 2 Identity headers/signatures?   
> One for
> the From and nonce-ish stuff, the other for the body and same nonce- 
> ish
> stuff.  If a middle-man wants to modify the body, he verifies and  
> re-signs
> that second signature, or if the middle-man is unaware of identity  
> then the
> next one can decide what to do with a bad signature for a body but  
> good
> signature for From.
>

The From itself has no intrinsic value - what you are trying to sign  
is that some body came from the person in the From header. If the  
 From header and it's signature can be cut and paste from one message  
to another, Identity would fail to solve any security problems.

> So when the final UAS gets it (or its domain verifier) she says  
> "hmmm... the
>> From was definitely signed by the URI domain company.com, but this  
>> body is
> signed by provider.com who I trust... ok, I can trust that", vs. "I  
> see
> company.com signed the From but the body was broken... this is  
> suspicious".
> This way a b2bua can change the body but doesn't have to have a  
> certificate
> matching the From-uri domain to do so, and the UAS can decide if  
> it's kosher
> for the b2bua-domain to change the body, while also verifying the  
> From is of
> the right domain.  I haven't thought it through, but it sounds ok.

You are proposing almost exactly the same thing I am. The way you are  
thinking of handling the body, just use that handling for both.

> -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: Wed, 5 Jul 2006 14:10:44 -0400

> Sent: Sunday, July 02, 2006 1:18 PM
>

I don't see how that's germane to the Identity issue?  Is there Identity
support for anonymous requests? (I thought not) The UAS clearly cannot
distinguish a trusted identity for such a request, since there is no
anonymous identity.  

If you mean how does the proxy know to do so for only anonymous requests
while not the others?  You tell me - you wrote the spec. :)  Operators seem
to do every permutation possible.  Some just have a rule where all PAI's for
all requests get stripped at the edge proxy right before the UAS, others do
it only if priv-value=id, some for any priv-value, some don't strip it at
all.  Is your point if the trust domain is not the same, and if the edge
proxy strips them all, then the UAS won't know it's a verified identity?  

> a transit case and then we might be able to figure out a solution.

Yup, we need to sort out the reqs.  In my mind your A-B-C scenario above
doesn't need or benefit from Identity, much (or it just moves the same
problem one step away).  

> to another, Identity would fail to solve any security problems.

It has value - at least for the publicly stated benefits of Identity being
useful for SPIT prevention.  

It can't be cut/paste anymore easily than the body also being signed.  Its
hash still includes the To-uri, call-id, date, and CSeq bits.  If you can
cut/paste that info for re-use, you can do it even if the body is also
signed. (although at least with a signed body it would make it hard to fully
establish a pasted call with media, or whatever)

> thinking of handling the body, just use that handling for both.

Except your's requires the middlemen to support Identity-coexistence or else
everything breaks - if they don't then the UAS won't know if anything in the
received request is correct, or if only the body got modified - even if only
the body got modified. (of course for some the body is the whole enchilada)

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 12 Jul 2006 01:42:52 -0400

> 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