Subject: [Sip] comments on draft-ietf-sip-dtls-framework

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2007 11:36:36 -0500

I think there is an additional issue that should be discussed in the 
security considerations section.

The draft relies heavily on sip identity to provide integrity over the 
fingerprint. The underlying assumption is that a MITM downstream would 
need to modify the fingerprint and thus would also need to modify the 
identity since it couldn't resign with the original domain.

This assumption is a good one in deployments that use user@domain 
identifiers - [email-masked]. However, the unfortunate reality is that 
the majority of sip deployments today use phone numbers. These are often 
represented in sip URI form - sip:[email-masked]. However, when 
phone numbers are used, the domain part is often ignored and most of the 
time not even rendered to the user. Even if it were, its not a 
"significant" part of the identifier, in that a user won't normally know 
or care what the domain part is.

What this means is that when phone numbers are in use, a MITM can easily 
rewrite the From field. So if it was sip:[email-masked] they can 
rewrite to sip:[email-masked], insert a media intermediary 
and new fingerprint and resign. The called UA or terminating proxy will 
verify that the identity is valid (which it is) and the called party is 
presented with the caller ID, which is JUST the phone number. So they 
don't notice a problem at all.

Thus, in practice, I fear dtls-srtp will easily allow proxies and SBCs 
on the chain to intercept and modify the media stream, similar to what 
they could do with sdescriptions. This is really a problem with sip 
identity itself that carries over here. But I think this issue needs to 
be mentioned and discussed. The draft makes itself out to be 
substantially more secure than sdescriptions or MIKEY because of its e2e 
nature but in practice I don't think it will be as effective.

Other minor comments:

> [RFC4572].  The Real-Time Protocol (RTP) [RFC3550] is used to
>    transmit real time media on top of UDP, TCP [RFC4571], and TLS
>    [RFC4572].

actually this isn't true; rfc4572 says it does not apply to RTP. From 
rfc4572:

    This document does not define any mechanism for securely transporting
    RTP and RTP Control Protocol (RTCP) packets over a
    connection-oriented channel.  There was no consensus in the working
    group as to whether it would be better to send Secure RTP packets
    [23] over a connection-oriented transport [24], or whether it would
    be better to send standard unsecured RTP packets over TLS using the
    mechanisms described in this document.  The group consensus was to
    wait until a use-case requiring secure connection-oriented RTP was
    presented.

> This draft provides guidelines on how to use and to
>    support for (a) transmission of media over DTLS and (b) to establish
>    SRTP security using extensions to DTLS (see
>    [I-D.ietf-avt-dtls-srtp]).

something is missing in this sentence. Maybe, "this draft provides 
guidelines on how to use and support DTLS for transmission of media and 
how to establish SRTP secureity using...."

> The media is transported over a mutually authenticated DTLS session
>    where both sides have certificates.  The certificate fingerprints are
>    sent in SDP over SIP as part of the offer/answer exchange.  The SIP
>    Identity mechanism [RFC4474] is used to provide integrity for the
>    fingerprints.  It is very important to note that certificates are
>    being used purely as a carrier for the public keys of the peers.
>    This is required because DTLS does not have a mode for carrying bare
>    keys, but it is purely an issue of formatting.  The certificates can
>    be self-signed and completely self-generated.  All major TLS stacks
>    have the capability to generate such certificates on demand.
>    However, third party certificates MAY also be used for extra
>    security.

suggest that the statements on self-signing get moved up to immediately 
after the first sentence. Otherwise, the reader is immediately confused, 
since most folks equate certificates with PKI, and the previous 
paragraph just said that no PKI is required.

> This approach differs from previous attempts to secure media traffic
>    where the authentication and key exchange protocol (e.g., MIKEY
>    [RFC3830]) is piggybacked in the signaling message exchange.  With
>    this approach, establishing the protection of the media traffic
>    between the endpoints is done by the media endpoints without
>    involving the SIP/SDP communication.

should be clear that "this appraoch" is referring to dtls-srtp and NOT 
mikey/sdesciptions. Also you might want to include a reference to 
sdescriptions here also.

Figure 1: the figure shows bidirectional arrows between elements, but 
the notations around authentication information indicate that this is 
really talking about an initial INVITE from alice to bob. Suggest that 
the arrows face right only in this flow.

Also, I think using the term, "signaling traffic" for the dtls handshake 
is confusing. Since folks equate, "signaling traffic" with sip. Suggest 
using a different term, perhaps "key management traffic" and use a 
different line style.

> Alice sends an SDP offer to Bob over SIP.  If Alice uses only self-
>    signed certificates for the communication with Bob, a fingerprint is
>    included in the SDP offer/answer exchange.  This fingerprint is
>    integrity protected using the identity mechanism defined in
>    Enhancements for Authenticated Identity Management in SIP [RFC4474].
>    When Bob receives the offer, Bob establishes a mutually authenticated
>    DTLS connection with Alice.  At this point Bob can begin sending
>    media to Alice.  Once Bob accepts Alice's offer and sends an SDP
>    answer to Alice, Alice can begin sending confidential media to Bob.

this is lacking from an overview of operations perspective. I suggest 
also mentioning that alice and bob will verify the fingerprints from the 
certs received over the dtls handshakes with those in the sip signaling, 
providing a correlation function. Mention that this provides the 
security property that you know your media traffic is going to the 
person you called, without necessarily providing a secure version of the 
identity of that person. This is the key idea of dtls-srtp that needs to 
be in here.

> DTLS/TLS uses the term "session" to refer to a long-lived set of
>    keying material that spans associations.  In this document,
>    consistent with SIP/SDP usage, we use it to refer to a multimedia
>    session and use the term "TLS session" to refer to the TLS construct.
>    We use the term "association" to refer to a particular DTLS
>    ciphersuite and keying material set. 

association and session both claim to use a single keying set. So its 
not clear what the difference is. Maybe associations use keys derived 
from the session keys? SHould clarify here.

> 6.1.  Anonymous Calls
> 
>    When making anonymous calls, a new self-signed certificate SHOULD be
>    used for each call so that the calls can not be correlated as to
>    being from the same caller.  

