Subject: [Sip] The thing we're missing in the RFC 4474 and DTLS-SRTP discussion

From: Dean Willis <[email-masked]>
Date: Thu, 13 Mar 2008 11:59:36 -0400

We seem to agree that RFC 4474 assertions involving things that look  
like phone numbers can not really be trusted, and probably therefore  
should not be sent.

However, DTLS-SRTP doesn't function without RFC 4474.

So, if you need to use DTLS-SRTP to protect a phone call that involves  
a numeric identity (and that includes E.164, private phone numbers,  
and numeric user parts of any kind), you end up having to send an RFC  
4474 Identity header that is going to mislead people.

So as things are currently written, one can never use DTLS-SRTP with a  
numeric userpart in the identity.

That's the part that we absolutely have to sort out.

We could fix this by having gateways encode their identity using a  
reserved userpart. This has to have the  property of saying "Do not  
display this as caller-ID". Using "sip:domain" or "sip:ipaddress" does  
not work, as those might actually be valid URIs that be be displayed  
as IDs.

It might work to have the gateway use a reserved value, like "sip:pstngateway@domain 
".

Or it might work to extend RFC 4474 to have a "strength of assertion"  
indicator.

It's certainly easier to add guidance in DTLS-SRTP about what gateways  
should do and about how UASes should interpret various header fields  
than it is to change RFC 4474.

However, we need to note that a standards-track document cannot say  
"Use P-Asserted-Identity". That would be an unacceptable downref. It  
could however say "If the identity encoded in the RFC 4474 Identity  
header has the reserved userpart "pstngateway", then the UAS MUST NOT  
display this to the user as the calling party identifier. Rather, the  
UAS should use other indicators of calling party identity that may be  
available to it.

--
Dean
_______________________________________________
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: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 13:58:35 -0400

> not work, as those might actually be valid URIs that be be displayed  

That's the problem I have -- if the calling party reported by the PSTN 
has been completely pulled out of the "From" header field, then you'll 
have very bad interaction with currently deployed phones. I don't think 
that's a reasonable trade-off. That's why I think this...

> It might work to have the gateway use a reserved value, like "sip:pstngateway@domain".
>   

...is a non-starter.

> Or it might work to extend RFC 4474 to have a "strength of assertion"  

You mean something like:
  From: <sip:[email-masked];user=phone;trusted=no> ?

Or something more like:
  Identity: "LotsOfBase64EncodedGunk==";trusted=no

(I acknowledge that this can be more nuanced than yes/no, but let's 
decide where the bike shed goes before we begin the argument about its 
color).

> than it is to change RFC 4474.

That would argue for some indication on the *From* header field that 
indicates a level of trust. I'm not sure it's really the proper place to 
place that information, from a semantic perspective -- but it does seem 
to be a potential way to get through this maze of thorns without losing 
too much blood.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 19:24:37 +0000

Dean,

See below.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: 13 March 2008 16:00
> To: IETF SIP List
> Subject: [Sip] The thing we're missing in the RFC 4474 and 
> DTLS-SRTP discussion
> 
> 
[JRE] If From contains something like sip:[email-masked]
(where mygateway is not a reserved name), that could be displayed to the
user (along with a TEL URI PAI) and would indicate where the request
comes from (within the SIP network). If DTLS-SRTP is used, it also
indicates where media is secured from. The problem is, it lacks an
explicit indicator that this is not the end domain, so it might lead a
UA to make a wrong assessment of security and indicate it to the user.
So there does indeed seem to be a need for some explicit indicator. I
think I prefer a "strength of assertion" indicator rather than a
reserved user value in the SIP URI. Maybe that could be an update of RFC
3261 to add a new parameter to SIP URI, rather than a change to RFC
4474.

> than it is to change RFC 4474.
[JRE] Yes, but that guidance might be relevant in circumstances other
than DTLS-SRTP, so we seem to have three possibilities:
1) Update RFC 4474 to include this guidance
2) Write an informative RFC to give this guidance
3) Include this guidance in DTLS-SRTP-framework.
In cases 1) and 2) there could also be some discussion in
DTLS-SRTP-framework, specific to that particular situation.

