Subject: Re: [Sip] Sanity check -- relationship between DTLS-SRTPand Identity

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 Mar 2008 08:48:26 -0600

Just following along with Dan's note from Friday...

>> Personally, I think that the E.164 problem is going to be
>> hard to solve,
>> and that it should not hold up DTLS-SRTP framework. (That is, that we
>> should release a DTLS-SRTP framework that only works with
>> "email-style"
>> SIP URIs.) That being said, E.164 numbers aren't going away any time
>> soon and so I think RAI should definitely perform work on how
>> to obtain
>> useful (as least PSTN-grade) identity guarantees for SIP
>> requests with
>> an E.164 number in the From: field.
>
> We can do PSTN-grade identity assertions of E.164's today already:
> just trust your pre-configured SIP trunk to not lie.  You set up SIP
> trunks to organizations with a contractual or gentleman's agreement
> to not lie.  You don't even need RFC4474 to do that.
>
> That is exactly as good as the PSTN's identity.

If I am understanding the discussion, one key point is that we're trying to 
accommodate implementations that ignore right-hand-side of URIs for E.164 
(and, worse, anything that might look like E.164) on the left-hand-side.

We think this is broken behavior, but we're trying to accommodate it? That 
usually turns out badly.

>> On the other hand, perhaps the SBC problem is one that we
>> should resolve
>> before advancing DTLS-SRTP framework. In particular, there
>> are at least
>> two proposals on the table (I.D-wing-identity-media and
>> I.D-fischer-sip-e2e-sec-media) that say "use something other than
>> RFC4474 for DTLS-SRTP framework". However, the concern that I have in
>> solving this problem is that, in the absence of guidelines for how a
>> 'well-behaving' SBC will handle particular headers or SDP
>> bodies, it's
>> hard to design a protocol that will interoperate well with SBCs.
>>
>> Note: Obviously, this concern is not DTLS-SRTP-Framework specific and
>> given that SBC-issues keep coming up in a variety of working groups,
>> perhaps RAI needs to reach consensus that either:
>> A) We will not address SBC-related concerns when engineering
>> protocols
>> (e.g. we advance DTLS-SRTP without solving the SBC problem).
>> B) We will seek to design protocols that interoperate with "most"
>> existing SBCs at the time the protocol specification is written.
>> C) We will seek to design protocols that interoperate with
>> "well-behaving" SBCs (i.e. SBCs that adhere to the following set of
>> guidelines).
>> D) ?????
>
> This is all feeling very much like the history of the IETF's
> involvement with NATs and the IETF's involvement with firewalls.

Well said. If I may expand this statement...

- NATs translate addresses (and ports). That's brain-dead simple if you 
don't mind breaking protocols that embed literal addresses as part of the 
payload. So BEHAVE got chartered.

- If you want these protocols to work, you need an application level 
gateway, too, but that's doable for any protocol that's well-documented 
enough to implement an endpoint. So if you're OK with B2B for an 
application, you don't need to do anything to accommodate ALGs.

