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

[[e-mail]]

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