Subject: [stir] Revised charter text for STIR

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jun 2013 07:40:22 -0700

Folks,

Based on the apparent trend on the list to favor a narrower working 
group charter, as well as the rest of what has been discussed on the 
list, here is revised draft charter text to consider.

It focuses on specification of an authorization validation method and a 
method for getting the information needed to perform validation.  The 
example of the first is signature in an identity field.  The example of 
the latter is a query to an external database, to get keys, credentials 
or the like.  But the language is intentionally non-technical, in order 
to leave the technical choices to the working group.  Hence, for 
example, it does not attempt to resolve the choice between "credential" 
or "public key", nor HTTP vs. DNS.

It removes details that are not essential to the work and that might 
invite irrelevant debate.

The first paragraph is designed to stand alone as a summary abstract; 
this is actually a formal requirement for charter text, since the first 
paragraph is what's circulated in announcements.

d/

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: TBD (Barnes)

Mailing list: https://www.ietf.org/mailman/listinfo/stir
To Subscribe: --

As with email, the claimed source identity of a SIP request (in the From
field) is not verified. As with email, this permits and produces
unauthorized use of source identities as part of deceptive and coercive
activities, such as bulk unsolicited commercial communications,
voicemail hacking, and impersonating banks. The current effort will
specify a mechanism to support validation that a telephone number's
presence in the SIP From field is authorized by the entity formally
assigned use of that number, or by their delegate. The mechanism will
support end-to-end SIP interactions. Initial specification will be in
terms of a pure-SIP exchange, which will serve as the operational base.
Additional mechanisms might later be developed to support more
complicated mediation scenarios.

The working group will consider choices for the method of specifying
authorization information and the means of obtaining the parametric
information needed to perform that authorization check. An example of
the first could be use of a cryptographically-protected field carried by
SIP and containing identity and authentication information. An example
of the second could be a mechanism for querying an external database, to
obtain the key-signing parameters for the authentication cryptography.

A number of previous efforts have attacked the problem of securing the
origins of SIP communications, including RFC3325, RFC4474 and the VIPR
working group. To date, however, true validation of the source of SIP
calls has not seen any appreciable deployment. While several factors
contributed to this lack of success, culprits included: failure of the
problem to be seen as critical at the time; lack of any real means of
asserting authority over telephone numbers on the Internet; misalignment
of the mechanisms proposed by RFC4474 with the complex deployment
environment that has emerged for SIP; and inherent operational problems
with a transitive trust model.

Input to working group discussions shall include:

    Private Extensions to the Session Initiation Protocol (SIP)
    for Asserted Identity within Trusted Networks
    RFC 3325

    Enhancements for Authenticated Identity Management in the
    Session Initiation Protocol (SIP)
    RFC 4474

    Secure Call Origin Identification
    http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00

    Secure Origin Identification: Problem Statement, Requirements,
    and Roadmap
    http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00

    Authenticated Identity Management in the Session Initiation
    Protocol (SIP)
    http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00

A likely approach for SIP-based authorization validation is to include a
new capability for Identity assertions to cover telephone numbers,
rather than domain names. To conform with realistic deployments.

The working group will coordinate with the security area, for any
proposal details that utilize classic security mechanisms, such as
cryptography and certificate credentials.

The working group will coordinate with RAI area groups studying the
problem of signaling through existing deployments, including activities
in the INSIPID and STRAW working groups.

Identity is closely linked to privacy, and frequently one comes at the
cost of the other. To the extent feasible the working group will favor
privacy-friendly choices that minimize call information leakage to third
parties.

The working group will deliver the following:

- Problem statement detailing the deployment environment and
   difficulties motivating work on secure origins

- Specification of an authorization validation method for the source
   telephone number identity of a SIP request (in the From
   field)

- Specification of the means for obtaining security-related parametric
   information, used to perform source telephone number identity
   authorization validation.

Milestones

Sep 2013   Submit problem statement for Info
Dec 2013   Submit STIR authorization validation method for PS
Mar 2013   Submit STIR parametric information draft for PS

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 12:50:57 -0400

I like this charter much more - I think it avoids the contentious aspects that could drag down the BOF, while at the same time narrows the scope of initial work to do.

I have one nit-pick though: I don't think it should list/mention the individual drafts as "input" to the WG.  Listing the RFCs makes sense, but the individual drafts are just individual drafts, and there are a lot more that have been submitted over the years that we could dredge up as input.  Is it meant as just a reading list type thing for background?  Do we put that in charters typically?

-hadriel

On Jun 27, 2013, at 10:40 AM, Dave Crocker <[email-masked]> wrote:

> Folks,
> 
> Based on the apparent trend on the list to favor a narrower working group charter, as well as the rest of what has been discussed on the list, here is revised draft charter text to consider.
> 
> It focuses on specification of an authorization validation method and a method for getting the information needed to perform validation.  The example of the first is signature in an identity field.  The example of the latter is a query to an external database, to get keys, credentials or the like.  But the language is intentionally non-technical, in order to leave the technical choices to the working group.  Hence, for example, it does not attempt to resolve the choice between "credential" or "public key", nor HTTP vs. DNS.
> 
> It removes details that are not essential to the work and that might invite irrelevant debate.
> 
> The first paragraph is designed to stand alone as a summary abstract; this is actually a formal requirement for charter text, since the first paragraph is what's circulated in announcements.
> 
> 
> d/
> 
> 
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Adam Uzelac <[email-masked]>
Date: Thu, 27 Jun 2013 13:48:23 -0400

I have to agree with Hadriel that listing the drafts probably isn't a good
idea.  You're bound to leave some out (I am thinking of
draft-kuthan-sip-derive - which has merit, but that's not the point, so
ignore).

Also - fwiw, I think the timing of this is effort is better this time
around.

-Adam

On Thu, Jun 27, 2013 at 12:50 PM, Hadriel Kaplan
<[email-masked]>wrote:

>
> I like this charter much more - I think it avoids the contentious aspects
> that could drag down the BOF, while at the same time narrows the scope of
> initial work to do.
>
> I have one nit-pick though: I don't think it should list/mention the
> individual drafts as "input" to the WG.  Listing the RFCs makes sense, but
> the individual drafts are just individual drafts, and there are a lot more
> that have been submitted over the years that we could dredge up as input.
>  Is it meant as just a reading list type thing for background?  Do we put
> that in charters typically?
>
> -hadriel
>
>
> group charter, as well as the rest of what has been discussed on the list,
> here is revised draft charter text to consider.
> >
> example of the first is signature in an identity field.  The example of the
> latter is a query to an external database, to get keys, credentials or the
> like.  But the language is intentionally non-technical, in order to leave
> the technical choices to the working group.  Hence, for example, it does
> not attempt to resolve the choice between "credential" or "public key", nor
> HTTP vs. DNS.
> >

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Jun 2013 17:48:44 +0000

The "input" drafts wouldn't be listed in a charter I don't think, but for
a BoF it is common to include them in the announcement. Some of them will
probably be iterated before I-D cut-off, so I might refer to their tracker
page rather than the -00s directly.

I think this version of the charter generally is a crisp and appropriately
narrow description of the in-band problem. Setting aside the question of
whether that is the best scope to choose, a few places off the bat I'd
have concerns:

- The potential interpretation of "the entity formally assigned use of
that number." That can be read in a number of ways, some of which will
close doors that need to remain open, I think. There are multiple
assignments that take place, from the ITU-T down to national regulators,
from regulators to carriers, from carriers to end users, with various
resellers and enterprises stuck in the middle. Is one of these assignments
formal and the others not, or are all of them potentially in play? To
leave open possibilities, I might gloss over this with "an entity assigned
use of the number."

- The deliverable for "the means of obtaining security-related parametric
information." The literal means of obtaining keys/credentials, I think,
are in the scope of the authorization validation method deliverable - for
RFC4474, for example, this was the Identity-Info header and the URI
schemes it described. You certainly can't do authorization validation
without that means. I could read this deliverable as if it's suggesting
that header or mechanism should be in a separate document. The original
charter had "key management" as a separate deliverable, which is a
slightly different scope.

- The charter should be clear that we intend to obsolete RFC4474 and
replace it with something, regardless of whether or not that happens to be
one of our current input drafts.

Jon Peterson
Neustar, Inc.

On 6/27/13 9:50 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>individual drafts as "input" to the WG.  Listing the RFCs makes sense,
>but the individual drafts are just individual drafts, and there are a lot
>more that have been submitted over the years that we could dredge up as
>input.  Is it meant as just a reading list type thing for background?  Do
>we put that in charters typically?
>
>-hadriel
>
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 27 Jun 2013 14:05:39 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Thursday, June 27, 2013 1:49 PM
To: Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Revised charter text for STIR

The "input" drafts wouldn't be listed in a charter I don't think, but for a
BoF it is common to include them in the announcement. Some of them will
probably be iterated before I-D cut-off, so I might refer to their tracker
page rather than the -00s directly.

I think this version of the charter generally is a crisp and appropriately
narrow description of the in-band problem. Setting aside the question of
whether that is the best scope to choose, a few places off the bat I'd have
concerns:

- The potential interpretation of "the entity formally assigned use of that
number." That can be read in a number of ways, some of which will close
doors that need to remain open, I think. There are multiple assignments that
take place, from the ITU-T down to national regulators, from regulators to
carriers, from carriers to end users, with various resellers and enterprises
stuck in the middle. Is one of these assignments formal and the others not,
or are all of them potentially in play? To leave open possibilities, I might
gloss over this with "an entity assigned use of the number."

[RS> ] 
[RS> ]  Speaking of ITU ..did you all see this ..note internally the
reference to phone numbers etc.  Richard Hill was the Counselor to ITU-T 

	Title           : "Non Accession to the ITRs Considered Harmful"
	Author(s)       : Richard Hill
	Filename        : draft-hill-itr-non-accession-harmful-00.txt
	Pages           : 10
	Date            : 2013-06-25

