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 PROTECTED] 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 [EMAIL PROTECTED] (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 PROTECTED] > mailto:[EMAIL PROTECTED] > [EMAIL PROTECTED] > > 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 PROTECTED] > mailto:[EMAIL PROTECTED] > [EMAIL PROTECTED] > > 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 PROTECTED] 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 PROTECTED] > > and then later get a call from > > sip:[EMAIL PROTECTED] > > then many people seem to think that only the number should be displayed. > > Paul > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 PROTECTED] >> >> ..and Verizon customers are assigned.. >> >> [EMAIL PROTECTED] >> >> ..and Cingular (now ATT) customers were assigned.. >> >> [EMAIL PROTECTED] >> >> >> 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 PROTECTED];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 [EMAIL PROTECTED] identifier, for example, >>> [EMAIL PROTECTED] 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 PROTECTED]", 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 PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
