Subject: [Sip] SBCs and draft-ietf-sip-identity-06

From: Hans Persson <[email-masked]>
Date: Tue, 07 Mar 2006 08:55:55 +0100

I just went back and had a look at draft-ietf-sip-identity-06. As far as
I can see, an Identity header really says two things at the same time.
1) The sender is who he claims to be. 2) The message looks like it did
when it was sent.

Both these functions are nice in an ideal world, but many people will
have SBCs, B2BUAs, or SIP-aware firewalls in their call paths. These
will modify SDP and probably the Contact header.

As far as I can see there is no discussion in the draft about this at
all, apart from the probably naĩve assumption that it shouldn't happen.

It would be nice with guidelines about what these types of entities
should do. Should they modify what they need to modify and leave the
rest (including the now non-verifiable Identity header, to make it clear
that something happened along the way) or should they remove the
Identity header as well?

In this type of scenario, the integrity verification of the SIP message
will fail. Personally, I'd rather still have a (possibly somewhat
weaker) verification that the sender is who he claims to be than
nothing.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 7 Mar 2006 11:54:18 -0600

> all, apart from the probably naĩve assumption that it shouldn't  

That's because IT SHOULDN'T HAPPEN.

A B2BUA is NOT A proxy, and is NOT, in general, identity-transparent

If you put a B2BUA in the loop, all that SIP Identity can really give  
you is an assertion about a request's state when it left the B2BUA,  
because for all practical purposes that is the originating UA for the  
request. It's a UA. It might have another protocol or a user  
interface on the other side of it instead of SIP, and the Identity  
mechanism can't tell the difference.

Consequently, it is up the B2BUA implementor to work with the  
identity-asserting operator in question and establish themselves as  
valid identity sources within the framework of that operator, and not  
as the man-in-the-middle attacks that they would otherwise appear to be.

--
dean

---

From: Hans Persson <[email-masked]>
Date: Thu, 09 Mar 2006 08:35:47 +0100

tis 2006-03-07 klockan 11:54 -0600 skrev Dean Willis:

> > Both these functions are nice in an ideal world, but many people 
> > will have SBCs, B2BUAs, or SIP-aware firewalls in their call paths.
> > These will modify SDP and probably the Contact header.
> >
> > As far as I can see there is no discussion in the draft about this 
> > at all, apart from the probably naĩve assumption that it shouldn't  
> > happen.
> 

No, it shouldn't happen. I'm just saying that it will, in reality.

I think it would be a good idea if new specs state explicitly if they
are going to break in common deployment scenario types instead of just
pretending that no problem exists.

Hans

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Mar 2006 13:21:29 -0600

> pretending that no problem exists.

The problem is that ALL of our specs break when non-conformant UAs  
are used. And B2BUAs, just like any other UA, have to be responsible  
to the protocol. When they aren't (for example, they haven't  
implemented an identity service with a transient relationship to the  
original UA), then they're going to break stuff.

I'm beginning to believe that service-controlling B2BUas were a  
REALLY bad idea, proxies were a MOSTLY bad idea, and we should have  
used a redirect-based model with negotiated traversal through  
signaling-neutral relay elements. Like maybe P2P-SIP with ICE . . .

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 22:59:40 -0800

> pretending that no problem exists.

I doubt that Identity breaks B2BUA in the cases that I have heard of. I
roughly break the cases into two classes - ones where the B2BUA wants to
assert a new identity because it is hiding the old one; And cases where it
is in the same domain as the original party. In either case the B2BUA can
have the credentials to be able to re-sign the identity in the message. I'm
won't be surprised if someone comes up with a case where it is a problem but
so far, everyone I have heard of has not been a problem.

---

From: Hans Persson <[email-masked]>
Date: Tue, 14 Mar 2006 08:48:26 +0100

> so far, everyone I have heard of has not been a problem.

I'd rather expect problem in the opposite direction. If the B2BUA wants
to terminate incoming calls, then the receiving client won't be able to
verify the identity of the caller since the B2BUA will have modified the
body (at least) of the incoming request since the creation of the
Identity header.

Hans

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Mar 2006 15:22:05 -0600

> body (at least) of the incoming request since the creation of the

yes, that's exactly the case I was worrying over. At the best, the  
SBC can tell the terminating UA what the identity it received was and  
claim to have checked that identity on behalf of the terminating UA.  
This is in effect a new assertion of identity, based on a transitive  
trust agreement.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Mar 2006 19:21:12 -0800

> body (at least) of the incoming request since the creation of the

So call in domain A goes to B2BUA in domain B. B2BUA checks the identity and
if it is not good, it discards the call. If it likes it the identity, it
maps to a name in domain B, signs with credential in domain B, and sends to
client in domain B that is trusts credentials in domain B. You are right
that the B2BUA need to check the identity for you but that is the nature of
anything that changes Identity items. It's not much differnt than the
outgoing direction.

---

From: Hans Persson <[email-masked]>
Date: Wed, 15 Mar 2006 08:50:18 +0100

> anything that changes Identity items. It's not much differnt than the

This sounds weird. A call from domain A (say [email-masked]) comes in
to B2BUA. B2BUA checks the identity and finds that you are who you claim
to be. So far, so good.

What do you mean by "maps to a name in domain B"? Should the B2BUA
change the call to appear to come from [email-masked], sign that, and
forward the call? That sounds like a really bad idea.

In many cases, there will be no association between the domain of the
caller and the domain of the called, so it's not possible to resign the
request when it gets forwarded (the B2BUA won't be able to sign for the
calling domain).

> This is in effect a new assertion of identity, based on a transitive  

Yes. What we need is a way to forward the fact that the identity has
been asserted at a hop before the end client, but within the same
domain. P-Asserted-From?

Hans

---

From: Aki Niemi <[email-masked]>
Date: Wed, 15 Mar 2006 10:06:41 +0200

> forward the call? That sounds like a really bad idea.

Well, you can't have sip-identity and break it at the same time. Choose
your poison.

> been asserted at a hop before the end client, but within the same

I think RFC3325 is enough.

Cheers,
Aki

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 06:02:44 -0800

> anything that changes Identity items. It's not much differnt than the

What is this mapping function, and what is a UAS supposed to do
with the mapped identity? And this seems to assume that the
B2BUA is always in the same adminstrative domain as the UAS,
which is not always the case, and even if it is it may not be
trustworthy.

This smells suspiciously like the mailing list problem in DKIM,
and details matter. A lot.

		Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:36:45 -0600

> which is not always the case, and even if it is it may not be

I believe it's an assertion that the call came from [email-masked]  
signed not by cisco.com but by ingate.com. Do you trust ingate to  
make this assertion? That's up the relationship you have with ingate.

I trust it a lot MORE if ingate is cryptoparticipant and I've  
validated the message source than if it just comes in out of the  
blue, but I still don't trust it a whole lot. That's a large part of  
why B2BUA solutions have EXTREMELY LIMITED APPLICABILITY and we don't  
design ANYTHING around them but conferencing-like services.

--
Dean

---

From: Hans Persson <[email-masked]>
Date: Thu, 16 Mar 2006 09:01:35 +0100

ons 2006-03-15 klockan 16:36 -0600 skrev Dean Willis:

> signed not by cisco.com but by ingate.com. 

How do I make such an assertion within the framework of Identity? As far
as I can tell, a UA compliant with identity-06 will reject such a
request since the domain of the From header does not match the domain of
the certificate of the signer. Or am I misunderstanding what you mean?

> Do you trust ingate to  

If ingate.com is my own domain (handling my own outgoing Identity
headers, for instance), then I would trust it to make this kind of
assertion. If, however, it is a third-party domain that happens to be in
the signaling path, then I probably won't put much trust in such an
assumption.

> design ANYTHING around them but conferencing-like services.

What I feel will limit the deployability of Identity is that it states
in the requirements in Appendix C "the mechanism must be capable of
protecting the integrity of SIP message bodies", while what is defined
in identity-06 is something like "the mechanism must protect the
integrity of SIP message bodies". Not just an option to do it, but
actually no option but to do it.

Hans

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 15:02:13 -0600

> the certificate of the signer. Or am I misunderstanding what you mean?

I didn't say it actually worked. That's part of the problem with B2BUAs.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Mar 2006 13:15:40 -0800

> I didn't say it actually worked. That's part of the problem with B2BUAs.

You wouldn't have the UA check the identity. It delegated that job to the
B2BUA when it asked the B2BUA to act on it's behalf.

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Mar 2006 15:51:55 -0600

> B2BUA when it asked the B2BUA to act on it's behalf.

Of course, then you need to check to make sure that the thing  
claiming to be your B2BUA both:

1) claims to have validated the identity as it saw it

2) really is your B2BUA and is not YAMITMA (yet another man in the  
middle attacker).

I think this can be done with the basic mechanics of identity, but we  
need some discussion of trust anchors that's outside of what I think  
is there.

#1 might could be satisfied by a "contract" between B2BUA and UA --  
the B2BUA has contracted to check any expressed identities and remove  
or flag ones it thinks are invalid. We need a way to assert, in the  
signaling, that this contract is being exercised. I think.

#2 might could be satisfied by a TLS or equivalent SA to the B2BUA.  
Of course, this assumes an increasingly tenuous transitive SA as  
additional proxies appear between B2BUA and UA. And I don't like it.

What if we extended the logic to be "Domain of the From: header must  
match the domain of the certificate of the signer" OR "the  
certificate of the signer MUST match the transitive trust domain of  
the recipient"?

So if an identity saying "[email-masked]" appears  
in my inbox, signed by "cisco.com", and my UA is configured to  
believe transitive identifications made by "cisco.com", then my UA  
thinks it has received a call from President George Washington.

I dunno, maybe I'm confused.

--
Dean

---

From: Hans Persson <[email-masked]>
Date: Mon, 20 Mar 2006 09:05:33 +0100

> certificate of the signer MUST match the transitive trust domain of  

That would take care of my concerns.

Hans