- firewalls drop packets based on policy. How those decisions are made, is 
less well-understood. BEHAVE was specifically NOT chartered for firewall 
work (and it's not like we forgot about this during charter discussions).

- we've been looking at SBCs for a while now, and we've ended up with 
multiple dozens of SBC functions documented in 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-04.txt. If 
we didn't charter work to define "well-behaved firewalls", I'm having a hard 
time visualizing us chartering work to define "well-behaved SBCs".

Other people may expect a happier outcome, but I'm not sure why.

Spencer 

_______________________________________________
Sip mailing list  https://www.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: "Dan Wing" <[email-masked]>
Date: Tue, 4 Mar 2008 11:32:59 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Spencer Dawkins
> Sent: Tuesday, March 04, 2008 6:48 AM
> To: [email-masked]
> Subject: Re: [Sip] Sanity check -- relationship between 
> DTLS-SRTPand Identity
> 
> If I am understanding the discussion, one key point is that 
> we're trying to accommodate implementations that ignore 
> right-hand-side of URIs for E.164 (and, worse, anything that might 
> look like E.164) on the left-hand-side.
> 
> We think this is broken behavior, but we're trying to 
> accommodate it? That usually turns out badly.

No, that's not what I was saying.

If your SIP trunk is with a service provider ("example.net", let's
say), and you have a mutually-authenticated TLS connection with their
SIP proxy and they give you a From that says [email-masked],
you now have an identity assertion from your service provider that is
exactly as good as the PSTN's identity assertion from your PSTN 
provider.

> Other people may expect a happier outcome, but I'm not sure why.

NATs and firewalls both attempt to perform their operations silently
and without involvement or interaction or knowledge of hosts.  There
are places where this breaks (hence: IETF's development of ICE;
the existence of UPnP and NAT-PMP; the existence of "hosted NAT
traversal", one of the many features of an SBC).

SBCs are always present on the path and are never invisible:  SIP and 
media packets are sent to their IP address.

-d

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Mar 2008 11:55:27 -0800

> exactly as good as the PSTN's identity assertion from your PSTN 
This sticks in my craw. The PSTN universe is a lot more closed than the
internet is. And the PSTN universe is not exactly air tight either. Unless
of course the subtext of "as good" is "crappy".

I haven't been following this very well, but is there movement afoot to
answer the question of "what are we going to do about e.164 number
security?" something other than "nothing"?

       Mike

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 Mar 2008 13:55:06 -0600

Hi, Dan,

Sorry, I hit you with collateral damage. I agree with your point (if the 
best we can do is PSTN-equivalent identity, we should do that).

My point about brokenness goes all the way back to the beginning in this 
(and related) threads, that we're really vague on either an E.164 address is 
actually reached through the PSTN, but a lot of people seem to have 
assumptions in this area (including "if it looks like an E.164 number, it 
probably is, so you can use it as CLID for the user, with no associated 
domain information").

Thanks,

Spencer

----- Original Message ----- 
From: "Dan Wing" <[email-masked]>
To: "'Spencer Dawkins'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 04, 2008 1:32 PM
Subject: RE: [Sip] Sanity check -- relationship between DTLS-SRTPand 
Identity

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Mar 2008 12:16:30 -0800

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, March 04, 2008 11:55 AM
> To: Dan Wing
> Cc: 'Spencer Dawkins'; [email-masked]
> Subject: Re: [dkim unverified] Re: [Sip] Sanity check -- 
> relationship between DTLS-SRTPand Identity
> 
> Dan Wing wrote:
> >
> internet is. And the PSTN universe is not exactly air tight 
> either. Unless of course the subtext of "as good" is "crappy".

That is my subtext, yes.

> security?" something other than "nothing"?

Yes, there are approximately 7 new drafts on this issue, and another 2 expired
drafts that discuss this a bit, too:

  draft-darilion-sip-e164-enum-00.txt
  draft-elwell-sip-e164-problem-statement-00.txt
  draft-fischer-sip-e2e-sec-media-00.txt
  draft-kaplan-sip-uris-change-00.txt
  draft-rosenberg-sip-rfc4474-concerns-00.txt
  draft-schwartz-sip-e164-ownership-00.txt
  draft-wing-sip-e164-rrc-01.txt
  draft-rosenberg-rai-phone-names-numbers-00 (expired)
  draft-mayrhofer-enum-domainkeys-00 (expired)

And there is a 30 minute timeslot in SIP to discuss the issue, "The Phone
Number/Identity Dichotomoy",
http://www.ietf.org/proceedings/08mar/agenda/sip.html

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Mar 2008 12:33:24 -0800

> probably is, so you can use it as CLID for the user, with no 
> associated domain information").

But including the domain doesn't help much with E.164's, anyway.  
Which is valid:

  [email-masked];user=phone
  [email-masked];user=phone
  [email-masked];user=phone

or, for that matter, what would Grandma say about:

  [email-masked];phone=user

(phone=user rather than user=phone, which means this is _not_ an E.164 but it
sure would be convincing to all but perhaps 50 or 60 people involved with SIP
standards).

This is all jibberish to users.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2008 16:17:55 -0500

Dan,

What I would *hope* is that a phone for the consumer market would not 
display a phone number as the callerid unless it has good reason to 
believe the caller can indeed be identified by a phone number. For all 
the wierd cases you cite, the phone could simply display that callerid 
is not available, or it could display display the phone number portion 
with some indication that it is suspect, such as ???.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Mar 2008 13:24:11 -0800

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, March 04, 2008 1:18 PM
> To: Dan Wing

I share a similar hope.

But the IETF has a poor history of influencing user interface behavior.

-d

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Mar 2008 16:40:17 -0500

Below, for emphasis:

> Just following along with Dan's note from Friday...
...
> We think this is broken behavior, but we're trying to accommodate it? That 

Trying to support end-devices that do the wrong thing (ignore an 
important part of a URI) is both a bad idea and fraught with disaster. 
SIP doesn't work if you ignore the right hand side of a SIP URI.

Now, if we want to have two identity assertion mechanisms, one relative 
to a full URI, and one relative to a phone number, then senders (or 
their proxies) can choose whether a phone number assertion is relevant. 
  And sensible users can ignore phone number assertiosn, since PSTN 
authentication is so weak.

Yours,
Joel

PS: Yes, I keep getting answers of the form "devices do that".  This is 
not like the NAT case, where we have to work around devices in the 
middle.  There are cases like that (NAT) in SIP.  And we try to deal 
with those.  But this is purely about what the end device chooses to 
present to its local user.
_______________________________________________
Sip mailing list  https://www.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, 4 Mar 2008 17:44:55 -0600

>> either. Unless of course the subtext of "as good" is "crappy".

Personally, I'm thinking I'd like to see an Identity entry that warns  
me that the assertion of identity is only PSTN grade.

I can envision a user-interface component like a signal-strength meter  
that pops up when my phone displays caller ID. A PSTN-grade assertion  
might be 1 bar, whereas an assertion from a trusted server that's made  
a mutual-cert verification might be 5 bars.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Mar 2008 08:14:35 -0500

> a mutual-cert verification might be 5 bars.

This kind of result (however it can be achieved) is what I too have been 
thinking is needed.

There are a bunch of issues with it:
- what are devices capable of rendering?
- what are most people capable of comprehending?
- how to reliably assign these "confidence levels"?

But in the end it seems that we need something like this.

	Paul