> UAS should use other indicators of calling party identity 
[JRE] We could, of course, issue an RFC 3325bis making it standards
track. I know this has been mentioned before and some people have said
it would never get through IESG security scrutiny. However, the header
field is in such common use, outside the initial walled garden for which
it was specified, that it might make sense.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 13 Mar 2008 19:27:45 +0000

I don't understand the focus on PSTN gateways.  Is it believed that only
PSTN gateways ever create URIs with numeric user parts?  Or that PSTN
gateways are particularly untrustworthy?  Neither seems reasonable to
me.

tim

> Sent: Thursday, March 13, 2008 12:00 PM
> To: IETF SIP List

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 22:17:11 +0000

Quite right. PSTN gateways present their own problems, but just the use
of number-based SIP URIs for communications within the SIP environment
also has some issues, i.e., the fact that the number has meaning without
the domain part, and thus the temptation to modify the domain part. As
part of the straw man proposal presented today in the meeting, it was
suggested that a domain can sign a number-based SIP URI if it believes
that calls to that number can reach the user via that domain. So that is
all you can assume about the domain part of such a URI.

Of course, this leads to the question of when is a SIP URI number-based
and when is it not. In theory, the user=phone parameter could be the
criterion, so that if user=phone is absent a relying party could assume
that the domain indicated in the URI is the "home" domain for that user.
In practice, it appears there are implementations that modify the domain
part of any URI that looks like it contains a phone number in the user
part. That would appear to be broken, in that return routability would
be lost. However, in practice, often a numeric user part IS a phone
number, and assuming global uniqueness, return routability perhaps is
achievable.

So there seems to be rather a grey line between trusting or not trusting
the domain part of a SIP URI as being the "home" domain of the user. We
have to try to figure out how to address this and give reasonable advice
to relying parties.

John

> Behalf Of Dwight, Timothy M (Tim)
> Sent: 13 March 2008 19:28
> To: IETF SIP List
> Subject: Re: [Sip] The thing we're missing in the RFC 4474 
> and DTLS-SRTPdiscussion
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Mar 2008 18:26:04 -0400

On Mar 13, 2008, at 1:58 PM, Adam Roach wrote:

>> reserved userpart. This has to have the  property of saying "Do  
>> not  display this as caller-ID". Using "sip:domain" or  
>> "sip:ipaddress" does  not work, as those might actually be valid  
>> URIs that be be displayed  as IDs.
>>
>
> That's the problem I have -- if the calling party reported by the  
> PSTN has been completely pulled out of the "From" header field, then  
> you'll have very bad interaction with currently deployed phones. I  
> don't think that's a reasonable trade-off. That's why I think this...

That;s why John proposed P-AI-ID as the Caller-ID source.
>> It might work to have the gateway use a reserved value, like "sip:pstngateway@domain 

How about:
	From: +12142821376 <sip:[email-masked]>

>
>
>
>> Or it might work to extend RFC 4474 to have a "strength of  
>> assertion"  indicator.
>>
>
> You mean something like:
> decide where the bike shed goes before we begin the argument about  
> its color).

yeah, those might work as well. Although this approach has the  
advantage of not modifying RFC 4474, just giving guidance about how  
gateways could use it. This could be done in DTLS-framework.

>
>
>> It's certainly easier to add guidance in DTLS-SRTP about what  
>> gateways  should do and about how UASes should interpret various  
>> header fields  than it is to change RFC 4474.
>>
>
> indicates a level of trust. I'm not sure it's really the proper  
> place to place that information, from a semantic perspective -- but  
> it does seem to be a potential way to get through this maze of  
> thorns without losing too much blood.

I like it.

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Mar 2008 18:30:24 -0400

> gateways are particularly untrustworthy?  Neither seems reasonable to

Here's the good news. Sine there are very few (aka none)  
implementations of RFC 4474 in the field now, we might be able to  
argue that by providing a way to properly handle PSTN numbers at  
gateways BEFORE we get deployment lets us work around the problem.