this is not even close to sufficient for anonymity. The IP address will 
be the same. So this needs to be called out that this is just referring 
to the DTLS part or else the rest of anonymity needs to be defined.

>  Note that in the situation where a request forks to multiple
>    endpoints that all share the same certificate, there is no way for
>    the caller to correlate the DTLS associations with the SIP dialogs.
>    Practically, this is not a problem, since the callees will terminate
>    the unused associations.

the issue isn't just which ones to keep; its correlating for UI 
purposes. For example, talking indicators or media hold. Each side needs 
to know which stream is associated with each dialog. Isn't a better 
solution to just have a unique certificate per device? Or else rely on 
something else for correlation (i.e., ice).

Indeed the draft should call out that when ice is used, ice itself will 
provide this correlation and it happens even prior to the start of dtls.

> be able to demultiplex STUN packets from DTLS packets.  STUN
>    [RFC3489] packets MUST NOT be sent over DTLS.

should reference 3489bis.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2007 09:20:57 -0800

At Mon, 19 Nov 2007 11:36:36 -0500,
Jonathan Rosenberg wrote:
> be mentioned and discussed.

I don't know enough about implementations to know if this is correct,
so let's stipulate that it is. Fundamentally, this is a SIP problem
and not a DTLS-SRTP problem. Not knowing who the signally refers
to isn't any better just because you don't bother to encrypt the
media.

That said, I don't think this is as bad as you make it out to
be in terms of MITM. The calling party knows the URI and can
(and must) mechanically enforce the URI match that the callee
presents, including the domain name.  This prevents MITM
attacks. Impersonation attacks on the called party remain,
but this can't be solved without actually presenting all
the relevant identity information to the user, regardless of
what the media security layer does.

> The draft makes itself out to be 

I don't understand this sentence. SDESCRIPTIONS doesn't even require
an active attack on the connection and MIKEY has exactly the same
issue unless you verify the certs, which of course you *can* do with
DTLS-SRTP.

> from the session keys? SHould clarify here.

There's no such thing as a session key in TLS. A session is the
master_secret. The association refers to the traffic keys.

> this is not even close to sufficient for anonymity.

Of course not. It's sufficient to stop DTLS from screwing up otherwise
working anonymity.

> The IP address will 
> solution to just have a unique certificate per device?

Not necessarily, no.

> Or else rely on 

Yes.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Nov 2007 13:48:23 -0500

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Monday, November 19, 2007 12:21 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework
>

I thought DTLS-SRTP was going to recommend the end users read out the fingerprint (or some section thereof), similar to the SAS model for ZRTP, no?  That is the only thing guaranteeing a middle-man hadn't done what Jonathan's worried about.  I thought it was well understood a middle-box could do this even with 4474; at least we talked about it in the context of ZRTP.  And this isn't just URI-changing hops - if the identity signer or verifier domain providers want to change the fingerprint+sdp and get cleartext, they can.  Human verification of the fingerprint is the only thing that would stop it. (and then only until real-time voice-spoofing becomes good enough)  No?

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2007 11:01:56 -0800

At Mon, 19 Nov 2007 13:48:23 -0500,
Hadriel Kaplan wrote:
> I thought DTLS-SRTP was going to recommend the end users read out
> the fingerprint (or some section thereof), similar to the SAS model
> for ZRTP, no? 

No. That's impractical and insecure for reasons I indicated in my
presentation in Prague.

> That is the only thing guaranteeing a middle-man
> hadn't done what Jonathan's worried about.  I thought it was well
> understood a middle-box could do this even with 4474; at least we
> talked about it in the context of ZRTP.  And this isn't just
> URI-changing hops - if the identity signer or verifier domain
> providers want to change the fingerprint+sdp and get cleartext, they
> can.

Yes, as Jon Peterson observed in another context, the identity
signer, not you, owns your identity. They can do whatever they
want. If you're concerned about your identity provider mounting
a MITM attack on you, you either need:

1. A new identity provider.
2. To use third-party certificates as a backup.
3. Out-of-band verification of the peer's certificate fingerprint.

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 Nov 2007 14:42:14 -0600

Jonathan,

What you are describing is actually a problem of non-compliance
with SIP, where people are improperly using SIP URIs
as if they were a Tel URI.

As you point out, they are adding a "bogus" domain name and
route purely on the phone number and ignore the domain
name.

This is quite unfortunate because, it 
invalidates most "phone number-derived SIP URIs" in terms
of SIP Identity. It is unfortunate, since if people used
a native Tel URI for cases where the domain is 
irrelevant, we wouldn't have this problem (and we couldn't
use DTLS-SRTP for this).

Basically, "telephone number routing" overlaid on top of
SIP breaks SIP routing. If I call somebody at [email-masked], 
I really have no garantee that it won't end-up at 
[email-masked].

This problem more than a SIP Identity problem. It's more
of a SIP usage problem.

Not sure how to deal with it.

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 08:37
> To: IETF SIP List
> Subject: [Sip] comments on draft-ietf-sip-dtls-framework
> 
> I think there is an additional issue that should be discussed 
> in the security considerations section.
> 
> The draft relies heavily on sip identity to provide integrity 
> over the fingerprint. The underlying assumption is that a 
> MITM downstream would need to modify the fingerprint and thus 
> would also need to modify the identity since it couldn't 
> resign with the original domain.
> 
> This assumption is a good one in deployments that use 
> user@domain identifiers - [email-masked]. However, the 
> unfortunate reality is that the majority of sip deployments 
> today use phone numbers. These are often represented in sip 
> URI form - sip:[email-masked]. However, when phone 
> numbers are used, the domain part is often ignored and most 
> of the time not even rendered to the user. Even if it were, 
> its not a "significant" part of the identifier, in that a 
> user won't normally know or care what the domain part is.
> 
> What this means is that when phone numbers are in use, a MITM 
> can easily rewrite the From field. So if it was 
> sip:[email-masked] they can rewrite to 
> sip:[email-masked], insert a media intermediary 
> and new fingerprint and resign. The called UA or terminating 
> proxy will verify that the identity is valid (which it is) 
> and the called party is presented with the caller ID, which 
> is JUST the phone number. So they don't notice a problem at all.
> 
> Thus, in practice, I fear dtls-srtp will easily allow proxies 
> and SBCs on the chain to intercept and modify the media 
> stream, similar to what they could do with sdescriptions. 
> This is really a problem with sip identity itself that 
> carries over here. But I think this issue needs to be 
> mentioned and discussed. The draft makes itself out to be 
> substantially more secure than sdescriptions or MIKEY because 
> of its e2e nature but in practice I don't think it will be as 
> effective.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 19:11:00 -0500