Abstract:
  One of the treaties administered by the International
  Telecommunications Union is the International Telecommunications
  Regulations (ITRs), whose purpose is to promote the development of
  telecommunication services.  The 1988 version of the ITRs opened the
  way for privatisation, liberalization, and the growth of the Internet
  and mobile networks.  Given the subsequent significant structure and
  technological changes, the ITU membership agreed to meet in 2012 to
  revise the ITRs.  While consensus was found on an overwhelming
  majority of the treaty text, some provisions proved to be
  controversial, leading to a split in the membership and sharp
  criticism of selected provisions.

  As a result, some ITU Member States did not sign the treaty.  This
  document analyses that criticism and attempts to place it in context;
  it identifies problems that may arise if states to not accede
  to the treaty, and suggests a way forward, concluding that not
  acceding may have undesirable results for the citizens of
  non-signatory countries and for interoperability in general.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hill-itr-non-accession-harmful

- The deliverable for "the means of obtaining security-related parametric
information." The literal means of obtaining keys/credentials, I think, are
in the scope of the authorization validation method deliverable - for
RFC4474, for example, this was the Identity-Info header and the URI schemes
it described. You certainly can't do authorization validation without that
means. I could read this deliverable as if it's suggesting that header or
mechanism should be in a separate document. The original charter had "key
management" as a separate deliverable, which is a slightly different scope.

- The charter should be clear that we intend to obsolete RFC4474 and replace
it with something, regardless of whether or not that happens to be one of
our current input drafts.

Jon Peterson
Neustar, Inc.

On 6/27/13 9:50 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>I like this charter much more - I think it avoids the contentious 
>aspects that could drag down the BOF, while at the same time narrows 
>the scope of initial work to do.
>
>but the individual drafts are just individual drafts, and there are a 
>lot more that have been submitted over the years that we could dredge 
>up as input.  Is it meant as just a reading list type thing for 
>background?  Do we put that in charters typically?
>
>-hadriel
>
>
>> It focuses on specification of an authorization validation method and 
>>a method for getting the information needed to perform validation.  
>>The example of the first is signature in an identity field.  The 
>>example of the latter is a query to an external database, to get keys, 
>>credentials or the like.  But the language is intentionally 
>>non-technical, in order to leave the technical choices to the working 
>>group.  Hence, for example, it does not attempt to resolve the choice
between "credential"
>>this is actually a formal requirement for charter text, since the 
>>first paragraph is what's circulated in announcements.
>> 
>> 
>> d/
>> 
>> 
>> 
>> 
>> unauthorized use of source identities as part of deceptive and 
>> coercive activities, such as bulk unsolicited commercial 
>> communications, voicemail hacking, and impersonating banks. The 
>> current effort will specify a mechanism to support validation that a 
>> telephone number's presence in the SIP From field is authorized by 
>> the entity formally assigned use of that number, or by their 
>> delegate. The mechanism will support end-to-end SIP interactions. 
>> Initial specification will be in terms of a pure-SIP exchange, which will
serve as the operational base.
>> the first could be use of a cryptographically-protected field carried 
>> by SIP and containing identity and authentication information. An 
>> example of the second could be a mechanism for querying an external 
>> database, to obtain the key-signing parameters for the authentication
cryptography.
>> 
>> A number of previous efforts have attacked the problem of securing 
>> the origins of SIP communications, including RFC3325, RFC4474 and the 
>> VIPR working group. To date, however, true validation of the source 
>> of SIP calls has not seen any appreciable deployment. While several 
>> factors contributed to this lack of success, culprits included: 
>> failure of the problem to be seen as critical at the time; lack of 
>> any real means of asserting authority over telephone numbers on the 
>> Internet; misalignment of the mechanisms proposed by RFC4474 with the 
>> complex deployment environment that has emerged for SIP; and inherent 
>> operational problems with a transitive trust model.
>> 
>> 
>> A likely approach for SIP-based authorization validation is to 
>> include a new capability for Identity assertions to cover telephone 
>> numbers, rather than domain names. To conform with realistic deployments.
>> 
>> problem of signaling through existing deployments, including 
>> activities in the INSIPID and STRAW working groups.
>> 
>> Identity is closely linked to privacy, and frequently one comes at 
>> the cost of the other. To the extent feasible the working group will 
>> favor privacy-friendly choices that minimize call information leakage 
>> to third parties.
>> 
>> - Specification of the means for obtaining security-related 
>> parametric  information, used to perform source telephone number 
>> identity  authorization validation.
>> 
>> 
>> Milestones
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 15:14:32 -0400

> one of our current input drafts.

It's likely that the resulting outcome of this WG ends up being a much narrower assertion of stuff being protected/authenticated - in particular, it might only end up protecting the caller-id for a given request, and nothing more.  ISTM that rfc4474 tried to 'protect' things that went beyond simply the caller-id of a request.  So if we *only* protect the caller-id, will you be comfortable with replacing RFC4474?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jun 2013 15:58:58 -0400

> one of our current input drafts.

You mean replace it for non-number URIs too?

While there may be good reason to do that, it seems like the issues are 
different, and trying to do both together might be distracting.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Jun 2013 20:06:02 +0000

There are some areas of ambiguity here, definitely, about the scope of
RFC4474 against the current work. A lot of this comes down to questions
we've discussed before: dealing with non-INVITE requests and defining the
threat of impersonation properly. If, extending the analogy to email, you
could secure the From header but not the body of the message, would it be
"impersonation" when someone changed the message body so that it appeared
you were saying something different than you intended?

We agreed coming in to this to scope the threat model such that a
man-in-the-middle modifying SDP, for example, changing m= or c= lines,
would not break the signature protecting caller ID. Personally, I think
there is value for impersonation protection in some environments and
scenarios in detecting change in message bodies - for non-INVITE requests
(MESSAGE, say), protecting security parameters in SDP which support SRTP,
etc. I think there are ways to design the overall mechanism that can
reconcile those two requirements. Some kind of separate signature over the
body, where the body signature would be optionally added by the
authentication service, is something we've discussed before. Maybe there
should be a special case for parameters relevant to SRTP. I don't think we
need a fully-baked solution at this point, but yes, I'd want that to be
part of the discussion of where we go with any identity mechanism for SIP.

Moreover, loosening the threat model when it comes to men-in-the-middle
doesn't mean we should ignore replay attacks. When you say "caller-id for
a given request, and nothing more," taken literally that would probably
fall short of the bar of protecting against cut-and-paste attacks. So no,
I don't think it's reasonable to say the scope of this is protecting only
the calling party number.

Jon Peterson
Neustar, Inc.

On 6/27/13 12:14 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>It's likely that the resulting outcome of this WG ends up being a much
>narrower assertion of stuff being protected/authenticated - in
>particular, it might only end up protecting the caller-id for a given
>request, and nothing more.  ISTM that rfc4474 tried to 'protect' things
>that went beyond simply the caller-id of a request.  So if we *only*
>protect the caller-id, will you be comfortable with replacing RFC4474?
>
>-hadriel
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Jun 2013 17:20:38 -0400

Dave:

Thanks for proposing text.  There are places where there is obvious improvement, but there are other places that raise concern for me.  Comments below.

Russ

> complicated mediation scenarios.

I do not think "As with email" helps in the first two sentences.  SIP is a fairly well understood protocol in the IETF, so we can just talk about it.

The last sentence is confusing to me.  The previous sentences say that the WG will develop a mechanism, and then the last sentence calls for additional ones in "complicated mediation scenarios".  Since mediation has not come up in this text before, I am not sure what it means here.

> obtain the key-signing parameters for the authentication cryptography.

I suggest this should be higher level description.  I suggest:

The working group will consider choices for the method of specifying
authorization information and the means of authenticating and validating
this information. For example, a cryptographically-protected field carried by
SIP could contain identity and authentication information, and then a
database could be queried to obtain the keying material to perform the
authentication checking.

> with a transitive trust model.

All good.  Perhaps a sentence about why we think the time is better now would complete this thought.

>   http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00

Others has suggested that this is important for these to be available to BOF participants, but several people have suggested removing it from the charter.

I think that the problem statement could remain, but if other object, I an not hard over on it.

> rather than domain names. To conform with realistic deployments.

I'd like to see the same rigor that you used earlier applied to this paragraph.  I think the mechanism and validation are not clearly separated in this description.

>  difficulties motivating work on secure origins

Maybe the starting point of draft-cooper-iab-secure-origin-00 goes here.

>  authorization validation.

I think that the last deliverable should focus on the validation of the authorization information.  Yes, we will have to specify all the steps, but the description should not already assume that not inserted by the caller.

Russ

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jun 2013 21:27:55 +0000

Several outcomes are possible, and it seems unnecessary to pick one at this time:

- Leave 4474 alone and create something suited to STIR E.164 needs that can co-exist with 4474, but is otherwise independent (new header field, new logic, etc.).

- Update 4474 for the number case (and more limited signing).

- Replace 4474, and thus address both E.164 (tel/SIP) and non-E.164 SIP URLs.

This will partially depend on the "how to look up certs/public keys" debate outcome, so I see little advantage in picking one of the options now. While I don't think we'd intentionally break 4474 implementations, should they exist, without good cause, backward compatibility isn't the primary concern here, unlike in other "bis" efforts where everybody wants to be assured that the new effort at least won't break old boxes.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Thursday, June 27, 2013 3:14 PM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]
Subject: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 18:06:00 -0400

Up front I should be clear about one thing: I thought we had been told that the real-world problem we need to solve and focus on and quickly fix is bogus/spoofed caller-id.  I'm not saying we might not also end up solving other things simultaneously with the same mechanism, enough so that we can really replace RFC4474 - I'm just saying we shouldn't be constrained to having to do so by putting it in the charter right now.  It might turn out we can replace 4474, but we don't know that yet.

I agree that we could come up with some way to provide optional protection for the SDP or parts thereof, even with the ability to verify the caller-id while failing to verify the SDP all with one signature.  The problem is it wouldn't be of any use.  It gets back to the notion of there being different levels of security - shades of gray - that somehow users could distinguish between somewhat-secure and somewhat-more-secure calls.

And the truth is it would only be "somewhat-more-secure", not actually "secure", for the same reasons that using DTLS-SRTP doesn't truly provide "secure" end-to-end media even in WebRTC.  You'd need an out-of-band, real endpoint-to-endpoint, trusted-third-party assurance model for that; something like EKR's IdP proposal for WebRTC might get close, for example.  But if you have some out-of-band mechanism, then you don't need a STIR in-band mechanism to protect the SDP at all - it's superfluous.

Furthermore, I think most people here agree that the SDP-portion would change virtually all the time today, which means that that part of the assertion will fail all the time today.  So adding that portion is useless today, if not outright counter-productive to getting STIR adopted.  So skip forward to the future, at some point the extra assertion might start succeeding on a few calls somewhere.  Then what?  Do you start rejecting calls that don't succeed at it?  Even if most calls succeed with it, do you reject the rest?  What is this distinguishing security assertion useful for, to either machines or humans?

So let's talk about the replay and cut-and-paste attack scenarios.  Let's assume we all agreed we need to prevent them - since we know the SDP portion of the assertion will fail most of the time today, shouldn't we be trying to prevent them regardless of the SDP being changed or not by transit domains, so that we can protect the caller-id from such an attack today?  There is a very popular Enterprise PBX vendor that by-default sends INVITEs without SDP - are we saying calls from those PBXs can't have their caller-id's protected as strongly as from other PBXs?  Should we deprecate offer-less INVITEs, even from 3PCC servers, for example? (fwiw, I'd be ok with doing that :)

Lastly, this is the type of feature-creep that makes things harder to specify, implement, and deploy, instead of focusing on the problem at hand.  

-hadriel

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Fri, 28 Jun 2013 00:07:20 +0200

Guess it is pretty hard do design the "all singi'n & dancing machine" here ;-)

RFC4474 tried and struggled across modified headers and other neat things.

Why not start with a mandatory Caller-ID in the digest? This approach will at least prevent the majority of spoofing since the signed Caller-ID can be validated against a public CA.

... of course this will not prevent MITM Copy and Paste or biting-attacks which are a minority and thus we can ignore it for the start. This will however reveal all these script kiddies acting at the origin. I guess this is the majority of all spoofing attacks.

For all other cases we need to think a bit further.
Optional steps could sign unmodified headers, time-stamps and random identifiers that could reveal MITM modifications. 
Out of band databases to temporarily store enforceable-tokens for each call instance can be an additional way to validate regardless of anything that was modified on the way to the validating entity or even in the endpoint.

Willi

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jun 2013 15:56:26 -0700

> from regulators to carriers, from carriers to end users, with various

Everyone you cite, except "end users" are not "users" of the numbers.

They are administrators of registries and other providers of 
infrastructure support for the number.  That, at least, was the 
distinction I meant to draw by saying "use".  The group agreed to say 
"assignee" rather than "owner" and that's who is meant by the text's use 
of "assigned".

If some other verbiage will more robustly ensure that the reader knows, 
essentially, that the reference is meant to be whoever answers the phone 
at that number, please suggest it.

No doubt, some signers will be telcos or other operators, and this might 
seem confusing, but they are doing it /on behalf of/ the end user.  Even 
if real end users happen not to know their calls are being protected 
with a signature on their behalf, it is on their behalf.  It's not "by" 
the operator.  They are a delegate of the user.

> leave open possibilities, I might gloss over this with "an entity assigned

Given the ambiguity you've cited, I strongly suggest that the charter 
language /not/ gloss over any reasonable misunderstanding.  Let's get 
the language as tight and clear as we can.

> one of our current input drafts.

I see a separate sub-thread happening on this, so I'll wait to modify 
draft charter text until that's resolved.

FWIW, my own reading of RFC4474 causes me to think that dealing with it 
for the current effort will primarily add confusion rather than benefit, 
especially since it has a broader scope and it appears to have no 
meaningful deployment this many years after IETF approval.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jun 2013 16:43:29 -0700

On 6/27/2013 2:20 PM, Russ Housley wrote:
> Dave:
>
> Thanks for proposing text. There are places where there is obvious
> improvement, but there are other places that raise concern for me.
> Comments below.

{ blanket disclaimer about my responses [1]  /d }

>> As with email, the claimed source identity of a SIP request (in the
>> From field) is not verified. As with email, this permits and
>> produces unauthorized use of source identities as part of deceptive
>> and coercive activities, such as bulk unsolicited commercial
>> current effort will specify a mechanism to support validation that
>> a telephone number's presence in the SIP From field is authorized
>> by the entity formally assigned use of that number, or by their
>> Initial specification will be in terms of a pure-SIP exchange,
>> which will serve as the operational base. Additional mechanisms
>> might later be developed to support more complicated mediation
>> scenarios.
>
> I do not think "As with email" helps in the first two sentences. SIP
> is a fairly well understood protocol in the IETF, so we can just talk
> about it.

Well....  I suggest that this isn't about "SIP" as much as it is about
"protecting" SIP and that's something quite different, in terms of
people's experience.  (I guarantee you that 'protecting' email was a
very, very different engineering exercise for me than was creating basic
email protocol functions.  SIP is not the first service worrying about a
large-scale forgery problem.  The reference to email is meant to class
the problem domain as one that we've actually got quite a lot of
experience with, in terms of threats and attackers and engineering a
response to them.  In addition, it happens that in very broad terms, the
approach being proposed here is quite similar to one the IETF has
already standardized.  (I said "broad". I said "very".)

So my feeling is that it helps to start a new effort by noting its
similarity to one that has already been pursued in the IETF and that has
quite a lot of operational experience.

> The last sentence is confusing to me.  The previous sentences say
> that the WG will develop a mechanism, and then the last sentence
> calls for additional ones in "complicated mediation scenarios".
> Since mediation has not come up in this text before, I am not sure
> what it means here.

Hmmm.  "end-to-end SIP" and "pure SIP" are meant to indicate a highly
simplified underlying protocol scenario, for the current round of
effort.  Obviously things are, and will be, more complicated, with
hybrid scenarios.  I meant to hint at those, to acknowledge them and to
exclude them.  For the first paragraph that seems like enough.  But I
take your point that the last sentence lacks transition/introduction.

Perhaps:

      Because SIP is often used in complex, hybrid scenarios in which it
is not the only protocol, additional mechanisms might later be developed
to augment the pure-SIP mechanism.

>> The working group will consider choices for the method of
>> specifying authorization information and the means of obtaining the
>> parametric information needed to perform that authorization check.
>> An example of the first could be use of a
>> cryptographically-protected field carried by SIP and containing
>> identity and authentication information. An example of the second
>> could be a mechanism for querying an external database, to obtain
>> the key-signing parameters for the authentication cryptography.
>
> authorization information and the means of authenticating and
> validating this information. For example, a
> cryptographically-protected field carried by SIP could contain
> identity and authentication information, and then a database could be
> queried to obtain the keying material to perform the authentication
> checking.

wfm.

{ I had thought the text you replaced was pretty high level, but no
matter; yours reads better to me. }

>>  the origins of SIP communications, including RFC3325, RFC4474 and
>>  the VIPR working group. To date, however, true validation of the
>> source of SIP calls has not seen any appreciable deployment. While
>>  several factors contributed to this lack of success, culprits
>> included: failure of the problem to be seen as critical at the
>> time; lack of any real means of asserting authority over telephone
>>  numbers on the Internet; misalignment of the mechanisms proposed
>> by RFC4474 with the complex deployment environment that has emerged
>> for SIP; and inherent operational problems with a transitive trust
>> model.
>

uhhh... sure.  Feed me.

>> Private Extensions to the Session Initiation Protocol (SIP) for
>> Asserted Identity within Trusted Networks RFC 3325
>>
>> Enhancements for Authenticated Identity Management in the Session
>> Initiation Protocol (SIP) RFC 4474
>>
>> Secure Origin Identification: Problem Statement, Requirements, and
>>  Roadmap
> Others has suggested that this is important for these to be available
> to BOF participants, but several people have suggested removing it
> from the charter.
>

Wasn't sure how much of the existing input docs to cite.  Charters vary
on this.

I'll take your directions as removing all but problem statement.

> I'd like to see the same rigor that you used earlier applied to this
>  paragraph.  I think the mechanism and validation are not clearly
> separated in this description.

well, ummm, I was trying to preserve as much of the original draft text
as I could...

On reflection, given where the group's discussion has gone, the
reference to domain names is now probably vestigial and unhelpful.

Perhaps:

    A likely approach for SIP source identity validation will be to
employ a cryptographically-protected Identity assertion accompanying the
telephone number in the SIP From field.  An external query service is
likely to be defined for obtaining the necessary cryptography-related
parameters.