As for numeric user IDs, there's no technical reason that  "sip:[email-masked] 
;" can't REGISTER and authenticate as the authorized user at  
"example.com". So, pure IP endpoints can authenticate using Identity.  
It;s the behavior of the PSTN gateways that induces the problem.

--
dean

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 18:38:16 -0400

I'll reiterate my key point here at the top: we cannot retroactively 
change the behavior of deployed user agents. All we can do is make sure 
what we're proposing doesn't make do stupid and/or useless things.

More inline.

On 3/13/08 6:26 PM, Dean Willis wrote:
>>> display this as caller-ID". Using "sip:domain" or "sip:ipaddress" 
>>> does  not work, as those might actually be valid URIs that be be 
>>> displayed  as IDs.
>>>
>>

The phone on my desk would treat that like any other unknown header, and 
ignore it.

>     From: +12142821376 <sip:[email-masked]>

If I missed that call, the phone on my desk would helpfully offer to 
call "sip:[email-masked]" when I got back. I don't think I'll be 
happy with the results.

>> indicates a level of trust. I'm not sure it's really the proper place 
>> to place that information, from a semantic perspective -- but it does 
>> seem to be a potential way to get through this maze of thorns without 
>> losing too much blood.
>
> I like it.

Okay, we might be getting somewhere then. Anyone else?

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 18:46:59 -0400

> gateways are particularly untrustworthy?  Neither seems reasonable to

Really? Email me your cell phone number, and the number you want me to 
appear to call it from.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 23:07:02 +0000

> Behalf Of Adam Roach
> Sent: 13 March 2008 22:38
> To: Dean Willis
> Cc: IETF SIP List
[JRE] Many phones do recognise P-Asserted-Identity and use that in
preference to an unsigned From URI. It is difficult to find a solution
that will not upset any existing deployed device, but we can at least
try to make it work acceptably with a sizeable population.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2008 19:08:30 -0400

> 	From: +12142821376 <sip:[email-masked]>

Are we now assuming that 4474 vouches for the correctness of the display 
name?

In any case, callerid includes name as well as number, so we probably 
need to reserve the display name for carrying the calling name, not the 
calling number.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 09:25:22 -0400

On Mar 13, 2008, at 7:08 PM, Paul Kyzivat wrote:

> Are we now assuming that 4474 vouches for the correctness of the  
> display name?

  No, we're not. We're assuming that since we can't verify the  
contents of the display name, that having such information signed by  
RFC 4474 would be a Bad Thing.

In other words, we are trying to limit the content of the RFC-4474  
signed fields to include only things that the authentication service  
can verify. It should not sign and assert as true that which it cannot  
verify. So when we have a call from the PSTN, the Identity header MUST  
NOT assert anything about the PSTN-provided information.

But here's the problem with Adam's idea.:

> Various exceptions to such policies might arise for cases like  
> anonymity; if the AoR asserted in the From field uses a form like 'sip:[email-masked]' 
> , then the 'example.com' proxy should authenticate that the user is  
> a valid user in the domain and insert the signature over the From  
> header field as usual. Note that this check is performed on the addr- 
> spec in the From header field (e.g., the URI of the sender, like 'sip:[email-masked]') 
> ; it does not convert the display- name portion of the From header  
> field (e.g., 'Alice Atlanta'). Authentication services MAY check and  
> validate the display-name as well, and compare it to a list of  
> acceptable display-names that may be used by the sender; if the  
> display-name does not meet policy constraints, the authentication  
> service MUST return a 403 response code.

If I'm reading it correctly, that gives us some flexibility with the  
display-name.

> In any case, callerid includes name as well as number, so we  
> probably need to reserve the display name for carrying the calling  
> name, not the calling number.

Interesting question. I think the phone number is part of the display  
name:

From: Dean Willis +12142821376 <sip:[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 10:01:22 -0400

> RFC 4474 would be a Bad Thing.

Let me restate that: signing the display name (or anything else) that  
we can't verify is a Bad Thing unless we explicitly state that the  
thing we're signing is uncertain, in such a way that receivers can  
understand that this thing is uncertain.

This gives us two choices -- not signing things that look like  
numbers, or including a warning flag in the signed material that  
indicates that the indicated aspect of the thing we're signing was not  
authenticated.

--
Dea

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Mar 2008 10:17:32 -0400

> try to make it work acceptably with a sizeable population.

So we've gone from warning "don't implement internet-drafts" to "don't 
implement RFCs"? It seems folly to pull the rug out from under existing 
user agents when we've already identified at least one approach that 
seems to satisfy the keying requirement without breaking existing 
deployed equipment or making assertions that can't be verified by the 
asserter.

Do you have a concrete objection to my proposal to tag the signed URI as 
having a level of trust that is less than absolute?

/a

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 10:48:25 -0400

> deployed equipment or making assertions that can't be verified by the

I think this is just another caveat on existing equipment. Some  
phones, if P-A-ID is present, will preferentially display it. Some  
will do this even in the presence of an Identity-signed From: field  
that contains conflicting information (inasmuch as they ignore  
Identity completely and prefer P-Asserted-Identity to From).

This is simply something that happens. We have to analyze the  
situation from a backward-compatibility perspective.

Proposal: Include a usage disclaimer parameter on the URI in the From:  
field of a request to which we apply RFC 4474 authentication service,  
resulting in an Identity header that signs the request (including the  
URI part of the From: field).

Case 1: Somebody in the loop is RFC 2543 and not 3261

Result: Proposal breaks because RFC 2543 nodes may fail when proxies  
change From: fields. This doesn't bother me at all.

Case 2: Receiver doesn't understand RFC 4474 or this proposal:

Subcase 2a: Receiver prefers From: field

Result: Contents of From: field are rendered. This MAY inform a  
knowledgeable user of the lack-of-trust, but probably won't.

Subcase 2b: Receiver prefers P-A-ID

Result: Contents of P-A-ID are rendered. So this results depends on  
how P-A-ID was populated, which is up to the implementation.

Case 2: Receiver understands RFC 4474 but not this proposal:

Result: Contents of From: field are rendered as verified. Depending on  
the rendering, this may either inform a knowledgeable user, or display  
as verified information that we know is not verified.

Case 3: Receiver understands RFC 4474 and this proposal (and DTLS- 
SRTP) :

Result: Contents of From: field are rendered as unverified. Media is  
encrypted. Media is verifiably bound to signaling. All is good.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2008 12:27:16 -0400

John, can you elaborate more on the straw-man proposal?  I'm not sure I fully grok it.

When I commented at the mic that the problem with such a concept, assuming I understand the proposal, is that there is nothing stopping any middle-man or frankly anything on the planet from simply signing a [number]@domain, for their domain name.  Jonathan's response I think was "well that makes it the same strength as PSTN".  But this makes it effectively useless to sign or verify.  Why bother signing?  Just use PAID. (which may well be the final result of all this discussion)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: Thursday, March 13, 2008 6:17 PM
> To: Dwight, Timothy M (Tim); IETF SIP List
> Subject: Re: [Sip] The thing we're missing in the RFC 4474 and DTLS-
> SRTPdiscussion
>
> > > assertion"
> > > gateways

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2008 12:31:11 -0400

> change From: fields. This doesn't bother me at all.

Amen. Seems to me it has been long enough that we ought to stop worrying 
about 2543 compatibility.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2008 12:40:24 -0400

> When I commented at the mic that the problem with such a concept, assuming I understand the proposal, is that there is nothing stopping any middle-man or frankly anything on the planet from simply…

I too am struggling with this.

I think this only makes sense if you then make a policy decision: a 
white list of signing domains from which you will accept signatures for 
phone numbers. But I don't understand how you populate that white list 
in a useful way. Seems like either it is "your own enterprise (if you 
have one) and your own SP", or else it is based on your trust in the 
root CA for the signer.

