Subject: [Sip] comments on draft-rosenberg-sip-rfc4474-concerns-00

From: [email-masked]
Date: Wed, 12 Mar 2008 13:13:38 -0700

Hi,

Obviously this I-D (and the other related ones [1]) are teasing apart an
important set of issues. And there's lots of subtle-but-important items
buried in all of this. I'm going to attempt to address some of the ones I
can see in draft-rosenberg-sip-rfc4474-concerns-00 in the hope of refining
our collective thinking, and terminology, wrt this class of issues. It's
unfortunately long, and doesn't offer any magic bullet solutions, but
hopefully worthwhile to peruse. The basic conclusion is that in reality
the issues noted in draft-rosenberg-sip-rfc4474-concerns-00 apply
essentially equally to any style of "user" part SIP URI.

=JeffH
------

quoting draft-rosenberg-sip-rfc4474-concerns-00:
>                                                ...most SIP deployments
>    at the time of writing make use of phone numbers, and not traditional
>    email-style user@domain identifiers.  Of course, a phone number does 
>    not have a domain part. 

But the latter is not strictly correct all the time -- e.g. see the email 
addresses in the headers of this message. Are they phone numbers or do
they just look like such?

Obviously, such portions of identifiers may or may not actually "be" what
they syntactically appear as, because there isn't a extant proper mapping
of them into operational services commonly associated with such syntax. 

It _is_, however, the case, in actual non-trivial deployments, that there
are identifiers used in the "local-part" of RFC2822 email addresses [2]
that _are_ exactly phone numbers -- e.g. AFAIK, every Sprint wireless
subscriber is assigned an email address of the form..

  [email-masked]

..and Verizon customers are assigned..

  [email-masked]

..and Cingular (now ATT) customers were assigned..

  [email-masked]

I assume that a non-trivial number of other carriers do similar things.
These  addresses presently are, in my experience, typically used to enable
bi-directional email<-->SMS gatewaying, but they _could_ also be used in
SIP URIs, e.g...

  sip:[email-masked];user=phone

..which would be a fairly reasonable thing to do, at least from an
objective technical perspective ;)

>    Consequently, the domain part of the SIP URI, when used in
>    conjunction with phone numbers, is not relevant to users in
>    establishing the identity associated with that number. 

I would update this to say..

    Consequently, the domain part of the SIP URI, when used in
    conjunction with phone numbers, is not necessarily relevant
    to users in establishing the identity associated with that
    number.

The term "necessarily" is important here, because the argument preceding
this claim in the document assumes only PSTN-style user equipment and
usage thereof. I nonminally agree that this dominates SIP-based VoIP usage
today (without really knowing in actuality), but I suspect the future is a
bit of an open question (at least in that we can perhaps kinda possibly
influence it).

>                                                      For email-
>    style identifiers, this is not true - the domain part is highly
>    relevant. 

I think, given the examples noted above, we should not use the ad-hoc
term "email-style identifier(s)" in our analysis of this class of issue,
because it is misleading. 

As illustrated above, the "local-part" (aka left-hand-side  (LHS)) of an
RFC2822 email address (aka "addr-spec" in RFC2822 [2]) can, and are 
reasonably often, comprised of numeric strings that can appear to 
syntactically be "phone numbers", and in some non-trivial number of cases
are actually such.

Rather, I think we should use a term(s) such as..

  natural-name-like identifiers

..and..

  phone-number-like identifiers ..or.. non-natural-name-like identifiers

..where the qualifier "-like" is important because one doesn't know for
sure, without checking with appropriate datastores or authorities or
whatever, whether those identifiers are in actuality what they resemble. 

>    Unfortunately, this problem is a FUNDAMENTAL PROPERTY OF PHONE
>    NUMBERS.  No specifications or efforts on the part of IETF can fix
>    this problem.  Phone numbers are fundamentally NOT scoped to a
>    domain, and attempts to represent them in any other form are
>    ultimately futile from an identification perspective.

This above set of claims are apparently predicated on prevalent user
equipment (UE), user agent user interface (UA UI), and user behavior as we
know it today. 

Continuing, in the "Re-Sign Attack" section of -rfc4474-concerns-00..

>    What happened here?  It is illustrative to look at this attack in the
>    case where Alice had used a user@domain identifier, for example,
>    [email-masked].  In this case, if the b.com transit domain had done the
>    same processing described above, the request would have arrived to
>    Bob's user agent.  The signature would be valid, and the domain of
>    the signer would match the domain in the From field.  However, the
>    identity shown to Bob would be "[email-masked]", which doesn't match
>    Alice's AOR as far as Bob knows.  Consequently, Bob will be alerted
>    to the fact that something is going on.

