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

[Paul Kyzivat <[e-mail]>]

Hello [e-mail] (or is it just [phone]?)

For now I will just call you [phone] 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:[e-mail]
	mailto:[e-mail]
	[e-mail]

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:[e-mail]
	mailto:[e-mail]
	[e-mail]

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:[e-mail] 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:[e-mail]

and then later get a call from

	sip:[e-mail]

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

	Paul

[e-mail] wrote:
> 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..
> 
>   [e-mail]
> 
> ..and Verizon customers are assigned..
> 
>   [e-mail]
> 
> ..and Cingular (now ATT) customers were assigned..
> 
>   [e-mail]
> 
> 
> 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:[e-mail];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,
>>    [e-mail].  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 "[e-mail]", 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip