Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

From: [email-masked]
Date: Fri, 20 Jun 2014 06:21:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Telephone Identity Revisited Working Group of the IETF.

        Title           : Authenticated Identity Management in the Session Initiation Protocol (SIP)
        Authors         : Jon Peterson
                          Cullen Jennings
                          Eric Rescorla
	Filename        : draft-ietf-stir-rfc4474bis-00.txt
	Pages           : 33
	Date            : 2014-06-19

Abstract:
   The baseline security mechanisms in the Session Initiation Protocol
   (SIP) are inadequate for cryptographically assuring the identity of
   the end users that originate SIP requests, especially in an
   interdomain context.  This document defines a mechanism for securely
   identifying originators of SIP requests.  It does so by defining new
   SIP header fields for conveying a signature used for validating the
   identity, and for conveying a reference to the credentials of the
   signer.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jun 2014 11:11:11 -0400

It's good to see this published! I have a few comments:

Section 4.3:

I find this section incomprehensible. What is it trying to tell me?

It starts out saying:

    The recipient of a request must compare
    that value to their own identity in order to determine whether or not
    the identity information in this call might have been replayed.

Must it? This doesn't seem to be normative, and I didn't find anything 
else saying this.

The point seems to be that response identity is hard and is not covered 
by this draft. If so, then the section title should be changed, and the 
section should explicitly state that is what it is trying to say.

Section 6.1:

    To address this problem, the authentication service and verification
    service both must perform the following canonicalization procedure on
    any SIP URI they inspect which contains a wholly numeric user part.
    Note that the same procedures are followed for creating the canonical
    form of URIs found in both the From and To header field values.

Based on the other text, I don't think the above really means "wholly 
numeric". It at least seems to include a leading "+". Perhaps the 
following better states what is intended:

    To address this problem, the authentication service and verification
    service both must perform the following canonicalization procedure on
    any SIP URI to which it applies.
    Note that the same procedures are followed for creating the canonical
    form of URIs found in both the From and To header field values.

Later in this section:

    The ABNF of this number string is:

          tn-spec = *DIGIT

I suspect you probably really want

          tn-spec = 1*DIGIT

Section 7:

    digest-string = addr-spec / tn-spec "|" addr-spec / tn-spec "|"
           Method "|" SIP-date "|" [ signed-identity-reliance-digest ]

The above has some precedence issues, and needs some parentheses:

    digest-string = (addr-spec / tn-spec) "|" (addr-spec / tn-spec) "|"
           Method "|" SIP-date "|" [ signed-identity-reliance-digest ]

Or perhaps this would be clearer:

    source-identity = addr-spec / tn-spec
    target-identity = addr-spec / tn-spec
    digest-string = source-identity "|" target-identity "|"
           Method "|" SIP-date "|" [ signed-identity-reliance-digest ]

That's it.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 Jun 2014 16:29:04 +0000

Hi Paul,

>Must it? This doesn't seem to be normative, and I didn't find anything

This is actually making a very simple, almost trite statement: if you
receive a request, you should inspect it to make sure it is to
"[email-masked]" and not to "[email-masked]," because someone could
just capture a request to Derek and replay it to you in order to
impersonate the sender of that message. It's telling you to pay attention
to the To, but, due to retargeting of various kinds, this gets
complicated. This section exists to explain that complication.

>section should explicitly state that is what it is trying to say.

This draft is not trying to address response identity in any way.

The major changes that were made in this draft are largely to Section 6.1:
this has some new text that we're going to need to talk about I'm sure.

>following better states what is intended:

No, the intention is that you strip the '+' for canonicalization.
"Implementations MUST drop any leading +'s" is two paragraphs down.

>I suspect you probably really want

Oh, well, yes, that's true.

>           Method "|" SIP-date "|" [ signed-identity-reliance-digest ]

Sure, that is clearer. This was legacy text imported from RFC4474, but we
should fix it here.

Thanks!

Jon Peterson
Neustar, Inc.

>That's it.
>
>	Thanks,
>	Paul
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/li
>stinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B
>31F1WQyjSQmLQXwHuHE%3D%0A&m=ChG48g2XuFFNBy%2F18bJyzEhIHdICB3IHnrFZJTtotCE%
>3D%0A&s=d0ac8746ea772795a2d7d1b8f83e221e6d3c45d69a6d7f096521e495983ad112

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jun 2014 10:00:59 -0500

On 6/20/14, 11:29 AM, Peterson, Jon wrote:
<trim/>
> The major changes that were made in this draft are largely to Section 
> 6.1: this has some new text that we're going to need to talk about I'm 
> sure.

All -

The new text in 6.1 that Jon's pointing to is copied below. Please 
review and comment at your earliest convenience.
If you think this is doesn't need any changes beyond what Paul and Jon 
have already discussed, please make that
comment on list.

------

       First, implementations must assess if the user-portion of the URI
       constitutes a telephone number.  In some environments, numbers
       will be explicitly labeled by the use of TEL URIs or the
       'user=phone' parameter, or implicitly by the presence of the '+'
       indicator at the start of the user-portion.  Absent these
       indications, if there are numbers present in the user-portion,
       implementations may also detect that the user-portion of the URI
       contains a telephone number by determining whether or not those
       numbers would be dialable or routable in the local environment --
       bearing in mind that the telephone number may be a valid E.164
       number, a nationally-specific number, or even a private branch
       exchange number.

       Once an implementation has identified a telephone number, it must
       construct a number string.  Implemenations MUST drop any leading
       +'s, any internal dashes, parentheses or other non-numeric
       characters.  This MUST result in an ASCII string of only digits
       without whitespace or visual-separators.

       Next, an implementation must assess if the number string is a
       valid, globally-routable number with a leading country code.  If
       not, implementations SHOULD convert the number into E.164 format,
       adding a country code if necessary.  This may involve transforming
       the number from a dial string (see RFC3966 [RFC3966]), removing
       dialing prefixes (e.g., a leading '011') or performing similar
       procedures.  It is only the case that an implementation cannot
       determine how to convert the number to a globally-routable format
       that this step may be skipped.

       In some cases, further transformations MAY be made in accordance
       with specific policies used within the local domain.  For example,
       one domain may only use local number formatting and need to
       convert all To/From user portions to E.164 by prepending country-
       code and region code digits; another domain might prefix usernames
       with trunk- routing codes and need to remove the prefix.

       The resulting canonical number string will be used as input to the
       hash calculation during signing and verifying process.

          tn-spec = *DIGIT

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jun 2014 10:03:59 -0500

> Sure, that is clearer. This was legacy text imported from RFC4474, but we
Agreed.

I would also like to see other cleanup/clarification work on the legacy
text as we go along, but am waiting to focus on that until we have the
primary technical work essentially ready.

RjS

---

From: <[email-masked]>
Date: Tue, 24 Jun 2014 15:54:30 +0000

Jon,

A couple of comments on this particular section. 

> Implemenations MUST drop any leading +'s

Implementations

> removing dialing prefixes (e.g., a leading '011')

Maybe something like "(eg a leading national or international prefix)" would be better - if you "remove a leading 011" in a number of numbering plans outside the NANP you'd get rid of the area code, or portion thereof... 

> It is only the case that an implementation cannot determine how 
> to convert the number to a globally-routable format that this step may be skipped.

The intent of the last sentence of the section isn't quite clear to me. I read this as meaning "This step may be skipped only if the implementation cannot determine how to convert the number to a globally-routable format." but then it would seem like stating the obvious; I must be missing something.

> signing and verifying process
Being picky: maybe you want to say "processes" here, I believe they're distinct. 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Tuesday, June 24, 2014 5:01 PM
To: [email-masked]
Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

On 6/20/14, 11:29 AM, Peterson, Jon wrote:
<trim/>
The major changes that were made in this draft are largely to Section 6.1: this has some new text that we're going to need to talk about I'm sure.

All - 

The new text in 6.1 that Jon's pointing to is copied below. Please review and comment at your earliest convenience.
If you think this is doesn't need any changes beyond what Paul and Jon have already discussed, please make that
comment on list.

------

         tn-spec = *DIGIT

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2014 13:14:42 -0400

> complicated. This section exists to explain that complication.

OK. That wasn't clear to me. But from a practical perspective, what are 
you suggesting be done? Does this imply that the UAS should display the 
To-URI together with the callerid? Or that the callerid should be 
displayed with an indication of lower confidence in this case? Or that 
the UAS should alert differently when the To-URI is "wrong" than it does 
when it is "right"?

I see no good answers that don't increase the complexity of the user 
experience.

I'd like to see more about this.

> This draft is not trying to address response identity in any way.

I thought it was at least touching on that because of:

    Moreover, the value in the To header field of a dialog-forming
    request is used as the From header field of requests sent in the
    backwards direction during the dialog, and is accordingly the header
    that would be signed by an authentication service for requests sent
    in the backwards direction.  But in retargeting cases, if the URI in
    the From header does not identify the sender of the request in the
    backwards direction, then clearly it would be inappropriate to
    provide an Identity signature over that From header.  As specified
    above, if the authentication service is not responsible for the
    domain in the From header field of the request, it MUST NOT add an
    Identity header to the request, and it should process/forward the
    request normally.

And IIUC that statement is actually *wrong*. The retargeted user could 
never get a request in the reverse direction signed with that From URI. 
RFC 4916 tackled that, and results in switching to, and signing, the 
proper URI for the called UA.

And the rest of the section also seems to be about connected/response 
identity and is unrelated to the subject of the section. I'm not sure it 
needs to be anywhere in this draft, but if so, then in a different section.

> "Implementations MUST drop any leading +'s" is two paragraphs down.

Yes, I understand that. My point was about how you determine if the 
original URI is a candidate for canonicalization as a telephone number. 
You say to inspect any URI which contains a wholly numeric user part. 
But certainly incoming URIs starting with "+" (which are *not* wholly 
numeric) also must be considered. Probably anything that matches a tel 
global-number should be, as well as anything that is wholly numeric.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Jun 2014 19:13:12 +0000

It isn't quite clear whether this section (6 in general) refers to "From" URIs or also potentially other number-like elements that could be part of the signature (e.g., To). If the latter, the syntactic range of numbers may be larger. For example, there are mobile-specific numbers like '#911' for reporting accidents, i.e., strings containing things other than tn-spec (*DIGIT). I'm guessing that this is only about the originating identity, but a clarification would help since "identities" seems to be used in both senses. (Example: "The recipient of a request must compare that value to their own identity in order to determine whether or not the identity information in this call might have been replayed.")

From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Tuesday, June 24, 2014 11:01 AM
To: [email-masked]
Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

All -

------

      exchange number.

         tn-spec = *DIGIT

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 Jun 2014 14:37:37 +0000

Thanks for these notes, I'll get these clarified. The reason why we have a sentence about skipping the step of rendering the number as globally routable is that it follows a SHOULD, and you typically in a SHOULD want to illustrate the circumstances in which you may do otherwise. I could probably couple those more tightly.

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Jun 24, 2014, at 5:00 PM, "[email-masked]" <[email-masked]> wrote:
> 
> Jon,
> 
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=Cbs%2Bu7I%2F8M1c7ujXL1r%2Ba3mXIqExLHEIFqTrg0rje1o%3D%0A&s=00de95c50f09988c39c6ef5daff02c44ba6094bbe1955080639c6f5abb94dab4

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 Jun 2014 15:02:00 +0000

Yeah, this stuff is not straightforward.

When we wrote RFC4474, we didn't think it was our business to specify the user interface when dubious events arose - we assumed our responsibilities ended with providing a set of tools in the signaling that could trigger UI as implementers and users thought appropriate. If you receive a SIP request that was To someone else and somehow forwarded to you, I do think that is potentially important information to render to the user, actually. I can imagine deciding whether or not to answer a call based on that information. I can even imagine that being useful without Identity. In a scoring system for identity, I can imagine that lowering confidence. But again, at least in how we originally saw our mandate, prescribing a UI was not in scope.

And we need to be careful to distinguish response identity (which to me means signing SIP response messages) and various forms of connected identity. Response identity is definitely out of scope - as I think is any mechanism intended to notify the caller of what number was reached, though Elwell-style workarounds could be implemented on top of these systems. But certainly the scope of RFC4474 did include protecting against a forged BYE request sent to tear down a dialog. That is why there are protections for requests sent in the backwards direction. Now this here is legacy RFC4474 text, and the number 4474 is less than 4916, so there may very well be fixes we need to get the language about From and To right. Be happy to work with you on that.

I will clarify that you do look at a leading + as an indicator to ascertain whether or not the numbers in a user-portion are a likely telephone number.

Thanks!

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Jun 24, 2014, at 6:14 PM, "Paul Kyzivat" <[email-masked]> wrote:
> 
> OK. That wasn't clear to me. But from a practical perspective, what are you suggesting be done? Does this imply that the UAS should display the To-URI together with the callerid? Or that the callerid should be displayed with an indication of lower confidence in this case? Or that the UAS should alert differently when the To-URI is "wrong" than it does when it is "right"?
> 
> I see no good answers that don't increase the complexity of the user experience.
> 
> And IIUC that statement is actually *wrong*. The retargeted user could never get a request in the reverse direction signed with that From URI. RFC 4916 tackled that, and results in switching to, and signing, the proper URI for the called UA.
> 
> And the rest of the section also seems to be about connected/response identity and is unrelated to the subject of the section. I'm not sure it needs to be anywhere in this draft, but if so, then in a different section.
> 
> Yes, I understand that. My point was about how you determine if the original URI is a candidate for canonicalization as a telephone number. You say to inspect any URI which contains a wholly numeric user part. But certainly incoming URIs starting with "+" (which are *not* wholly numeric) also must be considered. Probably anything that matches a tel global-number should be, as well as anything that is wholly numeric.
> 
>    Thanks,
>    Paul
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 Jun 2014 15:08:53 +0000

The last sentence of the first paragraph in the section excerpted below is intended to clarify that this guidance applies to both the To and From, and that is indeed one reason why we need to accommodate nationally-specific numbers and various related codes. I wonder if the various # codes are in fact dial strings though - I mean, no one is calling #69, that dial string is converted into a routable number by the back end systems. There may still be legacy systems that use the old military ABCD DTMF codes, or other things that fall outside the ABNF of DIGIT too.

But yes, if there are cases we care about that go beyond DIGIT, we need to fix this ABNF.

Jon Peterson
Neustar, Inc.

On Jun 24, 2014, at 8:57 PM, "Henning Schulzrinne" <[email-masked]<mailto:[email-masked]>> wrote:

It isn’t quite clear whether this section (6 in general) refers to “From” URIs or also potentially other number-like elements that could be part of the signature (e.g., To). If the latter, the syntactic range of numbers may be larger. For example, there are mobile-specific numbers like ‘#911’ for reporting accidents, i.e., strings containing things other than tn-spec (*DIGIT). I’m guessing that this is only about the originating identity, but a clarification would help since “identities” seems to be used in both senses. (Example: “The recipient of a request must compare that value to their own identity in order to determine whether or not the identity information in this call might have been replayed.”)

From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Tuesday, June 24, 2014 11:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

All -

------

      exchange number.

         tn-spec = *DIGIT

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=BZXq7FK4v9fzE3OW3Ql3NqPKdObzR%2BXuoTmk0oT9pt0%3D%0A&s=6ad49db3cbcf849b16bc33c5752b32f435955b1abf6a7a007bffbdf1ab173cac

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Jun 2014 15:42:28 +0000

Not a major issue, but I suspect that even after conversion to a "real" number, the To may well keep the *911 or similar, even if the request URI is rewritten. I see little downside to allowing the full range of DTMF characters in the grammar, including the A-D codes you mention.

From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, June 25, 2014 11:09 AM
To: Henning Schulzrinne
Cc: Robert Sparks; [email-masked]
Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

Jon Peterson
Neustar, Inc.

All -

------

      exchange number.

         tn-spec = *DIGIT

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jun 2014 12:08:08 -0400

> When we wrote RFC4474, we didn't think it was our business to specify the user interface when dubious events arose - we assumed our responsibilities ended with providing a set of tools in the signa…

I understand that. And yet, STIR is intended to be a very pragmatic 
exercise. If many/most plausible deployments won't be able to give 
special treatment to unexpected To-URIs then it makes little sense to 
define a mechanism that requires doing so.

OTOH, if we really intend that UIs will be expected to do something, 
then we ought to come up some suggestions about how. Perhaps this is the 
wrong document for it, but then we should look for another document that 
is the right place.

> And we need to be careful to distinguish response identity (which to me means signing SIP response messages) and various forms of connected identity. Response identity is definitely out of scope -

I thought you had concluded that response identity was impossible.

> as I think is any mechanism intended to notify the caller of what number was reached, though Elwell-style workarounds could be implemented on top of these systems. But certainly the scope of RFC4474 did include protecting against a forged BYE request sent to tear down a dialog. That is why there are protections for requests sent in the backwards direction. Now this here is legacy RFC4474 text, and the number 4474 is less than 4916, so there may very well be fixes we need to get the language about From and To right.

Perhaps we also need a 4916bis, or expand this document to encompass both.

> Be happy to work with you on that.

Sure. My first suggestion is to split this section into two - separating 
out the response/connected identity.

> I will clarify that you do look at a leading + as an indicator to ascertain whether or not the numbers in a user-portion are a likely telephone number.

ok. And henning has had more to say on this.

	Thanks,
	Paul