This problem has bugged me for a *long* time. I've tried to encourage 
use of tel: when the target address is a phone number, and I've tried to 
encourage care in what is used to display caller id. (Don't just strip 
the domain and display the number.) But I haven't had much luck.

Of course, not having an identity solution for phone numbers is also a 
serious problem, with no known solution that I am aware of.

Perhaps we need to start using the ENUM mappings of telephone numbers as 
the basis of identity. E.g.

	From: "+1-978-555-1234" <sip:4.3.2.1.5.5.5.8.7.9.1.e164.arpa>

and then apply sip identity to that.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 Nov 2007 18:17:05 -0600

Funny you should say that... I was also thinking of ENUM when I wrote this.

But I wasn't thinking of putting the ENUM in the From. I was thinking
of doing enum on the phone number, to verify the domain of the owner, and
correlate it with Identity. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 16:11
> To: Audet, Francois (SC100:3055)
> Cc: Jonathan Rosenberg; IETF SIP List
> This problem has bugged me for a *long* time. I've tried to 
> encourage use of tel: when the target address is a phone 
> number, and I've tried to encourage care in what is used to 
> display caller id. (Don't just strip the domain and display 
> the number.) But I haven't had much luck.
> 
> Of course, not having an identity solution for phone numbers 
> is also a serious problem, with no known solution that I am aware of.
> 
> Perhaps we need to start using the ENUM mappings of telephone 
> numbers as the basis of identity. E.g.
> 
> > What you are describing is actually a problem of 
> non-compliance with 
> > SIP, where people are improperly using SIP URIs as if they 
> were a Tel 
> > URI.
> > 
> > As you point out, they are adding a "bogus" domain name and route 
> > purely on the phone number and ignore the domain name.
> > 
> > This is quite unfortunate because, it invalidates most "phone 
> > number-derived SIP URIs" in terms of SIP Identity. It is 
> unfortunate, 
> > since if people used a native Tel URI for cases where the domain is 
> > irrelevant, we wouldn't have this problem (and we couldn't use 
> > DTLS-SRTP for this).
> > 
> > Basically, "telephone number routing" overlaid on top of SIP breaks 
> > SIP routing. If I call somebody at 
> [email-masked], I really 
> > have no garantee that it won't end-up at
> > [email-masked].
> > 
> > This problem more than a SIP Identity problem. It's more of a SIP 
> > usage problem.
> > 
> >> The draft relies heavily on sip identity to provide integrity over 
> >> the fingerprint. The underlying assumption is that a MITM 
> downstream 
> >> would need to modify the fingerprint and thus would also need to 
> >> modify the identity since it couldn't resign with the original 
> >> domain.
> >>
> >> identifiers - [email-masked]. However, the unfortunate reality is 
> >> that the majority of sip deployments today use phone 
> numbers. These 
> >> are often represented in sip URI form - 
> sip:[email-masked]. 
> >> However, when phone numbers are used, the domain part is often 
> >> ignored and most of the time not even rendered to the 
> user. Even if 
> >> it were, its not a "significant" part of the identifier, in that a 
> >> What this means is that when phone numbers are in use, a MITM can 
> >> easily rewrite the From field. So if it was 
> >> sip:[email-masked], insert a media 
> intermediary and new 
> >> fingerprint and resign. The called UA or terminating proxy will 
> >> verify that the identity is valid (which it is) and the 
> called party 
> >> is presented with the caller ID, which is JUST the phone 
> number. So 
> >> they don't notice a problem at all.
> >>
> >> Thus, in practice, I fear dtls-srtp will easily allow proxies and 
> >> SBCs on the chain to intercept and modify the media 
> stream, similar 
> >> to what they could do with sdescriptions.
> carries over 
> >> here. But I think this issue needs to be mentioned and 
> discussed. The 
> >> draft makes itself out to be substantially more secure than 
> >> sdescriptions or MIKEY because of its e2e nature but in practice I 
> >> don't think it will be as effective.
> > 
> > 
> > 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2007 12:06:31 -0500

inline:

> as if they were a Tel URI.

I don't think its a non-compliance issue; there is nothing in the spec 
that says you need to render to the domain part.

> route purely on the phone number and ignore the domain

Its ignored on the terminating UA; clearly within request-URI it is used 
to route the request along. But my point is that it is not a significant 
part of the identifier that a *user* cares about or validates.

> irrelevant, we wouldn't have this problem (and we couldn't

Or SIP Identity.

> Not sure how to deal with it.

Right now, I'm not proposing to deal with it at all. I'm just saying, 
this is a practical consideration that ought to be mentioned in the 
security considerations of draft-ietf-sip-dtls-framework.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 20 Nov 2007 11:21:07 -0600

> Sent: Tuesday, November 20, 2007 09:07
> Cc: IETF SIP List; Eric Rescorla
> I don't think its a non-compliance issue; there is nothing in 
> the spec that says you need to render to the domain part.

It's not the rendering I'm worried about.

It's the fact that the domain is ignored for routing, and only the userpart
is used.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Nov 2007 09:51:44 -0800

On Nov 19, 2007, at 8:36 AM, Jonathan Rosenberg wrote:

> easily rewrite the From field. So if it was sip: 
> [email-masked] they can rewrite to sip:9739525060@middle- 
> domain.com, insert a media intermediary and new fingerprint and  
> resign. The called UA or terminating proxy will verify that the  
> identity is valid (which it is) and the called party is presented  
> with the caller ID, which is JUST the phone number. So they don't  
> notice a problem at all.
>
> SBCs on the chain to intercept and modify the media stream, similar  
> to what they could do with sdescriptions. This is really a problem  
> with sip identity itself that carries over here. But I think this  
> issue needs to be mentioned and discussed. The draft makes itself  
> out to be substantially more secu

This gets to exactly the heart of why I think there is no need for  
the  draft-wing-sip-identity-media draft. Let's talk about how trust  
is going to work with phone numbers as identifies (ignoring that it  
is even SIP here).

Say company some phone with the number +1 123 555-1111 makes a call -  
it is at company with a PBX, call them IBM, connect to a telephony  
service provider, call them Sprint, and sends the call to another  
called say AT&T, that hands the call to another company PBX called,  
say Cisco, and we want to assert something about the caller's phone  
number.

There is no practical way for Cisco to know who +1 123 555-1111 was  
allocated to or for that person to prove they can use it. What  
happens is that Cisco has a relationship with AT&T and trust them not  
to deliver correct information. LIkewise AT&T has contracts with some  
people as trusts Sprint. They may not trust every telco they peer  
with in this form but for this example let's say they do trust Sprint  
to correctly not lie if Sprint claims they can verify the number is  
correct. (It's fine for Sprint to pass calls where they do not claim  
to know the number is correct too). Now sprint does know what numbers  
it allocated to IBM and has  contract with IBM so Sprint can decide  
if  +1 123 555-1111 was OK or not.

Now Identity gives us a way to realize all of this that protects from  
attackers modifying things along the chain.  IBM signs and the number  
as IBM and sends on to sprint. Sprint can use this to decide if they  
believe this OK or not along with their policy information. Now if  
sprint thinks it OK, they insert the assertion they think it OK and  
hand to AT&T. AT&T looks at it and decides that it was OK for sprint,  
then it is OK for them and inserts their assertion that it OK and  
hands down to Cisco. Cisco looks for the AT&T assertion and since it  
one of the carriers they trust, decides it is OK.
<bold> As far as I can tell, anything other than this won't work for  
phone numbers </bold>. This means that the PBX needs to require that  
the identity it trusts to sign numbers is some it trusts -  
practically this means the one or more carriers that it connects to.  
These carriers need to have their SBC (or proxies if they used  
theses) insert an assertion about if the number is OK or not.

You might think there is something better than this but really it is  
about who owns the namespace. If Sprint decides to give the number +1  
123 555-1111 to some other customer, say Acme, now Cisco needs to  
consider any assertion from IBM that they are 555-1111 to be false.  
The only person that knows there was a change was the namespace  
owner, Sprint in this case.  The number could even be given to a  
different carrier.  This solution is the best we can do given the  
constraints of the namespace allocation process. We can do much  
better with the names like sip:[email-masked] but that is a  
different topic.

Encrypted media is all constrained by it is no good having encrypted  
media to the attacker and the strength of the security is limited by  
the strength of how well you know who you are talking too. Here the  
DTLS keying fingerprint strength is exactly tied to the identity  
strength. If someone had some other way to knowing who they were  
talking too, such as SAS codes if that worked, then you can use those  
too.

The high point I am trying to make here is that you always have to  
trust whoever controls the namespace and for the case we are  
interested in here for phonenumbers, that implies a certain trust of  
the carriers. This in turn means that the Cisco  PBX in the example  
above needs to reject the signature of a phone number from middle- 
domain.com.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Nov 2007 21:46:56 -0500

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, November 25, 2007 12:52 PM
> To: IETF SIP List

I don't think it does.  The draft is more about real SIP URIs, such as sip:[email-masked].

> to deliver correct information.

I assume you mean "incorrect" information. :)

> theses) insert an assertion about if the number is OK or not.

This already happens through P-Asserted.  What you describe is hop-by-hop trust of identity, so why would you believe a 4474 signed request by your trusted previous-hop any less than a P-Asserted claim from it?  And what's more, why would each hop bother with the overhead of 4474 if it can just use P-Asserted?  If Cisco was concerned with something between them and AT&T, or AT&T concerned with something between them and Sprint, or Sprint concerned with something between them and IBM, why wouldn't they just use SIP/TLS for those peer connections?  It's less overhead and provides better security for those connections than 4474.

RFC4474's real use-case is one where there is an unchangeable namespace (ie, sip:[email-masked]) and the request crosses multiple domains.  But that is the one use case it will fail at without this draft.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Nov 2007 22:03:11 -0500

Cullen,

I agree with you that the sort of transitive trust you describe seems 
like a practical approach in many common sorts of deployments.

A fundamental part of this is that the recipient of identity only 
display this in a way that will be interpreted as trustworthy unless it 
indeed has reason to trust the identity. (This is a "duh" but is 
apparently widely violated.)

Earlier in this thread I proposed the idea of generating identity for 
calls from "phone numbers" (represented as TEL URIs) based on the enum 
lookup representation of the phone number. It is just a wild idea that I 
haven't thought through at all, but it might work. In practice it would 
probably mean that you might start with:

and as a result have a cert for that signed by 
<sip:3.2.1.5.5.5.8.7.9.1.e164.arpa> which in turn would be signed by 
<sip:2.1.5.5.5.8.7.9.1.e164.arpa>, etc.

(I guess in practice there would be fewer levels of delegation of 
authority than the number of digits.)

That would trade trust in the intermediaries that the call routes 
through for the ones that handle the actual assignments.

That of course depends on the existence of public enum for the identity 
of the caller, which doesn't seem the be a priority when the big 
carriers are involved. But it does seem to be a good complement to the 
sip identity mechanism, for use with phone numbers.

	Thanks,
	Paul