The latter only works if there are one or more root CAs that enforce 
some sort of meaningful policy over who they will provide certs to. That 
in turn starts to sound a lot like policies for ENUM.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 17:40:53 +0000

Dean,

I like your proposal. I think return calls should work too. If sent to
the URI (complete with lack-of-trust parameter), it should cause the
request to route to the same gateway (or another in the same domain),
which can simply ignore the lack-of-trust parameter and route to PSTN
(or even do an ENUM look-up and route onwards in SIP if that turns out
to be possible).

Also an intermediate SIP entity might ignore the domain part and route
only on the phone number, but again I think no harm is done.

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 14 March 2008 14:48
> To: Adam Roach
> Cc: Elwell, John; IETF SIP List
> andDTLS-SRTPdiscussion

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 17:52:05 +0000

Adam,

I am confused how we got here. As I said in a response to Dean a few
minutes ago, I think a level-of-trust parameter could work. Dean
explained the different options of UASs on receiving information in both
PAI and From.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 14 March 2008 14:18
> To: Elwell, John
> Cc: Dean Willis; IETF SIP List

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 18:01:49 +0000

Hadriel,

Part of the straw man proposal was "If a user is identified by a phone
number, its domain can sign with an RFC 4474 signature if it believes
that calls to that number will reach the user".
So yes, an intervening domain can change the domain name and resign,
which is fine as long as you can get back to that E.164 number via that
domain. As far as DTLS-SRTP is concerned, it means media are secured as
far as that domain. It is slightly better than PAI because it signs the
fingerprint of the certificate to be used for DTLS. If you want
something better, use so-called "email-style" URIs, which can't be
changed by intermediate domains (without totally breaking things).

John

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 14 March 2008 16:27
> To: Elwell, John; Dwight, Timothy M (Tim); IETF SIP List
> Subject: Straw-man for rfc4474 and e164
> 
> When I commented at the mic that the problem with such a 
> concept, assuming I understand the proposal, is that there is 
> nothing stopping any middle-man or frankly anything on the 
> planet from simply signing a [number]@domain, for their 
> domain name.  Jonathan's response I think was "well that 
> makes it the same strength as PSTN".  But this makes it 
> effectively useless to sign or verify.  Why bother signing?  
> Just use PAID. (which may well be the final result of all 
> this discussion)
> 
> -hadriel
> 
> Behalf Of

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 18:04:13 +0000

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 14 March 2008 16:40
> To: Hadriel Kaplan
> Cc: Elwell, John; Dwight, Timothy M (Tim); IETF SIP List
> Subject: Re: [Sip] Straw-man for rfc4474 and e164
> 
> 
> 
> Hadriel Kaplan wrote:
> have one) and your own SP",
[JRE] Yes, probably just these too. This is a limitation of phone number
based URIs.

> or else it is based on your trust in the 
> root CA for the signer.
> 
> and DTLS-

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2008 15:01:04 -0400

> From: Elwell, John [mailto:[email-masked]]
>
> fingerprint of the certificate to be used for DTLS.

Right, but any domain can do this, whether they're right or wrong or lying on purpose.  As far as the UAS or UAC know, there is a long chain of trust in the middle, or a chain with no trust whatsoever.  Since any domain anywhere can do it, without repercussion, knowing that DTLS-SRTP is working to/from that random domain has little value.  It means nothing about the end-to-end security of the media or signaling or message contents.  It would naturally devolve to only believing the signature of your next-hop domain, at which point there is no need to sign anything using rfc4474 - you might as well just believe PAI and the fingerprint attribute your next-hop gave you.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 19:48:00 +0000

Hadriel,

What I want is the end domain, e.g., my bank. Being assured my call is
secured as far as my service provider gives me no confidence it is
secured as far as my bank or whatever domain I want to communicate with.
That is why "email-style" is so much better than phone-number-based.

John 

> Sent: 14 March 2008 19:01
> Subject: RE: Straw-man for rfc4474 and e164
> 
> 
> 
> Right, but any domain can do this, whether they're right or 
> wrong or lying on purpose.  As far as the UAS or UAC know, 
> there is a long chain of trust in the middle, or a chain with 
> no trust whatsoever.  Since any domain anywhere can do it, 
> without repercussion, knowing that DTLS-SRTP is working 
> to/from that random domain has little value.  It means 
> nothing about the end-to-end security of the media or 
> signaling or message contents.  It would naturally devolve to 
> only believing the signature of your next-hop domain, at 
> which point there is no need to sign anything using rfc4474 - 
> you might as well just believe PAI and the fingerprint 
> attribute your next-hop gave you.
> 
> -hadriel
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 21:32:28 -0500

> But here's the problem with Adam's idea.:

well, this came out all wrong.

I had thought Adam was changing the From header field in the
authentication server, which would confuse RFC 2543 style gateways.

Rather, he is suggesting that SRTP-DTLS compliant gateways add a
parameter to their From header field that indicates the identity was
received PSTN and should be treated accordingly.

I think this approach works very well.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 21:36:29 -0500

Hadriel Kaplan wrote:
> When I commented at the mic that the problem with such a concept,
> assuming I understand the proposal, is that there is nothing stopping
> any middle-man or frankly anything on the planet from simply signing
> a [number]@domain, for their domain name.  Jonathan's response I
> think was "well that makes it the same strength as PSTN".  But this
> makes it effectively useless to sign or verify.  Why bother signing?
> Just use PAID. (which may well be the final result of all this
> discussion)

You MUST sign in order to be able to use DTLS-SRTP effectively. This
means that even PSTN-grade identities have to be signed. So we we either
have to change DTLS-SRTP to not have this dependency, or we have to find
a way to mark the PSTN-grade ones appropriately so that they are not
taken seriously as a strong identity.

Adam's approach solves this better than us1ing PAID, as 1) we could NOT
have DTLS-SRTP (a standareds-track doc) with a normative reference to
RFC 3325 (an informational track doc). Further, the same problem applies
-- even with RFC 3325, it would be good to differentiate strong
identities from PSTN-grade identities.

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 21:37:44 -0500

> explained the different options of UASs on receiving information in both

Adam came up with a better way to mark level-of-trust than I did. Other
than that, it is the same solution (that is, interpreted the same way).

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 15 Mar 2008 09:35:05 -0400

At Fri, 14 Mar 2008 21:36:29 -0500,
Dean Willis wrote:
> You MUST sign in order to be able to use DTLS-SRTP effectively.

This is not correct.

Even in the absence of signatures, DTLS-SRTP provides significant
value because you need to actively modify both the signalling
and the media (what draft-ietf-sip-media-security-requirements
calls active-signaling-active-media).

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Mar 2008 13:02:46 -0400

> taken seriously as a strong identity.

No, you don't have to rfc4474 sign dtls-srtp fingerprint attributes.  Rfc4474 signing them prevents SIP devices between the signer and the verifier from modifying the attribute to become a dtls-srtp man-in-the-middle.  If a MitM can re-sign without the verifier detecting it, then rfc4474 signing is pointless, even for the DTLS-SRTP fingerprint attribute.

And that is the problem with e164.  If foo.com can receive sip:[email-masked], and change it to sip:[email-masked], and the UAS only displays "+12128675309" or the human only cares about that part because they think it's a phone number, then there's little point in signing.

> identities from PSTN-grade identities.

You wouldn't need to reference rfc3325 in dtls-srtp-framework (and it's the framework this is about, btw, not dtls-srtp).  PAID has nothing to do with the fingerprint - it has to do with identity.  My point was you already do have PSTN-grade identities: PAID is it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Mar 2008 13:17:35 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
>

I think they should add it as a URI-param, or even URI-username param.  Both because it's about the type of username or URI itself, and because then rfc4474 would actually include that param in its signature, so no one in the middle could change it.  Of course that uri-param already exists: user=phone.  Or is that not the right semantic?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Mar 2008 13:36:25 -0400

> That is why "email-style" is so much better than phone-number-based.

