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

[Hannes Tschofenig <[e-mail]>]

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 [phone]
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

[e-mail]

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




 Paul Kyzivat wrote:
> 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
>   

_______________________________________________
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