{ no, I'm not in love with it either.  again... feed me. }

>> The working group will coordinate with RAI area groups studying
>> the problem of signaling through existing deployments, including
>>  the cost of the other. To the extent feasible the working group
>> will favor privacy-friendly choices that minimize call information
>>  leakage to third parties.
>>

Stylistically, I'm used to having "input" stuff in a charter precede
"deliverable" stuff.  But that's a nit, of course.

>> - Specification of an authorization validation method for the
>> source telephone number identity of a SIP request (in the From
>> field)
>>
> I think that the last deliverable should focus on the validation of
> the authorization information.  Yes, we will have to specify all the
>  steps, but the description should not already assume that not
> inserted by the caller.

Hmmm.  I was trying to distinguish between the basic 'packaging'
protocol vs. the query service, but I think you are seeing a different
distinction.

Or perhaps you mean an /additional/ deliverable that combines packaging
with query service to produce a complete process for performing validation?

Please clarify. I'm not sure what change to make.

d/

[1] I'm hoping Russ already knows this, but just to make sure he and
everyone else does:  I got to 'own' the draft text while writing it and
imposing whatever whimsical preferences i felt like; but by posting it
to the list, I switched to -- at most -- editor.  So I'll offer opinions
about suggestions -- and it's the fact that I might get vigorous that
prompts my wanting to add this disclaimer -- and am glad to expedite
things by assuming what's ok with the group, but it's the group that
actually decides on the text.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 27 Jun 2013 23:56:37 +0000

Re:  Because SIP is often used in complex, hybrid scenarios in which it is
not the only protocol, additional mechanisms might later be developed to
augment the pure-SIP mechanism.

Maybe:  Because SIP is often used in complex, hybrid scenarios in which it
is not the only signaling protocol, ancillary signaling mechanisms might
later be developed to augment the SIP-only signaling.

Signaling could also be replaced by "session-setup protocol", but didn't
want to get into the SIP versus SDP and which is really session stuff.
Mechanisms seemed a bit broad.  Just wanted to suggest that it is the "call"
signaling aspect of the networks that we are focused on.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Thursday, June 27, 2013 4:43 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [stir] Revised charter text for STIR

>> From field) is not verified. As with email, this permits and produces 
>> Initial specification will be in terms of a pure-SIP exchange, which 
>> will serve as the operational base. Additional mechanisms might later 
>> be developed to support more complicated mediation scenarios.
>

Well....  I suggest that this isn't about "SIP" as much as it is about
"protecting" SIP and that's something quite different, in terms of people's
experience.  (I guarantee you that 'protecting' email was a very, very
different engineering exercise for me than was creating basic email protocol
functions.  SIP is not the first service worrying about a large-scale
forgery problem.  The reference to email is meant to class the problem
domain as one that we've actually got quite a lot of experience with, in
terms of threats and attackers and engineering a response to them.  In
addition, it happens that in very broad terms, the approach being proposed
here is quite similar to one the IETF has already standardized.  (I said
"broad". I said "very".)

> The last sentence is confusing to me.  The previous sentences say that 
> the WG will develop a mechanism, and then the last sentence calls for 
> additional ones in "complicated mediation scenarios".

Hmmm.  "end-to-end SIP" and "pure SIP" are meant to indicate a highly
simplified underlying protocol scenario, for the current round of effort.
Obviously things are, and will be, more complicated, with hybrid scenarios.
I meant to hint at those, to acknowledge them and to exclude them.  For the
first paragraph that seems like enough.  But I take your point that the last
sentence lacks transition/introduction.

Perhaps:

      Because SIP is often used in complex, hybrid scenarios in which it is
not the only protocol, additional mechanisms might later be developed to
augment the pure-SIP mechanism.

>> information needed to perform that authorization check.
>> An example of the first could be use of a cryptographically-protected 
>> field carried by SIP and containing identity and authentication 
>> information. An example of the second could be a mechanism for 
>> querying an external database, to obtain the key-signing parameters 
>> for the authentication cryptography.
>

wfm.

{ I had thought the text you replaced was pretty high level, but no matter;
yours reads better to me. }

>> included: failure of the problem to be seen as critical at the time; 
>> lack of any real means of asserting authority over telephone  numbers 
>> on the Internet; misalignment of the mechanisms proposed by RFC4474 
>> with the complex deployment environment that has emerged for SIP; and 
>> inherent operational problems with a transitive trust model.
>

uhhh... sure.  Feed me.

>> Authenticated Identity Management in the Session Initiation Protocol 
>> (SIP)

Wasn't sure how much of the existing input docs to cite.  Charters vary on
this.

> separated in this description.

well, ummm, I was trying to preserve as much of the original draft text as I
could...

On reflection, given where the group's discussion has gone, the reference to
domain names is now probably vestigial and unhelpful.

Perhaps:

    A likely approach for SIP source identity validation will be to employ a
cryptographically-protected Identity assertion accompanying the telephone
number in the SIP From field.  An external query service is likely to be
defined for obtaining the necessary cryptography-related parameters.

>> favor privacy-friendly choices that minimize call information  

> steps, but the description should not already assume that not inserted 
> by the caller.

Or perhaps you mean an /additional/ deliverable that combines packaging with
query service to produce a complete process for performing validation?

d/

[1] I'm hoping Russ already knows this, but just to make sure he and
everyone else does:  I got to 'own' the draft text while writing it and
imposing whatever whimsical preferences i felt like; but by posting it to
the list, I switched to -- at most -- editor.  So I'll offer opinions about
suggestions -- and it's the fact that I might get vigorous that prompts my
wanting to add this disclaimer -- and am glad to expedite things by assuming
what's ok with the group, but it's the group that actually decides on the
text.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 00:03:44 +0000

On 6/27/13 3:06 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>Up front I should be clear about one thing: I thought we had been told
>that the real-world problem we need to solve and focus on and quickly fix
>is bogus/spoofed caller-id.  I'm not saying we might not also end up
>solving other things simultaneously with the same mechanism, enough so
>that we can really replace RFC4474 - I'm just saying we shouldn't be
>constrained to having to do so by putting it in the charter right now.
>It might turn out we can replace 4474, but we don't know that yet.

Maybe we should postpone that question to after chartering, but if we
can't agree on how close the scope of security services is to what RFC4474
offers, that may actually be a charter-level problem. Scope as in, that it
not be susceptible to replay attacks, say.

>I agree that we could come up with some way to provide optional
>protection for the SDP or parts thereof, even with the ability to verify
>the caller-id while failing to verify the SDP all with one signature.
>The problem is it wouldn't be of any use.  It gets back to the notion of
>there being different levels of security - shades of gray - that somehow
>users could distinguish between somewhat-secure and somewhat-more-secure
>calls.

I think there are already a set of discernible and different security
properties of a SIP session. For example, you raise one below, whether the
media uses SRTP or not. If a call uses identity, we could say it is
somewhat secure, and if it also uses SRTP, we could say its
somewhat-more-secure. You seem to be arguing that if there are two
distinct security properties, the question of how to render them in the UI
trumps any inherent usefulness in their deployment? Is SRTP only useful if
a UI is telling you it's there?

Certainly there are times you might want to be sure SRTP is in place, and
in those times users should have a way to check it. Similarly, there might
be times you really want to make sure that the number calling you is
unspoofed, and if the surety isn't there, you may change your behavior.
I'm not afraid offering information to SIP entities without designing an
algorithm that reduces every factor to a single binary lockbox graphic.

>And the truth is it would only be "somewhat-more-secure", not actually
>"secure", for the same reasons that using DTLS-SRTP doesn't truly provide
>"secure" end-to-end media even in WebRTC.  You'd need an out-of-band,
>real endpoint-to-endpoint, trusted-third-party assurance model for that;
>something like EKR's IdP proposal for WebRTC might get close, for
>example.  But if you have some out-of-band mechanism, then you don't need
>a STIR in-band mechanism to protect the SDP at all - it's superfluous.

Even trying to apply a blanket term like "secure" to something as manifold
and complex as a SIP session is problematic. Again, there are little
chunks of problem and of solution scattered through the specs.

And broadly, agreed that out-of-band can do more interesting things than
in-band, but as you know it has its own challenges to overcome.

>Furthermore, I think most people here agree that the SDP-portion would
>change virtually all the time today, which means that that part of the
>assertion will fail all the time today.  So adding that portion is
>useless today, if not outright counter-productive to getting STIR
>adopted.  So skip forward to the future, at some point the extra
>assertion might start succeeding on a few calls somewhere.  Then what?
>Do you start rejecting calls that don't succeed at it?  Even if most
>calls succeed with it, do you reject the rest?  What is this
>distinguishing security assertion useful for, to either machines or
>humans?

I'm not necessarily saying that body-level security should be an
all-or-nothing thing like it was in RFC4474, at least not for INVITE
requests - it might be possible to design something helpful that wouldn't
even fail in some deployments similar to the ones you have in mind.
RFC4474 opted to do the simplest thing we could think of, which was to
treat all requests alike and to offer the same protection to all message
bodies. It was thinking about NOTIFYs and MESSAGEs as well as INVITEs.
Perhaps today we'd approach it differently.

But more materially, I am proposing that we create an optional hook for
the deployments and scenarios where protecting some elements of bodies
makes sense. I fully understand that there are deployments where it will
not be practical, and I think we can make the hook quite unobtrusive for
those deployments. My question to you is, are you so dedicated to the
architecture of SIP request bodies being unprotected that you're unwilling
to have even an option for this?

>So let's talk about the replay and cut-and-paste attack scenarios.  Let's
>assume we all agreed we need to prevent them - since we know the SDP
>portion of the assertion will fail most of the time today, shouldn't we
>be trying to prevent them regardless of the SDP being changed or not by
>transit domains, so that we can protect the caller-id from such an attack
>today?  There is a very popular Enterprise PBX vendor that by-default
>sends INVITEs without SDP - are we saying calls from those PBXs can't
>have their caller-id's protected as strongly as from other PBXs?  Should
>we deprecate offer-less INVITEs, even from 3PCC servers, for example?
>(fwiw, I'd be ok with doing that :)

I'm not sure why you're linking replay protection and body protection here
- I didn't suggest they were connected in my mail. Replay protection is
really a question of what headers are going to get signed. As I sent in a
mail very early in the list, I didn't think from what I read in your draft
that we're hugely far apart on this.

>Lastly, this is the type of feature-creep that makes things harder to
>specify, implement, and deploy, instead of focusing on the problem at
>hand. 

If by "this" you mean "replay protection," I'd say it is something that
makes this actually prevent impersonation instead of not preventing
impersonation.

Jon Peterson
Neustar, Inc.

>>>> replace it with something, regardless of whether or not that happens
>>>>to
>>>> be

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 00:40:32 +0000

[snip]
>the operator.  They are a delegate of the user.

I think many people on this list would view telcos signing as the everyday
case, and end-user signators as the exception. From an assignment
perspective, carriers are certainly not (in contemporary North America
anyway) delegates of the user; users are delegates of the carrier.
Moreover there are plenty of other actors, like resellers, enterprises,
etc who are also delegates and potentially signers. The problem again with
the "the entity formally assigned use" language is that it treats the
concept of "assignee" as if numbers have a single authority, but the
reason "assignee" is a better term here than "owner" is because it doesn't
have the connotation that there's some single authority. Numbering doesn't
work that way.

>the language as tight and clear as we can.

If we fail to account for the fact that there will be several delegate
entities that can be legitimate signators for a given number, we will not
capture the problem space. If the charter expresses the opposite of that,
it will be a problem.

Jon Peterson
Neustar, Inc.

---

From: Dan York <[email-masked]>
Date: Fri, 28 Jun 2013 00:43:35 +0000

>It might turn out we can replace 4474, but we don't know that yet.

+1 to this and also to Henning's list of potential outcomes.

I think we need to focus on getting something out - and getting something
*deployed* - that solves the phone number secure origin problem we've been
talking about.   I worry that adding in a requirement that we need to
obsolete/replace RFC 4474 will create additional delays and steps in the
process of getting a solution out and deployed.

If, as we are repeatedly being told, "no one is using RFC 4474" because of
its problems, than does anyone really care if RFC 4474 gets obsoleted or
just hangs around as yet-another-RFC-that-is-ignored?

A better approach may be to get a STIR solution out and deployed as
rapidly as possible and then separately run a 4474bis process that
potentially incorporates the STIR solution and makes other modifications -
and obsoletes 4474.

My 2 cents,
Dan

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jun 2013 22:10:25 -0700

> have the connotation that there's some single authority. Numbering doesn't

End users are not working "on behalf of" the provider.  The term 
"delegate" would mean they were...  So, no, the end user is not a 
delegate of the telco.

It's important not to confuse the mechanics of some actions with the 
roles being performed.  We need to distinguish among several different 
roles and several different actions and a couple of different 
legitimization models.

Values are administered, possibly through a hierarchy.  Ultimately, they 
are assigned for 'use'.  Look into a reverse white pages and you won't 
find reference to the telco or Neustar.  You'll find the user who 
answers the phone.

Administrators are not 'users'.  Yeah, they mess with the value, but 
they are performing support functions.

Operators also perform some functions that touch the value.  Back when 
telephone numbers were tied to switch topology, of course, the 
relationship was tighter.  But again, they are not 'users'.  They are 
providers.  The difference is fundamental.

We need to avoid confusing support functions -- whether administration 
or operations -- from assignment to the end-user.

The history with telephone numbers has conflated a number of different 
roles into the same set of actors.  Number portability highlights that 
they really are different roles.  They further make clear that the 
assignment of the number is detached from the telco that assigns it to 
the end user.

Yes, the number can be taken back from the end user, but not at the whim 
of the telco.  And it's generally not permitted to say 'owner' when a 
continued licensing fee is required to retain rights.

Lastly is the role of vouching for validity.  The end user can vouch for 
their own use, because have that authority.  But it's plausible that 
others might do the vouching, either because the end user delegated that 
right to them or because the services that check for validity lend 
credence to some other agents.  This moves from a simple, objective 
assignment-based model for validation to one that looks more like 
third-party reputation.

So a telco doing signing is fine, either because they are doing it with 
the user's implicit/explicit permission, or because the assessment 
service chooses to treat the telco as a trusted agent.

d/

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Fri, 28 Jun 2013 08:22:22 +0200

Yes, 
as Henning states: 
Starting out with "limited signing" for the number is the basic thing we shall do for a start.

The Pro's
+ This gives a strong authentication of the Caller-ID
+ Every one in the chain can validate
+ We protect "the user" instead of "the transport & service"
  ... IP is not based "Trust by Wire" anymore ;-)
+ We can re-use the authentication for other cases
  including encryption
+ Operators can force users to assert the final
  Caller-ID format without modifying it later

- MITM fiddling is still possible
- We need authoritative validation services (CA)s 
  for initial enrollment of phone numbers

Further evolution can start when 
1.) Operators learn that they are signing at most "on behalf" 
    of the user or endpoint as Dave mentions, 
2.) Endpoints learn to sign and validate themselves, 
3.) SIP can turn in to a real e2e service where operators
    will become the connection agent as we see it with DNS

Willi

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Fri, 28 Jun 2013 08:44:18 +0200

Dave,
I fully agree with the "on behalf of" and "delegation" view 
I would go a step further state that end users 
"optionally delegate the signing power to the operator"
and thereby allow the operator to sign on behalf of the
end-user.

... of course this is the default case today.
In the long term this will change.

Shall we add something like this as a basic assumption to the charter?

This will make the STIR work much simpler and at least it will be a clear statement how to deal with this old paradigms in the scope of STIR.

... we are on the Internet and not on closed "Trust by Wire" networks anymore.

Willi

On 28.06.2013, at 07:10, Dave Crocker wrote:

> End users are not working "on behalf of" the provider.  The term "delegate" would mean they were...  So, no, the end user is not a delegate of the telco.
> 
> It's important not to confuse the mechanics of some actions with the roles being performed.  We need to distinguish among several different roles and several different actions and a couple of different legitimization models.
> 
> 
> Values are administered, possibly through a hierarchy.  Ultimately, they are assigned for 'use'.  Look into a reverse white pages and you won't find reference to the telco or Neustar.  You'll find the user who answers the phone.
> 
> Administrators are not 'users'.  Yeah, they mess with the value, but they are performing support functions.
> 
> Operators also perform some functions that touch the value.  Back when telephone numbers were tied to switch topology, of course, the relationship was tighter.  But again, they are not 'users'.  They are providers.  The difference is fundamental.
> 
> We need to avoid confusing support functions -- whether administration or operations -- from assignment to the end-user.
> 
> The history with telephone numbers has conflated a number of different roles into the same set of actors.  Number portability highlights that they really are different roles.  They further make clear that the assignment of the number is detached from the telco that assigns it to the end user.
> 
> Yes, the number can be taken back from the end user, but not at the whim of the telco.  And it's generally not permitted to say 'owner' when a continued licensing fee is required to retain rights.
> 
> 
> Lastly is the role of vouching for validity.  The end user can vouch for their own use, because have that authority.  But it's plausible that others might do the vouching, either because the end user delegated that right to them or because the services that check for validity lend credence to some other agents.  This moves from a simple, objective assignment-based model for validation to one that looks more like third-party reputation.
> 
> So a telco doing signing is fine, either because they are doing it with the user's implicit/explicit permission, or because the assessment service chooses to treat the telco as a trusted agent.
> 
> d/
> 
> 
> 
> 
> -- 
> Dave Crocker

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 15:45:24 +0000

Just want to be clear we are trying to protect the caller-id for the call. (i'd like to bold the "for the call" part of previous sentence).

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 14:20:42 -0400

> Just want to be clear we are trying to protect the caller-id for the call. (i'd like to bold the "for the call" part of previous sentence). 

No, we're not - or rather, that's not been the problem we've been asked to solve, and not a problem that's actually occurring.

We've been asked to solve the problem of bogus+spoofed caller-id's for *call-initiating requests*.  We have not been asked to solve a problem of valid call requests with bogus media, we have not been asked to solve a problem of valid calls being hijacked, we have not been asked to solve a problem of valid calls being eavesdropped, we have not been asked to solve a problem of valid calls being routed to the wrong participants, etc.

We've been asked to solve a real-world problem.  We've been told to solve it as quickly as possible.  We've also essentially been told it needs to be deployable by carriers, in such a way that they will *want* to deploy it, because there's not going to be a legal mandate rubber-stamping an IETF RFC and forcing the carriers to comply. (There may be such a mandate in some countries someday, but not the one I live in anyway... not in a short timeframe)

I know we'd like to solve a lot of other problems at the same time, because it's nice to kill two birds with one stone.  But right now other birds don't exist, and we have to throw the stone quickly before the single bird gets away.  And a bird in the hand is worth two in the bush.
[heh, two proverbs linked together, cute eh? :) ]

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 18:32:19 +0000

Perhaps the charter should have a requirement for extensibility.

Then perhaps those other things can be added in later???

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Friday, June 28, 2013 11:21 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked]; Jon Peterson
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

On Jun 28, 2013, at 11:45 AM, "Cullen Jennings (fluffy)" <[email-masked]>
wrote:

> Just want to be clear we are trying to protect the caller-id for the call.
(i'd like to bold the "for the call" part of previous sentence). 

No, we're not - or rather, that's not been the problem we've been asked to
solve, and not a problem that's actually occurring.

We've been asked to solve the problem of bogus+spoofed caller-id's for
*call-initiating requests*.  We have not been asked to solve a problem of
valid call requests with bogus media, we have not been asked to solve a
problem of valid calls being hijacked, we have not been asked to solve a
problem of valid calls being eavesdropped, we have not been asked to solve a
problem of valid calls being routed to the wrong participants, etc.

We've been asked to solve a real-world problem.  We've been told to solve it
as quickly as possible.  We've also essentially been told it needs to be
deployable by carriers, in such a way that they will *want* to deploy it,
because there's not going to be a legal mandate rubber-stamping an IETF RFC
and forcing the carriers to comply. (There may be such a mandate in some
countries someday, but not the one I live in anyway... not in a short
timeframe)

I know we'd like to solve a lot of other problems at the same time, because
it's nice to kill two birds with one stone.  But right now other birds don't
exist, and we have to throw the stone quickly before the single bird gets
away.  And a bird in the hand is worth two in the bush.
[heh, two proverbs linked together, cute eh? :) ]

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 19:13:26 +0000

Extensibility is one way to address it, but if we said "the scope of
protection should be configurable as new extensions come along," it would
make me share the fears about shades-of-gray that Hadriel has previously
expressed. I would much rather be explicit up front about what we think
the total scope of protection can be, and what existing deployments will
permit.

The argument that basing STIR on obsoleting RFC4474 adds new features
beyond the motivating requirements is powerful rhetoric, but divorced I
think from the actual reality of the IETF work before us. The fact is, we
have a body of prior work on authentication services and verification
services, on how to create, sign and validate digest-strings, and how to
determine signing authorities. I don't think I've heard anyone here (yet,
anyway) proposing an alternative architecture, just a change to the
digest-string and an addition to the types of signing authority.

The changes we need to make in STIR to the digest-string are, with one
exception, changes we would make regardless of whether or not the From
header field value contained a telephone number. They are changes that
will make this work with existing deployments. The one exception is the
canonicalization algorithm for telephone numbers we've discussed on the
list: that work is specific to telephone numbers. If we're fixing the rest
of the digest-string for the TN case, though, we should also fix it for
the greenfield case. The greenfield case doesn¹t introduce any new
requirements for this, say. It would not save us any work to treat this as
a separate effort from obsoleting the digest-string of RFC4474.

The addition of a new category of signing authority for telephone numbers
isn't even a wire protocol change, as I've previously pointed out.
Identity-Info is already quite flexible in terms of what URI types it
supports (including potentially dns URIs). The new work that needs to be
done here is on how we compare the (canonicalized) From telephone number
with the authority of the signer. But even the logic that inspects the
>From field to determine if it contains a telephone number needs to be
cognizant of the existence of greenfield identifiers, and trying to cast
this such that it operates in complete isolation from the world of
greenfield SIP URIs will not be conducive to a robust solution. I have a
hard time seeing an argument that it would be better to deploy
verification services that can only understand telephone numbers, given
the enormous overlap in functionality with understanding native SIP URIs,
and the fact that the standardization work on that is already done. There
is no new "feature" we'd need to figure out to support greenfield IDs.

So again, I don't really see the argument that there's some kind of new
work or additional consideration required to take on obsoleting RFC4474.
We would be adding some new logic, some different branches to walk down,
and fixing some stuff that was previously broken. Yes, we need to agree on
what the changes to the digest-string would be, and deciding how body
security fits into that (or not) is a place where we could potentially get
into the weeds - but whether we're talking about TNs in isolation or along
with greenfield identifiers, that discussion isn't going to just go away,
we need to have it. That much said, I feel pretty confident we could
arrive at a compromise solution that would not burden existing deployments
with unnecessary false negatives or needless operations.

Jon Peterson
Neustar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 15:37:00 -0400

If that's all true, then it should be a simple matter to decide to replace 4474 with the thing we produce, when we either choose an I-D to be a WG draft, or move closer to publishing a WG draft.  I don't believe not having "we will replace 4474" in the charter would prevent us from replacing it in the end if we decide our output should replace it.  I don't even think it requires a recharter, does it?

So then what are we arguing about?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 15:56:21 -0400

[breaking this response into two parts - it be gettin' too long]

> a UI is telling you it's there?

No, but while "SRTP" isn't useful for a UI, it *is* useful for a machine/system to use.  For users, SRTP isn't useful to know whether media is secure end-to-end at all, because it should never be assumed to be end-to-end.  It's practical utility today is in securing the specific network path/hops between its two SRTP-ends, which are far shorter than end-end; that basically means its practical benefit is limited to preventing eavesdropping on things like wifi and other insecure hops.

So for machines, SRTP can be useful in a black/white way because the machines can actually be set to only use SRTP and reject calls which don't use SRTP in specific deployment cases, because there are deployment scenarios where that makes sense - ones where the admin believes the network to be insecure from eavesdropping, knows the other party/parties do as well, and that they should all be using SRTP or the call must fail.

The difference between that, and rfc4474-style signing SDP to verify it's unchanged all the way from the originating domain, is that I don't understand what system or user could use it in a black/white way.  It's not needed for scenarios where you know the topology - you would want to get calls from any originating domain, and yet not trust the carriers in the middle.  But if you're the type of entity who doesn't trust the carriers in the middle not to mess with your actual media, then you wouldn't accept any call to begin with from carriers.  Signing the SDP does not prevent the originating carrier or any E.164 delegate/assignee along the authority-chain from doing whatever they want with the media.  And it doesn't prevent the carriers in the middle from learning a hell of a lot about your call simply from the signaling.  Paranoid entities simply shouldn't trust such models to be sufficiently secure no matter what we do.

So I'm asking what the scenario is we'd use this info for in a black/white way - to make some yes/no decision.  If we can't show something different to the users in a UI, and if the system admins can't do something different with the info, what good is it in practice?

I'm not claiming there is no such scenario - I really just don't know what it would be.  I'd like to know it would be useful for something; otherwise I fear it's a waste of time and counter-productive.

> unspoofed, and if the surety isn't there, you may change your behavior.

I'm confused by that statement - are you saying if we don't sign SDP we can't be sure the number calling us is unspoofed?  Obviously we can't know the audio/video *media* is unspoofed, but we should know the caller-id number isn't. (or maybe I misunderstand what you mean above?)

And no, I'm not an idiot - I do realize most people expect the media to be from the number calling them. :)

But it's simply not possible to provide them such assurance today, and that hasn't been a real-world problem needing to be solved.  We don't see calls with legitimate caller-id's and spoofed media, and we don't even see spoofed media in general.  And if/when it does happen, the STIR mechanism won't help us counteract it, because such calls would be indistinguishable from the 99.999% other calls that have munged SDP. (ie, all calls would be blocked if we started blocking calls with changed SDP)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 15:56:59 -0400

[part 2]

On Jun 27, 2013, at 8:03 PM, "Peterson, Jon" <[email-masked]> wrote:
> those deployments.

Actually it's not unobtrusive.  It reveals that carriers in the middle changed the SDP.

> My question to you is, are you so dedicated to the

Hah!  I'm "dedicated to the architecture of SIP request bodies being unprotected"?!?  Yes I've dedicated my life to leaving SIP request bodies unprotected.  The Flying Spaghetti Monster himself came down and told me to never protect SIP bodies.

    "For the FSM so hated the SIP request bodies, that whoever believes in
     Him shall smite the evil bodies at all cost.  For they are wicked bodies 
     full of IP Addresses, and port numbers, and other vile attributes." 
     - Kaplan 3:42

I don't know what I was possibly thinking when I wrote a draft that allows for signing the SDP or relevant parts thereof:
http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity

Clearly I had a temporary crisis of faith at the the time. ;)

> that we're hugely far apart on this.

Sorry for the confusion - I thought you were saying we needed to sign bodies to prevent certain forms of cut-paste attacks.  Obviously pure "replay" attacks can be prevented regardless of SDP.  I meant more cut-paste attacks, as in the baiting-attack, which is a problem I do worry about with even just caller-id reputability.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 20:03:40 +0000

I know, right?!

But seriously, there's a lot of "ifs" in your statement below. I'm
concerned that if we start out with a non-goal of replacing RFC4474, we
could duplicate a lot of design and effort and architecture (and pretty
much text, even) and yet, in the name of parsimoniousness, end up with two
different flavors of verification and authentication services that as
specifications need to be separately updated and kept in synch and so on.
I'd rather nip that at the bud.

Jon Peterson
Neustar, Inc

On 6/28/13 12:37 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>If that's all true, then it should be a simple matter to decide to
>replace 4474 with the thing we produce, when we either choose an I-D to
>be a WG draft, or move closer to publishing a WG draft.  I don't believe
>not having "we will replace 4474" in the charter would prevent us from
>replacing it in the end if we decide our output should replace it.  I
>don't even think it requires a recharter, does it?
>
>>> We've been asked to solve a real-world problem.  We've been told to
>>>solve
>>> it

---

From: Dan York <[email-masked]>
Date: Fri, 28 Jun 2013 20:34:20 +0000

On 6/28/13 4:03 PM, "Peterson, Jon" <[email-masked]> wrote:

>I'm concerned that if we start out with a non-goal of replacing RFC4474,
>we

I hear what you are saying, Jon, but we've heard time and time again in
various conversations that RFC4474 is "not being deployed" and is not
being used because it has too many challenges in the way SIP systems are
deployed today.  So it may be more accurate to say that we might end up
with:

1. one flavor of verification and authentication services that "nobody
uses"  (RFC 4474)
2. one flavor of verification and authentication services that is focused
on telephone numbers  (STIR)

And if this is the case I would ask if we really need to worry about #1 at
this point in time.

Might it not be better to focus on getting a STIR solution out and THEN
look at a 4474bis that looks at the larger 4474 challenges and integrates
the STIR work into that larger work?

My concern with adding a piece to the charter about replacing 4474 means
that it becomes yet one more thing that needs to be completed - and we
don't know if in fact a STIR solution will truly be able to replace 4474.
We might find that the simplest and most easily deployable solution for
STIR will not solve all the challenges of 4474 - and yet if the charter
says we need to replace 4474 we're then either trying to make it do so or
we're rechartering.

Let's make the charter as simple and focused as possible.  When we get to
where we have an agreed-upon solution we can decide if it can, in fact,
replace 4474 and can make that decision then.

My 2 cents,
Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 16:48:21 -0400

OK, but I'm concerned that if we start out with a goal of replacing RFC4474, that we're constrained to providing the same level of protection, for the same information/aspects, against the same type of attack vectors.  I'm *not* concerned we'll have to protect the literal From/To/Date/Call-ID/Cseq header field values, because I think we can work around those, but I'm concerned that we'll be required to protect bodies or even parts thereof.

And I *am* expecting to discuss design and architecture, and don't want to be constrained to even having to support a URL model.  Yes one could put 'dns' in it, but if it would be up to the originator to decide whether to put 'dns' or 'http' in it, then I think there will be a discussion to have about that in the WG - and I don't want someone to just be able to say "we have to have it because it's already in RFC 4474".  And you know people say things like that all the time in WG's, using the charter as a club to beat down discussion.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 20:59:03 +0000

While I don't entirely agree with the account of numbering administration
or assignment offered below, it certainly acknowledges that entities other
than end users will sign for telephone identities. The point I raised
about the proposed charter text was that I wasn't sure what actors it
means where it reads that signing authority rests with "the entity
formally assigned use of that number, or their delegate." I don't think
there really is any formal assignment, there's a loose and sometimes
convoluted process of delegation with many strange corner cases, and many
numbers that aren't assigned to users at all. I don't think naming users
as the font of authority, who then (implicitly, I guess) delegate to
carriers authority to sign for numbers, is at all indicative of the
deployment environment or the realities of numbering. It seems to me that,
much like public ENUM, this language expresses a wish about how numbering
should work; and like public ENUM, it would have to bend the realities of
number administration, as infrastructure ENUM does, before a path to
adoption became clear.

Jon Peterson
Neustar, Inc.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 28 Jun 2013 21:09:43 +0000

Being the scope in RFC4474 is broader than this effort, how can this replace it

Martin Dolly
AT&T 

Sent from my iPhone

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 21:38:10 +0000

>deployed today.  So it may be more accurate to say that we might end up

Those "challenges" are the elements STIR proposes to fix, which are the
two I enumerated in my last mail. Or did you have some other challenges in
mind?

>And if this is the case I would ask if we really need to worry about #1 at

Are we more likely to get this up in an expeditious manner by fixing the
acknowledged problems with the existing work, or starting over from
scratch? Or let me put it this way: Ddo you want to dispense with the
concepts of an auth service and verification service, or a digest-string
canonicalizing elements of a SIP request that's signed, or a credential
for the signing authority? If all three of those seem like parts of the
solution here, then you're building on RFC4474 whether you like or not.

Sure, we could clone all of those concepts and text and build a spec that
leaves out some parts (that we don't need to fixed or even changed)
supporting greenfield identifiers, and then we'd have a resulting spec
that is like your #2. And yes, in that case no one would use #1, agreed.
Saying that "no one is using #1 because it doesn't have the fixes that we
didn't put in #1" is a pretty good way to make sure you really don't need
to worry about #1.

If we are just building on the assumptions of an existing architecture, we
could treat this work as incremental fixes to said architecture. It might
be faster. And as I said in my last mail, a verification service will
still have be aware of greenfield identifiers and SIP URI structures to do
its job, you can't make SIP URIs not a part of the architecture.

>the STIR work into that larger work?

There are no larger 4474 challenges other than the ones STIR proposes to
fix, to my knowledge. Do tell, if you know differently.

>says we need to replace 4474 we're then either trying to make it do so or

A change to the scope of the digest-string necessarily means that the
protection scope of a RFC4474bis won't be the same as RFC4474. It won't
solve all the challenges of RFC4474. Saying that we're going to obsolete
RFC4474 necessarily doesn't mean we're going to produce a protocol with
identical properties: that would make the effort a complete waste of time.
So again, I'm not sure what replacing RFC4447 really adds to the scope of
work here.

>replace 4474 and can make that decision then.

Read through the various drafts and pieces of charter text being proposed
- I'm not sure I've seen anyone considering an in-band approach that does
not effectively obsolete RFC4474. If we want the output of this working
group to be what people do in the world instead of RFC4474, then we should
obsolete RFC4474.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 21:45:40 +0000

>
>OK, but I'm concerned that if we start out with a goal of replacing
>RFC4474, that we're constrained to providing the same level of
>protection, for the same information/aspects, against the same type of
>attack vectors.  I'm *not* concerned we'll have to protect the literal
>From/To/Date/Call-ID/Cseq header field values, because I think we can
>work around those, but I'm concerned that we'll be required to protect
>bodies or even parts thereof.

A valid concern, and I agree we should not be constrained to the same
level of protection as RFC4474. In fact, the original proposed charter
text called this out explicitly: "To conform with realistic deployments,
we must also study ways to rebalance the requirements for the scope of
RFC4474¹s integrity protection to emphasize preventing third-party
impersonation over preventing men-in-the-middle from capturing media." If
you want it stronger than that, I don't object. I do think the right way
to capture it is to get precise about the threat model and the precise
types of impersonation we aspire to prevent.

>And I *am* expecting to discuss design and architecture, and don't want
>to be constrained to even having to support a URL model.  Yes one could
>put 'dns' in it, but if it would be up to the originator to decide
>whether to put 'dns' or 'http' in it, then I think there will be a
>discussion to have about that in the WG - and I don't want someone to
>just be able to say "we have to have it because it's already in RFC
>4474".  And you know people say things like that all the time in WG's,
>using the charter as a club to beat down discussion.

Um. Hmm. Is there something that the Identity-Info URI model practically
is preventing? I mean, the model is completely open - you don't even have
to execute the URI, if you have an alternate way of getting credentials
(as RFC4474 says). I was also vaguely imagining that an auth service could
put multiple options in Identity-Info, if that helps. If you explain more
what the concern is here, I'd certainly be open to finding the right
language.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 28 Jun 2013 17:47:10 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Friday, June 28, 2013 4:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Revised charter text for STIR

While I don't entirely agree with the account of numbering administration or
assignment offered below, it certainly acknowledges that entities other than
end users will sign for telephone identities. 
[RS> ] 
[RS> ]  IMHO it's the carriers and their resellers  will probably administer
STIR like services this since we tend to write them checks and they are in a
better position to do it.   Even large enterprises will end up saying.. "To
hell with this,  I outsource everything these days .. go call ATT and have
them do it.  What do we pay them for anyway? This is some "cloud" thing."

The point I raised about the proposed charter text was that I wasn't sure
what actors it means where it reads that signing authority rests with "the
entity formally assigned use of that number, or their delegate." I don't
think there really is any formal assignment, there's a loose and sometimes
convoluted process of delegation with many strange corner cases, and many
numbers that aren't assigned to users at all. I don't think naming users as
the font of authority, who then (implicitly, I guess) delegate to carriers
authority to sign for numbers, is at all indicative of the deployment
environment or the realities of numbering. 
[RS> ] 
[RS> ] Actually Jon is right here.  We all understand numbering is a
somewhat convoluted process where the end user has only a limited level of
authority over his "E164 domain."  And I use word domain deliberately. Even
though you have portability rights over your NANP number for instance
doesn't mean you can rewrite the 'zone files'  in the NPAC. No one believes
the system in the US or anywhere else is perfect, but it is what it is for
now. To  the eternal credit of the FCC, they are asking questions on how it
could evolve given the realities of PSTN Transition.  Don't delay file
today!   I have a Word template if you need one.

It seems to me that, much like public ENUM, this language expresses a wish
about how numbering should work; and like public ENUM, it would have to bend
the realities of number administration, as infrastructure ENUM does, before
a path to adoption became clear.

Jon Peterson
Neustar, Inc.

On 6/27/13 10:10 PM, "Dave Crocker" <[email-masked]> wrote:

>>> No doubt, some signers will be telcos or other operators, and this 
>>>might  seem confusing, but they are doing it /on behalf of/ the end 
>>>user.
>>>Even
>> I think many people on this list would view telcos signing as the 
>>everyday  case, and end-user signators as the exception. From an 
>>assignment  perspective, carriers are certainly not (in contemporary 
>>North America
>> Moreover there are plenty of other actors, like resellers, 
>>enterprises,  etc who are also delegates and potentially signers. The 
>>problem again with  the "the entity formally assigned use" language is 
>>that it treats the  concept of "assignee" as if numbers have a single 
>>authority, but the  reason "assignee" is a better term here than 
>>"owner" is because it doesn't  have the connotation that there's some 
>>single authority. Numbering doesn't  work that way.
>
>
>
>Values are administered, possibly through a hierarchy.  Ultimately, 
>they are assigned for 'use'.  Look into a reverse white pages and you 
>won't find reference to the telco or Neustar.  You'll find the user who 
>answers the phone.
>
>Yes, the number can be taken back from the end user, but not at the 
>whim of the telco.  And it's generally not permitted to say 'owner' 
>when a continued licensing fee is required to retain rights.
>
>
>Lastly is the role of vouching for validity.  The end user can vouch 
>for their own use, because have that authority.  But it's plausible 
>that others might do the vouching, either because the end user 
>delegated that right to them or because the services that check for 
>validity lend credence to some other agents.  This moves from a simple, 
>objective assignment-based model for validation to one that looks more 
>like third-party reputation.
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 14:52:52 -0700

On 6/28/2013 1:59 PM, Peterson, Jon wrote:
> than end users will sign for telephone identities.

Didn't know that was in question.

Rather, the questions I saw were: who is doing signing on whose behalf 
and under what identifier?  (I cited the case of a signature using an 
identifier other than the telephone number, in order to include the case 
of independently-trusted vouching services.)

An example I forgot to include in my earlier rejoinder was the traveling 
doctor show.  As with number portability, doctor portability highlights 
that vetting the number's use ultimately rests with the end user.

 >  The point I raised
> formally assigned use of that number, or their delegate."

 > I don't think
> convoluted process of delegation with many strange corner cases,

Oh.  Right.  Whether a number leads to a particular person or enterprise 
answering the phone is always questionable?  From one call to the next, 
it could land on anybody's phone, anywhere.

Methinks you've imparted meaning to the words 'formal' and 'loose' that 
are a bit arcane for the current discussion.

> and many
> deployment environment or the realities of numbering.

You seem to be confusing operational norms with administrative truths.

As I said earlier, there's certainly plenty of history to explain 
conflating the two, but they really are importantly separate topics, 
which things like number portability (and doctor portability) highlight.

> It seems to me that,
> should work;and like public ENUM, it would have to bend the realities of

I'm not understanding the reference to enum, in relation to the points I 
was making.

d/

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 21:58:15 +0000

One side note.

Please spell out whether auth means authentication or authorization.
Often folks use the two inter-changeably, but there is a distinction.

Authentication says you know who signed the assertion.
Authorization says that who signed the assertion has the number delegation
authority to do so.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Friday, June 28, 2013 2:53 PM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [stir] Revised charter text for STIR

On 6/28/2013 1:59 PM, Peterson, Jon wrote:
>
> While I don't entirely agree with the account of numbering 
> administration or assignment offered below, it certainly acknowledges 
> that entities other than end users will sign for telephone identities.

Rather, the questions I saw were: who is doing signing on whose behalf and
under what identifier?  (I cited the case of a signature using an identifier
other than the telephone number, in order to include the case of
independently-trusted vouching services.)

An example I forgot to include in my earlier rejoinder was the traveling
doctor show.  As with number portability, doctor portability highlights that
vetting the number's use ultimately rests with the end user.

Oh.  Right.  Whether a number leads to a particular person or enterprise
answering the phone is always questionable?  From one call to the next, it
could land on anybody's phone, anywhere.

Methinks you've imparted meaning to the words 'formal' and 'loose' that are
a bit arcane for the current discussion.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 22:20:18 +0000

Replying out of order (the hail of mail is deafening out there):

>Actually it's not unobtrusive.  It reveals that carriers in the middle

We need to design it in such a way that it's not that obtrusive. Roughly
what I've been thinking is that the auth service should have the option to
include more in its protection scope or not. I understand the sensitivity
here about not revealing some changes to the SDP, and in environments
where that's a concern, auth services simply will have to behave
appropriately. Ultimately, I think the security treatment at verifiers of
the two states a) "I don't know if the body was changed or not" and b) "I
know the body was changed" should pretty much be the same anyway.

A quick strawman:

Follow the example of how RFC4474 treats the Contact header (which I know
we need to move out of the digest-string, bear with me). Obviously Contact
isn't present in every SIP request. If it is present, you add it to the
digest-string; if not, you leave a gap in the digest-string for it (a
"||"). That way, if the auth service didn't see one at signing time, no
intermediary can add it later.

So imagine there's a new optional header, Identity-Reliance or something.
That header contains a sig over a separate digest-string, which for
simplification's sake right now we'll say contains just the request body.
We add a slot in the Identity digest-string for the signature that appears
in the Identity-Reliance header field value.

Thus, if you're an auth service, you have an -option- to construct an
Identity-Reliance header. If you don't build one, you just leave a "||" in
the Identity digest-string for the Identity-Reliance slot. So, if you're
an auth service acting in a context where revealing SDP changes would be a
problem, you simply don't include Identity-Reliance. If you're an
intermediary in the middle who needs to surreptitiously change SDP, maybe
if you see an Identity-Reliance header, you reject the request, perhaps
even in a way that an auth service could (if policy permits) repair it -
or if even that is too revealing, do some other sort of special treatment.

And yes, I do think partial body protection for SDP is worth some study,
and yes, I recognize that Identity-Reliance could be specified modularly
and not even be a blocking dependency for the current work. We could
define that slot in the digest string as "||" for now with a note to the
effect that it is for future use and implementations should ignore it
until told otherwise.

Is that on the right track?

>Hah!  I'm "dedicated to the architecture of SIP request bodies being
>unprotected"?!?  Yes I've dedicated my life to leaving SIP request bodies
>unprotected.  The Flying Spaghetti Monster himself came down and told me
>to never protect SIP bodies.
>

Okay, I deserved that.

>
>I don't know what I was possibly thinking when I wrote a draft that
>allows for signing the SDP or relevant parts thereof:

I know, I already wrote a note to this list about that draft. It's true it
basically does have an option for signing SDP, admittedly one with
slightly different properties than what I'd had in mind.

So I'll take that to mean that you're fine having an option for SDP body
protection. :)

>Sorry for the confusion - I thought you were saying we needed to sign
>bodies to prevent certain forms of cut-paste attacks.  Obviously pure
>"replay" attacks can be prevented regardless of SDP.  I meant more
>cut-paste attacks, as in the baiting-attack, which is a problem I do
>worry about with even just caller-id reputability.

Sure. Agreed that it does help to prevent some classes of attacks. I would
be cautious about legislating that the mechanism we create in this working
group can't provide any other security services as a side effect of its
existence, but I do understand that we're agreeing not to take detours on
our way to impersonation prevention. I don't think something along the
Identity-Reliance lines would slow us down.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 15:47:10 -0700

> Then perhaps those other things can be added in later???

The challenge is to figure out what extensibility to call for.

A generic reference to being extensible doesn't provide any real design 
guidance.  Whereas, for example, "make the crypto algorithm choices 
extensible" does.

Text that anticipates specific bits of needed extensibility might be 
quite helpful, if folks have particulars to offer.

FWIW, the discussion that's been on the list so far hasn't suggested to 
me anything I'd call extensibility.  The particular issue that prompted 
your note -- additional kinds of security functions we might want to 
add, after doing authorization validation for the telephone in the From 
field -- doesn't have obvious use that I can think of, for designing the 
initial mechanism.

Perhaps others have suggestions?

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 16:09:26 -0700

> digest-string and an addition to the types of signing authority.

Choosing between publishing credentials versus publishing public keys is 
at least one example of competing choices that are quite basic in the 
design model for this authorization validation service.

So, for example, using a DKIM-derived scheme is quite a different 
architecture from the one you've proposed.

> list: that work is specific to telephone numbers.

The experience with canonicalization algorithms for DKIM -- and it, too, 
had to deal with in-transit modifications -- makes clear that it's a 
topic with challenges and compromises.  (Hmmm.  "compromises" might be a 
pun, here.)

> If we're fixing the rest

I'm not understanding how concern for RFC4474 affects the technical work 
on this.

> isn't even a wire protocol change, as I've previously pointed out.

"new category of signing authority"?  Sorry for my confusion, but I 
don't know what that means.

> supports (including potentially dns URIs). The new work that needs to be

I missed where the DNS URI (dns:xxxxx) construct of RFC 4501 came into 
the discussion or how it's relevant.

> with the authority of the signer.

"compare the...number with the authority of the signer"?  Apologies 
again but I'm not understanding what that means.  How is "comparison 
with [an] authority" likely to play into validation?

> But even the logic that inspects the
> greenfield SIP URIs will not be conducive to a robust solution.

Specify what it is to look for and that it is to ignore everything else, 
and things get pretty simple.  It's like ignoring header fields that the 
processor doesn't know.  And it has the advantage that it's both robust 
and simple.

By the way, you seem to be using 'greenfield" as a well-recognized 
qualifier, but I can't find explanatory reference to it.  Please explain.

> I have a
> and the fact that the standardization work on that is already done.

If you said "large scale deployment and use work that is already done", 
that might be more telling...

As for the referenced overlap, that bodes well for making the later, 
incremental work tractable.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Jun 2013 04:18:20 -0400

> what the concern is here, I'd certainly be open to finding the right

So are you saying that verifiers can basically just ignore the HTTP URL?  I hadn't noticed that exception before in RFC 4474.  It seems really weird to me to do that - I mean it sounds like an interop problem waiting to happen - but I guess I'd be ok with having more unused header fields floating around.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jun 2013 07:48:07 -0700

On 6/29/2013 1:18 AM, Hadriel Kaplan wrote:
> So are you saying that verifiers can basically just ignore the HTTP URL?  I hadn't noticed that exception before in RFC 4474.  It seems really weird to me to do that - I mean it sounds like an interop problem waiting to happen

Not quite right.  There's no 'waiting' about it.  And it's deterministic.

It defines the essence of a classic interop problem, with a signer using 
one method and a verifier requiring another.  Complete disconnect.

The usual model for IETF protocols, to avoid this, is to require 
everyone to use a common, core, basic capability, and then make others 
optional, as optimizations or enhancements.

If the use of the alternative is to be /instead of/ the basic method, 
then there must be a prior negotiation between signer and verifier. 
Otherwise, the basic method is required.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 16:16:55 +0000

We do some version of this in every web browser and DNS resolver: If the data is locally cached, no protocol request is made, along with other local caching mechanism where the HTTP or DNS request never reaches the origin server named, including both transparent and explicit (redirect) caching.

As long as verifying entities have a way to fall back to retrieving content via the URL at the designated location, this doesn't seem to affect interoperability (and probably doesn't even need a detailed specification). As with all caching mechanisms, there is a trade-off between extra querying and possibly stale data.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Saturday, June 29, 2013 4:18 AM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]; Michael Hammer
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

-hadriel