This all depends on how the UE/UA UI behaves, and how Bob behaves. He may
or may not "be alterted".

E.g. I personally would note the claimed natural-name-like identifier
whether or not any remaining identifier components are materialized to me,
and likely just figure it's just another natural-name-like-based
identifier my contact wields. 

I.e. I think the re-sign attack is an issue of some interest no matter how
the "user" part of the SIP URI in the From: header field is composed
whether it is a natural-name-like identifier or a non-natural-name-like
identifier. Also, that we should perhaps offer more "UI guidance" to
implementors (and yes, some std-track RFCs do say things like "such and
such SHOULD be materialized to the user...", if I recall correctly; but
yes, doing so is controversial).

-rfc4474-concerns-00 goes on to say, in the same section..

>        ...these man-in-the-middle attacks (when an email-style From
>    URI is being used) will be detectable for cases where the called
>    party knows the caller.

Being "detectable" doesn't necessarily depend upon the style of From: URI
in the case where the called party "knows" the caller, especially if the
called party has a UE/UA-accessible address book against which the UE/UA
checks incoming identifiers. 

But also, the caller may simply be wielding a newly-acquired SIP URI, e.g.
Alice acquired a new account in another domain but is wielding the same
"user" part identifier, e.g. "alice". And so, this observation..

>                          Even when the called party doesn't know the
>    caller, attemptes to return their calls would fail, ...

..isn't necessarily correct, because if Alice has simply acquired a new
account, with sytactically the same accout identifier, comm attempts back
to her will ostensibly succeed. 

So it seems to me that the following claim of..

>    Our conclusion is that, when email-style identifiers are used, RFC
>    4474 provides a reasonable degree of protection against re-signing
>    [...]. However, when phone numbers are used, RFC 4474 provides no 
>    protection against re-signing, and its message integrity is easily 
>    subject to MITM attacks.

..is not quite correct *overall* in that RFC4474 protections are largely
equivalent no matter what style of SIP URI "user" part identifier is
employed. 

All RFC4474 provides is a verifiable assertion of "caller identitifier
legitimacy" (and msg integrity), vouched for by the UAS/AuthnSvc, to the
next hop in the signaling chain, nothing more. That, I believe, is what
this para in RFC4474 that you cite essentially claims..

>      In the end analysis, the Identity and Identity-Info headers cannot
>      protect themselves.  Any attacker could remove these headers from a
>      SIP request, and modify the request arbitrarily afterwards.  However,
>      this mechanism is not intended to protect requests from men-in-the-
>      middle who interfere with SIP messages; it is intended only to
>      provide a way that SIP users can prove definitively that they are who
>      they claim to be.

..and it seems arguable that RFC4474 should state this more explicitly, at
least in the very last phrase.

In terms of the section "3.2.  The False Number Attack", it seems to me
that it is an issue no matter what style identifier is wielded by the
malicious provider, e.g. a.com. They could just as easily mount this
attack with either natural-name-like or a phone-number-like identifiers.
The attacks successfulness depends largely upon how the targeted UE/UA UI
behaves, and the goals of the attack. 

Wrt to the section "4.1.  Unsecure Caller ID for Phone Numbers", where it
says this..

>    The false number attack described in Section 3.2 means that RFC 4474
>    does not readily provide 'secure caller ID' for phone numbers.  The
>    definition of secure in this context is that the phone number present
>    in the From header field URI does in fact represent the number of the
>    party that originated the call.

..I think that "definition of secure" applies only to the extent the
UAS/AuthnSvc is trustworthy, regardless of the style of "user" part
identifier wielded. 

E.g. where, in "4.2.  Comparison with RFC3325" it says..

>              an attacker could not assert identity within
>    whitehouse.gov.

..and in section "4.3.  Interactions with DTLS-SRTP" it says..

>    When used with email identifiers, RFC 4474 provides a limited form of
>    message integrity protection against MITM attacks.  As discussed
>    above, this is because modified domains in From fields are likely to
>    be readily detected by end users, either right away or in the future.

..but a malicious domain "in the network" _could_ (potentially) assert
"@whiteh0use.gov", and its success will again depend essentially only upon
both the UE/UA and user behavior. So, again, it seems to me that the basic
analysis is independent of the style of "user" part identifier wielded. 

This point is acknowledged here..

>                                                             Indeed, it
>    won't be detectable even if they have an email-style identifier, if
>    the called party doesn't recognize that the caller's identity doesn't
>    match what their UA is showing to them.