Sure, and that works well for domain names you recognize, if your UA displays it, because really you're mentally treating it as an email-style URI.  (and also why Paul said this would only work for whitelists) But if it is a call from sip:[email-masked] signed by cht.com.tw, it would mean nothing to most people.  The verifier would think it's fine as would your UAS, and it may be fine (Chunghwa Telecom is a legit telco).  Or it may be that CHT got it from a CLID spoofer service in the PSTN, or CHT is mis-configured, or a CLID spoofer provider itself. (they're not, but you wouldn't know that, and the fact that a +1 number came from Chunghwa Telecom is suspicious)

The straw-man says CHT would only sign it "if it believes that calls to that number will reach the user".  I'm not actually sure what that means.  I think you mean if calls to that username number would reach the same domain that's signing it??  Regardless, if CHT *were* to offer a CLID spoofer service, it would obviously sign it anyway, and no one would be wiser.  For email-style URI's that's not possible, because CHT can't sign sip:[email-masked].  Siemens could sign it maliciously, but doing so only spoofs siemens.com's users.  Whereas CHT signing sip:[email-masked] maliciously actually spoofs the real owner of +12128675309 globally, because it is treated by machines and humans as a global identity regardless of the domain.

-hadriel

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 15 Mar 2008 12:11:55 -0500

------- Original message -------
From: Eric Rescorla <[email-masked]>
Cc: [email-masked], [email-masked]
Sent: 15.3.'08,  8:35

> calls active-signaling-active-media).

AFAIK (which admittedly is not all that far) if you have no fingerprint, 
you lose a key advantage of DTLS-SRTP, which is the ability to correlate 
media and signaling. Without this, we're still subject to all the media 
insertion attacks, some of which do not even require MITM.

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 15 Mar 2008 12:18:42 -0500

------- Original message -------
From: Hadriel Kaplan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sent: 15.3.'08,  12:14

Dean
> I think they should add it as a URI-param, or even URI-username param.  
Both because it's about the type of username or URI itself, and because 
then rfc4474 would actually include that param in its signature, so no one 
in the middle could change it.  Of course that uri-param already exists: 
user=phone.  Or is that not the right semantic?

yes, that is what I think Adam proposed in general. To reiterate, he 
suggested adding a URI paramter to the URI in the From header field at the 
gateway device.  

As I understand it, there are use cases where an authentication service can 
make a strong assertion of idenity about a URI that has user=phone, so I do 
not think that has the semantic we are looking for. I think we need another 
parameter.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 16 Mar 2008 13:33:14 -0400

> insertion attacks, some of which do not even require MITM.

Eric (I think) and I are not talking about having no dtls-srtp fingerprint - that's an SDP attribute.  We're talking about not having the rfc4474 signature signing that fingerprint attribute.  Even without the rfc4474 signature, an attacker has to be able to modify that SDP fingerprint attribute to succeed, and thus be in the signaling path.  The rfc4474 signature just prevents anyone between the signer and verifier from being able to do so.

If the rfc4474 mechanism is signed at the originating domain and verified at the terminating domain, that's fairly useful.  It's not secure end-to-end, because anything between the UAC and signer, the signer itself, the verifier itself, or anything between the verifier and the UAS, can be active mitm.  But the assumption is the UAC trusts its domain, and the UAS trusts its domain, and the domains trust each other.  But if rfc4474 can be re-signed by middle-domains willy-nilly, then it's just hop-by-hop trust which SIP already has today so there's little point in incurring the cost of signing and verifying.  The dtls-srtp-framework fingerprint attribute already has the hop-by-hop trust model without rfc4474.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 16 Mar 2008 20:36:34 -0500

Hadriel Kaplan wrote:

> Eric (I think) and I are not talking about having no dtls-srtp
> fingerprint - that's an SDP attribute.  We're talking about not
> having the rfc4474 signature signing that fingerprint attribute.
> Even without the rfc4474 signature, an attacker has to be able to
> modify that SDP fingerprint attribute to succeed, and thus be in the
> signaling path.  The rfc4474 signature just prevents anyone between
> the signer and verifier from being able to do so.