Cullen Jennings wrote:
>> easily rewrite the From field. So if it was sip:[email-masked] 
>> they can rewrite to sip:[email-masked], insert a media 
>> intermediary and new fingerprint and resign. The called UA or 
>> terminating proxy will verify that the identity is valid (which it is) 
>> and the called party is presented with the caller ID, which is JUST 
>> the phone number. So they don't notice a problem at all.
>>
>> identity itself that carries over here. But I think this issue needs 
>> to be mentioned and discussed. The draft makes itself out to be 
>> substantially more secu
> 
> This gets to exactly the heart of why I think there is no need for the  
> draft-wing-sip-identity-media draft. Let's talk about how trust is going 
> to work with phone numbers as identifies (ignoring that it is even SIP 
> here).
> 
> Say company some phone with the number +1 123 555-1111 makes a call - it 
> is at company with a PBX, call them IBM, connect to a telephony service 
> provider, call them Sprint, and sends the call to another called say 
> AT&T, that hands the call to another company PBX called, say Cisco, and 
> we want to assert something about the caller's phone number.
> 
> allocated to or for that person to prove they can use it. What happens 
> is that Cisco has a relationship with AT&T and trust them not to deliver 
> correct information. LIkewise AT&T has contracts with some people as 
> trusts Sprint. They may not trust every telco they peer with in this 
> form but for this example let's say they do trust Sprint to correctly 
> not lie if Sprint claims they can verify the number is correct. (It's 
> fine for Sprint to pass calls where they do not claim to know the number 
> is correct too). Now sprint does know what numbers it allocated to IBM 
> and has  contract with IBM so Sprint can decide if  +1 123 555-1111 was 
> OK or not.
> 
> attackers modifying things along the chain.  IBM signs and the number as 
> IBM and sends on to sprint. Sprint can use this to decide if they 
> sprint thinks it OK, they insert the assertion they think it OK and hand 
> to AT&T. AT&T looks at it and decides that it was OK for sprint, then it 
> is OK for them and inserts their assertion that it OK and hands down to 
> Cisco. Cisco looks for the AT&T assertion and since it one of the 
> carriers they trust, decides it is OK.
> phone numbers </bold>. This means that the PBX needs to require that the 
> identity it trusts to sign numbers is some it trusts - practically this 
> means the one or more carriers that it connects to. These carriers need 
> to have their SBC (or proxies if they used theses) insert an assertion 
> about if the number is OK or not.
> 
> consider any assertion from IBM that they are 555-1111 to be false. The 
> only person that knows there was a change was the namespace owner, 
> Sprint in this case.  The number could even be given to a different 
> carrier.  This solution is the best we can do given the constraints of 
> the namespace allocation process. We can do much better with the names 
> like sip:[email-masked] but that is a different topic.
> 
> media to the attacker and the strength of the security is limited by the 
> strength of how well you know who you are talking too. Here the DTLS 
> keying fingerprint strength is exactly tied to the identity strength. If 
> someone had some other way to knowing who they were talking too, such as 
> SAS codes if that worked, then you can use those too.
> 
> The high point I am trying to make here is that you always have to trust 
> whoever controls the namespace and for the case we are interested in 
> here for phonenumbers, that implies a certain trust of the carriers. 
> This in turn means that the Cisco  PBX in the example above needs to 
> reject the signature of a phone number from middle-domain.com.
> 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Nov 2007 08:38:03 +0000

Cullen,

I always thought that user@domain1 and user@domain2 are not equivalent -
each domain has its own namespace for the user part. I am not aware of
anywhere that says this is untrue also for phone numbers. I believe
[email-masked];user=phone and
[email-masked];user=phone are not equivalent. Also I
understand you cannot just take a SIP URI that includes a telephone
number and say that this is equivalent to a TEL URI.  I am not sure
where I got this understanding from, because it does not appear to be in
RFC 3261 - perhaps from an old email thread.

So if somebody submits a request to [email-masked];user=phone,
it should be routed to domain example1.com, which then will route it to
the user to which it has assigned this identifier. It has nothing to do
with whether domain example1.comn owns the E.164 number +123456789. On
the other hand, if somebody submits a request to TEL:+123456789, then
that should indeed be routed to whoever "owns" that E.164 number, which
may or may not be example.com.

If an originating domain asserts [email-masked];user=phone, and
that assertion is carried through any intermediate domains to the
destination domain, and if that assertion is backed up by cryptographic
means, then the terminating user can have confidence that the
originating user is in domain example1.com. If media is secured based on
this assertion, the user can be confident that media is secured to/from
a user in example.com. Receiving an assertion from mitm.net (even if
this is a carrier with which the terminating user or his/her
organisation has a contractual relationship), on the other hand, does
not give the terminating user any such confidence that he is talking to
someone in example1.com.

The fact that the request originates at a user in domain example1.com is
the important thing here - whether that domain "owns" E.164 number
+123456789 is unimportant. SIP identity makes no such claim, and such a
claim is not needed in order to obtain the media security properties we
are seeking.

Of course, if a UAS effectively converts such a SIP URI back to a TEL
URI and displays it just as an E.164 number, without displaying the
domain part, this is the root of the problem (as somebody remarked
earlier in this thread). It gives the called user the wrong information.

I thought the whole idea of the dtls-srtp work (and indeed the whole RAI
media security discussions) was to try to find a means of achieving near
end-to-end security for media. If we just blindly trust the next hop
domain, we might as well stick to something like SIPS + Sdescriptions.

John

> Sent: 25 November 2007 17:52
> To: IETF SIP List

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2007 07:54:28 -0500

John,

I agree with your analysis. And yet in many contexts there is a strong 
desire to display "phone numbers", because of custom and limitations of 
protocols and devices. So there is a tendency to coerce a sip URI into a 
phone number whenever it looks like that can be done.

I think these two views (your analysis and Cullen's) can coexist in 
certain environments. Specifically, a UA that receives a call with 
sip:[email-masked] as the caller identity can assume this is 
equivalent to TEL:+123456789 *if* it has an agreement with example.com 
that such an equivalence is true. This certainly isn't true in general, 
but may be true in some important cases, expecially when the domain 
belongs to a service provider.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Nov 2007 10:06:48 -0800

I should reply to whole thread but out of time right now .... agree  
with lost of what was said ...

On Nov 26, 2007, at 12:38 AM, Elwell, John wrote:

> each domain has its own namespace for the user part. I

Yes, agree with this. This does not however stop a domain from having  
a policy that user names that start with + are E.164 numbers (or some  
some similar policy such as names that start with a digit are dial  
strings of some sort). Now a domain that takes a E.164 number as a  
user name and goes to route that to another domain that it peers with  
needs to understand something about the policy of the next domain.  
Should it use a tel, should it use a sip uri and have a + in front of  
it, etc. But there is nothing wrong with domains having policy about  
how they map user names to telephone numbers and nothing wrong about  
them understanding the policies of other domains they peer with. I  
think all of this is very commonly done in deployed systems today.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Nov 2007 21:24:35 +0000

Cullen,

I agree, of course, that this is common practice.

John 

> Sent: 26 November 2007 18:07
> To: Elwell, John
> Cc: IETF SIP List

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2007 19:20:23 -0500

inline:

> phone number whenever it looks like that can be done.

Its more than a rendering problem. The identifier is meaningful for 
security because the person on the receiving end of the call can tie it 
to user - the one that they know has been assigned this identifier. And 
thus, they can be assured that, when they answer the phone, they know 
the user that is calling (let us put aside issues when someone else uses 
  my phone to make calls).

The root issue is that FUNDAMENTALLY, phone numbers are not scoped 
within a domain. For this reason, the mapping that exists in peoples 
heads from identifiers to users is of one of two forms:

"user@domain" --> some person
"1 (408) 902-5000" ---> some person

so, even if you user interface could render the fact that, the call was 
from sip:[email-masked], I believe that users would anyway 
ignore the domain part since there is no domain part for phone numbers.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2007 19:23:40 -0500

inline:

Hadriel Kaplan wrote:

> 
>> Now Identity gives us a way to realize all of this that protects
>> from attackers modifying things along the chain.  IBM signs and the
>> number as IBM and sends on to sprint. Sprint can use this to decide
>> if they believe this OK or not along with their policy information.
>> Now if sprint thinks it OK, they insert the assertion they think it
>> OK and hand to AT&T. AT&T looks at it and decides that it was OK
>> for sprint, then it is OK for them and inserts their assertion that
>> it OK and hands down to Cisco. Cisco looks for the AT&T assertion
>> and since it one of the carriers they trust, decides it is OK. 
>> <bold> As far as I can tell, anything other than this won't work
>> for phone numbers </bold>. This means that the PBX needs to require
>> that the identity it trusts to sign numbers is some it trusts - 
>> practically this means the one or more carriers that it connects
>> to. These carriers need to have their SBC (or proxies if they used 
> This already happens through P-Asserted.  What you describe is
> hop-by-hop trust of identity, so why would you believe a 4474 signed
> request by your trusted previous-hop any less than a P-Asserted claim
> from it?  And what's more, why would each hop bother with the
> overhead of 4474 if it can just use P-Asserted?  If Cisco was
> concerned with something between them and AT&T, or AT&T concerned
> with something between them and Sprint, or Sprint concerned with
> something between them and IBM, why wouldn't they just use SIP/TLS
> for those peer connections?  It's less overhead and provides better
> security for those connections than 4474.

I agree with Hadriel here. There is no point in RFC 4474 if anyway every 
hop is going to resign. Cullen - what value do you see in it over 3325?

My current view, unfortunately, is that, in environments that use phone 
numbers as identifiers, 4474 and DTLS-SRTP add no security whatsoever 
above their "weaker" cousins - 3325 and sdescriptions. If we all agree 
this is in fact true, that better be amazingly clear in documents we are 
producing. Since right now it isn't.

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Nov 2007 17:14:31 -0800

In one message, Jonathan Rosenberg wrote:

> My current view, unfortunately, is that, in environments that 
> use phone numbers as identifiers, 4474 and DTLS-SRTP add no 
> security whatsoever above their "weaker" cousins - 3325 and 
> sdescriptions. If we all agree this is in fact true, that 
> better be amazingly clear in documents we are 

This is not a defect or deficiency of DTLS-SRTP, as Eric 
pointed out.  Rather, it is a deficiency caused by SIP's
use of the E.164 namespace (which humans understand) in 
conjunction with domain names; mixing them doesn't work
well.  It comes down to the question:  are these 
equivalent:

  [email-masked]
  [email-masked]

In another message, Jonathan Rosenberg wrote:

> so, even if you user interface could render the fact that, 
> the call was from sip:[email-masked], I believe 
> that users would anyway ignore the domain part since there is 
> no domain part for phone numbers.

Right.  The problem is mixing E.164 namespace with SIP namespace.

But for SIP identity, we need to decide if an entity
that signed an E.164 is authorized, by our own domain's view
of 'authorized', to sign for it.

Cullen suggests that the RFC4474 Verifier have a list of 
domains that the Verifier will trust to sign any E.164.  That
is the best that can be done with RFC4474 by itself.  As you
stated, this allows that trusted entity to violate that
trust (insert their own a=fingerprint, and do their own
DTLS handshake).

As Paul and Francois suggested, using ENUM could provide a way
to determine if the signer was authorized to sign for a certain
E.164.  However, ENUM is not widely deployed and is mired in
non-technical issues.  Furthermore, even if the non-technical
issues were resolved, and we had ENUM available everywhere,
operators that use SBCs and use RFC4474 would have to re-sign
SIP requests, destroying the original signature in the process.
So ENUM is not a viable path (unless we also invent a way to
do end-to-end identity, along the lines of 
-wing-sip-identity-media).

Another approach that I have considered is a SIP return-
routability test.  This provides better flexibility and
does not require a priori configuration of policy for which
domains you trust to sign or to resign; of course, if you 
do trust  certain domains to resign certain things, you can 
short-cut this return-routability (because it will always 
return the same information you already have).  Thus, you 
can consider the SIP return-routability an additional 
enhancement for a SIP network where you don't already 
know which domains are going to send you Invites.

I have written this up, but it is still immature.  However,
there seems to be interest in this thanks to Jonathan's
good analysis of how RFC4474 and today's use of E.164 
collide to reduce the value of RFC4474 signatures (and,
thus, DTLS-SRTP that relies on RFC4474 signatures to
prevent active MitM attacks).

Please consider this a straw-man idea.

SIP E.164 Return Routability Test
---------------------------------

Introduction:

On today's Internet, many protocols have had to protect themselves from
malicious traffic with spoofed identites. As most IP protocols use IP
addresses as the identity, the protection has involved source IP address
verification using a cookie (TCP cookies, [PHOTURIS], [IKE]). SIP [RFC3261]
itself uses cookies, but only for its Digest authentication.

Overview of Operation:

Upon receipt of an INVITE where the From: address contains a SIP URI with an
E.164, a Verifier (as defined in RFC4474 and in SIP-Identity-Media) needs to
verify if the signer is authorized to sign for that domain. This verification
is done by sending an out of dialogue SIP message to that E.164, using the
Verifier's default SIP routing rules for routing an E.164 address. If this
routes to the same domain as the originating Invite, the cookie will be
returned.

To do this, the Verifier sends an out-of-dialogue SIP message to the identity
in the From: address, using the Verifier's normal SIP message routing. This
out-of-diaglogue SIP message is a SUBSCRIBE to an event that causes the
calling UA to send one NOTIFY. The SUBSCRIBE also contains a cookie. The
calling UA's NOTIFY contains the originating UA's DTLS fingerprint and the
SUBSCRIBE's cookie. Upon receiving the NOTIFY, the Verifier ensures
fingerprints in the NOTIFY and INVITE match, and then passes the INVITE to the
called UA. 

Following SIP-Identity-Media, the called UA performs a DTLS-SRTP handshake
with the calling UA, and via the DTLS-SRTP handshake the called UA proves
possession of the private key associated with its public key (and certificate
fingerprint). 

Message Flow:

Calling    Auth.     SBCs and               Called
  UA      Service     B2BUAs    Verifier      UA
-------   -------    --------   --------    ------
  |          |          |          |          |
  | Invite   |          |          |          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          | Invite   |          |          |
  |          |--------->| Invite   |          |
  |100       |          |--------->|          |
  |<---------|100       |          |          |
  |          |<---------|100       |          |
  |          |          |<---------|          |
  |          |          |          |          |
  |          |          |    (validates       |
  |          |          |     signature)      |
  |          |          |          |          |
  |          |          |Subscribe |          |
  |          |Subscribe |<---------|          |
  |Subscribe |<---------|          |          |
  |<---------|          |          |          |
  |          |          |          |          |
  |200 Ok    |          |          |          |
  |--------->|200 Ok    |          |          |
  |          |--------->|200 Ok    |          |
  |Notify    |          |--------->|          |
  |--------->|          |          |          |
  |          |          |          |          |
  |    (signs request)  |          |          |
  |          |          |          |          |
  |          |Notify    |          |          |
  |          |--------->|Notify    |          |
  |          |          |--------->|          |
  |          |          |          |          |
  |          |          |200 Ok    |          |
  |          |200 Ok    |<---------|          |
  |200 Ok    |<---------|          |          |
  |<---------|          |          |          |
  |          |          |     (a=fingerprint  |
  |          |          |       matches)      |
  |          |          |          |          |
  |          |          |          | Invite   |
  |          |          |          |--------->|
  |          |          |          |          |
  |          | DTLS-SRTP Handshake |          |
  |<=========...=======>|<==...==============>|
  |          |          |          |          |
  |          |          |          |     (handshake 
  |          |          |          |      successful)
  |          |          |          |          |
  |          |          |          |          |display e.164
  |          |          |          |          |------------>

-d

---

From: "Shakil Ahmed Network Advancement Technical" <[email-masked]>
Date: Tue, 27 Nov 2007 12:50:56 +0600

Hi all,

I have a question, might be very naïve for you guys. Is 'SIP E.164 Return Routability' a replacement technology for ENUM/DNS(E.164<>SIP URI)?

Regards,

Shakil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Tuesday, November 27, 2007 7:15 AM
To: 'Jonathan Rosenberg'
Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'; 'Elwell, John'
Subject: SIP E.164 Return Routability Test [was RE: [Sip] comments ondraft-ietf-sip-dtls-framework]

  [email-masked]

Introduction:

Overview of Operation:

Message Flow:

-d

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Nov 2007 07:28:04 +0000

The point is, when showing the padlock icon to say that a call's media
are secured, it needs to accompanied by a display of the domain to which
it has been verified to be secure. The same way that when I go to a
secure web site I can see the URL and, if I desire, view the
certificate. For SIP, this should be true whether the user-ID within
that domain is a phone number or not.

So if I make a call to somebody in example1.com, I would expect that to
be shown and not something like MitM.net.

John

> Sent: 27 November 2007 00:20
> To: Paul Kyzivat
> Cc: Cullen Jennings; IETF SIP List; Elwell, John
> the call was

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Nov 2007 08:05:14 +0000

Dan,

What prevents an intermediate domain saving a copy of the cookie and the
fingerprint and using them to construct the NOTIFY? For scenarios where
the return routing goes through an intermediate domain that the INVITE
came through, this would appear to eliminate the usefulness of this
technique. Perhaps the calling UA needs to sign something in the NOTIFY
to prove ownership of the private key whose certificate fingerprint has
been sent.

John

> From: Dan Wing [mailto:[email-masked]] 
> Sent: 27 November 2007 01:15
> To: 'Jonathan Rosenberg'
> Cc: 'Cullen Jennings'; 'IETF SIP List'; Elwell, John; 'Paul Kyzivat'
> Subject: SIP E.164 Return Routability Test [was RE: [Sip] 
> comments on draft-ietf-sip-dtls-framework]
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Nov 2007 00:29:38 -0800

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, November 27, 2007 12:05 AM
> To: Dan Wing; Jonathan Rosenberg
> Cc: Cullen Jennings; IETF SIP List; Paul Kyzivat
> Subject: RE: SIP E.164 Return Routability Test [was RE: [Sip] 
> comments ondraft-ietf-sip-dtls-framework]
> 
> Dan,
> 
> What prevents an intermediate domain saving a copy of the 
> cookie and the fingerprint and using them to construct the 
> NOTIFY?

I used a Notify is a SIP request, and would be signed (using 
RFC4474 or SIP-Identity-Media) by the originating domain.

-d

> For 
> scenarios where

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Nov 2007 10:45:56 +0000

Dan,

I am missing something here. Let me try to explain my concern.

Suppose I have an INVITE request from [email-masked], which
goes through domains example2.com and example3.com before arriving at
example4.com, where the signature (according to RFC 4474 or
draft-wing-sip-identity-media) is verified. Domain example2.com or
example3.com remembers information from the INVITE request (e.g., the
cookie, the certificate fingerprint). Domain example4.com issues a
SUBSCRIBE request, which let's assume gets routed through domain
example3.com or example2.com, which terminates the SUBSCRIBE request and
sends a NOTIFY request, using the saved cookie and fingerprint. In this
case, the verifier should see that the RFC 4474 or
draft-wing-sip-identity-media signature is from domain example2.com or
example3.com, i.e., a different domain from that of the original INVITE
request. On this basis the verifier could decide not to trust it.

But this still requires draft-wing-sip-identity-media, because with RFC
4474, if example2.com or example3.com resigns the original INVITE
request using +123456789@example2/3.com, the INVITE and NOTIFY requests
will still be signed by the same domain, so the verifier in example4.com
still has no evidence that the INVITE request originated in
example1.com.

John

> Sent: 27 November 2007 08:30
> To: Elwell, John; 'Jonathan Rosenberg'
> Cc: 'Cullen Jennings'; 'IETF SIP List'; 'Paul Kyzivat'

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Nov 2007 08:34:51 -0800

> Sent: Tuesday, November 27, 2007 2:46 AM

Right.  But, what the verifier in example4.com now knows is
that SIP routing towards that E.164 gets routed through
example2/3.  The verifier in example4.com knows and trusts
his own forward routing; the verifier in example4.com has
no idea how other SIP nodes are routing SIP messages towards
example4.com.

My strawman is akin to a TCP SYN cookie, and akin to the 
nonce in SIP's Digest authentication.  Neither my strawman,
nor TCP SYN cookies, nor SIP's Digest authentication nonce,
prove that you're really talking to the same source that
sent you the original message (SIP INVITE, TCP SYN,
SIP REGISTER).  Rather, they prove you have return routability
to an attacker (who now needs to be on the forward and 
reverse paths) or to the originating endpoint.

It's a strawman idea to provide additional identity; perhaps 
it has insufficient value for the problem at hand.  

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Nov 2007 11:08:34 -0800

> From: Shakil Ahmed Network Advancement Technical 
> [mailto:[email-masked]] 
> Sent: Monday, November 26, 2007 10:51 PM
> To: IETF SIP List
> commentsondraft-ietf-sip-dtls-framework]
> Importance: Low
> 
> Hi all,
> 
> I have a question, might be very naïve for you guys. Is 'SIP 
> E.164 Return Routability' a replacement technology for 
> ENUM/DNS(E.164<>SIP URI)?

No.  Keep in mind it is an immature idea.

The idea of return routability is that if you receive an Invite
with an E.164 of +1-202-456-1414 (which is the Whitehouse
switchboard), and it has a SIP From of:

  "From: [email-masked]"   (the Russian mafia)

you need a way to discern that is valid (or invalid) compared
to:

  "From: [email-masked]"

or

  "From: [email-masked]" (Verizon is the phone
                                       company for the Washington,
                                       DC area)
or

  "From: [email-masked]"  (your company's ITSP)

Right now, SIP has no way to determine which of those three is valid.

ENUM, if it were available, could help.  With ENUM, you could, 
in theory, look up the phone number and see if mafia.ru,
whitehouse.gov, or verizon.net were authorized to sign that
identity.  ENUM does not provide that functionality today, 
though.

The idea of SIP return routability is to generate a new SIP
request, using your domain's own default SIP routing rules,
and see if it goes to the same place as the just-arrived
INVITE.  

Using the example above where the INVITE is from mafia.ru, you 
would take the E.164 address (+1-202-456-1414) from the 
Invite and build a new SIP request (a SUBSCRIBE) -- like
"sip:[email-masked];user=phone" if att.net was your 
default ITSP.  This SUBSCRIBE would be routed, by att.net,
and eventually arrive at whitehouse.gov.  At whitehouse.gov, 
that SUBSCRIBE causes them to send one NOTIFY back to you.  
With SIP-Identity-Media, whitehouse.gov's signature is preserved 
and your Verifier would see that the SUBSCRIBE is signed by 
whitehouse.gov.  "whitehouse.gov" is different from "mafia.ru".
Your verifier now knows that mafia.ru is not authorized
to sign for that E.164, and rejects the INVITE.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Nov 2007 02:33:19 -0500

> Sent: Monday, November 26, 2007 8:15 PM
>
> non-technical issues.

ENUM is widely deployed, IMO, it's just not public ENUM. ;)

> know which domains are going to send you Invites.

Clever idea!  Sorta emulates what some people do for PSTN calls already (e.g., Bank calls you, and you call them at their public number to verify).  Or what web systems and mail-list servers do by sending an email with a cookie to verify new users.

But it demands symmetric origination+termination, which doesn't always happen.  For example, your call to me may well go through the PSTN before reaching me on SIP, but my Subscribe to you will go pure SIP - maybe due to least-cost routing, different route policies, etc.  So while your Invite-based call to me may come in "legitimately" as From: <sip:[email-masked]>, my Subscribe to sip:[email-masked] may be received/answered by cisco.com.  Even if there were a public ENUM DB this problem would happen.

Of course you could just take the username portion of the From and send a new Invite for a new dialog (maybe even with a Replaces header concept) out instead of Subscribe, and really emulate what people do on the PSTN... but I'm not advocating that. :)

-hadriel