And so, in "5.  Conclusions", where it says..

>    Unfortunately, there is no simple remedy to this problem.  The
>    problems with RFC4474 cannot just be fixed by an alternate security
>    technique.  They are deeply rooted in the domain independence of
>    phone numbers.

..I disagree with the last sentence. To a fair degree, the local-part of
RFC2822-style, and the "user" part of SIP URI, identifiers are
domain-independent. E.g. I wield "Jeff.Hodges", "=JeffH", etc. in more
than one domain, and could also wield my sprint phone number in a domain
that I own as either an email address and/or a SIP URI "user" name part.

To a large degree, the (non-trivial, important) issues highlighted in
-rfc4474-concerns-00 are predicated on UE/UA, and user, behavior. 

So, it seems that unless "we" (or someone) addresses security-critical
aspects of UE/UA UI behavior, we might want to think about yet another
security mechanism, one that is UA-to-UA and/or UAS-to-UAS. 

OR, perhaps in practice, we'll gravitate to some acceptable level of
transitive trust across SIP-based overlay networks in conjunction with
some set of white- and black- listing technology, as -rfc4474-concerns-00
notes. Much as spam is addressed in the email world, and solicitor calls
are handled in the present phone world. 

One for-what-it's-worth observation is that -- granted it depends on UE/UI
software capabilities and user proclivities (but the following is pretty
common AFAIK) -- many of us are already far along the path of having
personal UE/UA-based whitelists on our mobiles and softphones and email
UAs etc. 

-----------------------

[1]   Dan Wing said in 
<http://www.ietf.org/mail-archive/web/sip/current/msg22416.html>:

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

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

[2] from RFC2822, ABNF excerpts..

address         =       mailbox / group

mailbox         =       name-addr / addr-spec

addr-spec       =       local-part "@" domain

name-addr       =       [display-name] angle-addr

angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent        =       dtext / quoted-pair

dtext           =       NO-WS-CTL /     ; Non white space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-126        ;  characters not including "[",
                                        ;  "]", or "\"

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

atom            =       [CFWS] 1*atext [CFWS]

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

---
end

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2008 21:48:25 -0400

Hello [email-masked] (or is it just +11234567890?)

For now I will just call you +11234567890 since I don't have another 
name for you. :-)

I take a different spin on Jonathan's terminology. When he says "a phone 
number does not have a domain part" I think he is really talking about 
the phone *number* - that which is assigned to you by a traditional 
phone company, and which people commonly put on business cards and 
various other places.

Now, as you and others point out, it is fairly common to embed things 
that are, or look like, phone numbers in other kinds of addresses and 
URIs. The essence of the problem is knowing whether some set of digits, 
possibly preceded by a +, is a phone number in a given context.

Regarding whether people can, and should, interpret the "user part" of 
other forms of address (email, sip) without regard to the domain part - 
that is just stupid. You may reasonable assume that

	sip:[email-masked]
	mailto:[email-masked]
	[email-masked]

all refer to the same person, namely me. That may not always be true, 
but probably pretty close. OTOH I am quite certain that you may not 
assume that

	sip:[email-masked]
	mailto:[email-masked]
	[email-masked]

all refer to the same person. (Just picking Alan because he is a real 
person with a fairly common name.) These things are simply not scoped in 
such a way as to be unique without the domain name. So equipment that 
needs to identify users of such addresses MUST be prepared to display 
the full name, including the domain. Equipment that deals in phone 
numbers *does not* need to be prepared to display a domain name, and a 
dominant fraction of the phone devices in the world have no good way to 
do so.

If I get a call from sip:[email-masked] I may give a 
passing thought of "Could that be Alan? What the heck is he up to?", but 
mostly I will think it is probably somebody else. I certainly wouldn't 
want my device suppressing the domain.

Yet, if I normally get calls from:

	sip:[email-masked]

and then later get a call from

	sip:[email-masked]

then many people seem to think that only the number should be displayed.

	Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2008 15:36:54 +0200

Some of these aspects are in fact not a topic for SIP Identity.
Reason: SIP Identity leaves authorization open.

If I configure my authorization check procedure to look for +19785551234
then there has to be a way to assert that I am that particular identity. 
The concept of domain does obviously not matter here -- since there just 
is no domain.

SIP Identity may not be the appropriate mechanism todo so.

If I configure my authorization check procedure to look for

[email-masked]

then SIP identity may be able to help you.

If you distribute information about your identity that does not include 
a domain name or you happen to change your domain part without letting 
other people know then there is a problem.

Ciao
Hannes

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 09:40:19 -0400

> then many people seem to think that only the number should be displayed.

Actually, I think there is a subtle but critical correction to be made 
here. If I understand correctly, people want the two identifiers you 
cite to be considered different, and believe that the domain should be 
displayed.

However, if you change your example to 
"sip:[email-masked];user=phone" and 
"sip:[email-masked];user=phone", then I suspect your statement 
stands. And I'm not sure that treating these as the same entity is wrong 
-- there's an indication that the user portion is formatted in a 
specific, well-defined way that other parties are expected to be able to 
interpret according to well-defined rules (RFC 3966). Without 
"user=phone", that's not true.

/a

---

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

Adam,

I understand your point. But there are a lot of people who seem to think 
it is fine to take any user part that looks vaguely line a phone number 
and treat it as such.

It was my take that Mr(Ms) +11234567890 specifically feels that way.

My understanding is still that even 
"sip:[email-masked];user=phone" and 
"sip:[email-masked];user=phone" are *different* and should be 
announced as such. Certainly the routing rules are different for 
reaching the two of them, and that can be significant.

IMO if you want an address that can be displayed simply as a phone 
number, then you should use a TEL for it.

	Paul

---

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

On Mar 13, 2008, at 9:36 AM, Hannes Tschofenig wrote:

> +19785551234

Well, there might be. For example, I might be able to look into the  
ENUM database and find out what cert (by domain) is supposed to be  
used to sign requests for that E.164 number. Or, I might be configured  
with a bunch of certs, each of which lists as part of its attribute  
set a range of phone numbers that it can sign.

--
Dean

---

From: =JeffH <[email-masked]>
Date: Fri, 14 Mar 2008 02:46:50 -0700

> It was my take that Mr(Ms) +11234567890 ...

Note that I closed the initial portion of my message body with "=JeffH". But 
also note that it take clues/hints/traditions/conventions outside of the rules 
of the set of email RFCs to identify what might be the nominally socially 
correct "name" (note "names" are not always "identifiers") to use to refer to 
me. And you'll get different answers from different entities. (some would 
perhaps suggest "obnoxious" or something similar).  ;)

Anyway, from my perspective, either is fine for the purposes of this discussion.

Also note that I copied my message to "[email-masked]", which by 
the way, will indeed "reach" me via email, even though the "local-part" is 
indeed a valid +1 PSTN number, but not one I "control", beyond it's association 
(in this context) with kingsmountain.com. Hm, I may need to enable SIP-based 
comms for it....

Paul Kyzivat wrote in reply to Adam Roach::
 >
 >                         But there are a lot of people who seem to think

Actually, no, that is not what I was attempting to say.

Rather, what I was attempting to say is that..

   It is nominally not correct (for some definition of correct)
   to take a "user" part (aka "local-part" in RFC2822 parlance),
   from the "user@domain" sub-construct of the "SIP URI"
   construct defined in RFC4474, and interpret its real-world
   attributes, or attibutes it might have in another protocol context,
   outside of the current protocol context (i.e. SIP),
   unless hints/extraContext/whatever are also present in the
   latter protocol context -- regardless of the syntactic
   construction  of said "user" part.

I also agree with a converse of the above..

   It is nominally "a leap-of-faith" to take a "user" part
   (aka "local-part" in RFC2822 parlance), from the
   "user@domain" sub-construct of the "SIP URI" construct
   defined in RFC4474, and interpret its real-world
   attributes, or attibutes it might have in another protocol
   context,  outside of the current protocol context (i.e.
   SIP) -- regardless of the syntactic construction  of said
   "user" part -- unless, hints/extraContext/whatever are
   also present in the latter protocol context.

Paul Kyzivat went on to say:
 > "sip:[email-masked];user=phone"
 >
 > are *different* and should be

There was sentiment in the room here @Philly/IETF-71 yesterday morning, that 
the "user" part of those two above identifiers SHOULD be treated by UAC/UA/UE 
as the "same", and that various present SIP RFCs at least imply such (I don't 
know myself, need to research it), though it is not currently consistently 
implemented that way.

 > number, then you should use a TEL for it.

Sure, for header fields such as To and Request-URI, but the issue here is what 
to assert in the From header field such that one can sign it (and other SIP msg 
components) and have some sort of linkage back to a trust anchor.

=JeffH
aka [email-masked]

ps: I didn't send my original message from my actual @messaging.sprintpcs.com 
email address for two reasons..

1. I didn't want that email address and phone number published on the web in 
email archives.

2. I didn't want to receive the SIP mailing list as SMS messages on my 
PDA/phone (scary).

---
end