Ok, I missed this.

I really thought DTLS-SRTP required an RFC 4474 Identity header. That's 
why I asked the question several times, both in person (with EKR) and on 
the list.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 16 Mar 2008 21:34:28 -0700

> > the signer and verifier from being able to do so.

Said another way:

Without RFC4474, DTLS-SRTP (and TLS-comedia [RFC4572]) are vulnerable 
to an active attacker if that attacker is on both the media path
(to modify the (D)TLS handshake) and the signal path (the modify
the a=fingerprint).

> Ok, I missed this.
> 
> I really thought DTLS-SRTP required an RFC 4474 Identity 
> header. That's why I asked the question several times, both in 
> person (with EKR) and on the list.

It depends on if you want protection from active attackers; if
you do, you need RFC4474.  If you don't, you don't need RFC4474.

-d

---

From: "Jason Fischl" <[email-masked]>
Date: Mon, 17 Mar 2008 22:05:15 -0700

> gateways BEFORE we get deployment lets us work around the problem.

Forgot to post this last week. The resiprocate (open source) sip stack has
supported RFC 4474 for several years now and has been deployed in a number
of commercial products including user agents, proxies and b2buas.
_______________________________________________
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: Mon, 17 Mar 2008 22:48:08 -0700

> Forgot to post this last week. The resiprocate (open source) 
> sip stack has supported RFC 4474 for several years now and 
> has been deployed in a number of commercial products 
> including user agents, proxies and b2buas. 

Excellent.  Is there information regarding its success with
E.164 numbers, SBCs, and user's understanding of an E.164 
with a domain name stuck after it?  Do those UAs, which
support RFC4474, display the domain name?

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Mar 2008 16:53:14 +0000

Hadriel,

> Sent: 15 March 2008 17:36
> To: Elwell, John; IETF SIP List
> Sure, and that works well for domain names you recognize, if 
> your UA displays it, because really you're mentally treating 
> it as an email-style URI.  (and also why Paul said this would 
> only work for whitelists) But if it is a call from 
> sip:[email-masked] signed by cht.com.tw, it would 
> mean nothing to most people.  
[JRE] Exactly, and therefore if the person claims to be from my bank I
would probably be very suspicious.

> The verifier would think it's 
> fine as would your UAS, and it may be fine (Chunghwa Telecom 
> is a legit telco).  Or it may be that CHT got it from a CLID 
> spoofer service in the PSTN, or CHT is mis-configured, or a 
> CLID spoofer provider itself. (they're not, but you wouldn't 
> know that, and the fact that a +1 number came from Chunghwa 
> Telecom is suspicious)
> 
> The straw-man says CHT would only sign it "if it believes 
> that calls to that number will reach the user".  I'm not 
> actually sure what that means.  I think you mean if calls to 
> that username number would reach the same domain that's 
> signing it??  Regardless, if CHT *were* to offer a CLID 
> spoofer service, it would obviously sign it anyway, and no 
> one would be wiser.  For email-style URI's that's not 
> possible, because CHT can't sign sip:[email-masked]. 
>  Siemens could sign it maliciously, but doing so only spoofs 
> siemens.com's users.  Whereas CHT signing 
> sip:[email-masked] maliciously actually spoofs the 
> real owner of +12128675309 globally, because it is treated by 
> machines and humans as a global identity regardless of the domain.
[JRE] I think what the straw man meant is that CHT should sign it if, by
routing a return request back to CHT, CHT would be able to route that
return request to the entity that was the source of the original
request. So if CHT somehow authenticated the original request as coming
from [email-masked], it could sign it has having come from
[email-masked] and then, on receiving a return request to
[email-masked], could route it on to [email-masked].
How helpful is this to the receiver of the original request? It just
means that return routability via CHT should work, and not that CHT.com
is the end domain from which the original request came. Not very useful
for authentication purposes. But on the other hand, an unchanged From
URI ([email-masked]) might be more useful.

John