Subject: [stir] Charter

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 1 Jul 2013 19:33:49 +0000

Greetings,

Where are we at with the charter? And who has the power of the pen?

Are charter updates reflecting the list consensus?

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 12:41:42 -0700

> Are charter updates reflecting the list consensus?

Yeah, we should try to close this.  Thanks for raising it.

I've assumed that I should fold in revisions and re-issue, but I raised 
some questions that I don't think got resolved.

For convenience, here are the items I think are still open:

> Subject: Re: [stir] Revised charter text for STIR
> Date: Thu, 27 Jun 2013 16:43:29 -0700
> From: Dave Crocker <[email-masked]>
...

>>> 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.
>>
>> 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.

Keep/Drop??

>> 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.

OK to change to this?

>>> 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.
>>
>> All good.  Perhaps a sentence about why we think the time is better
>> now would complete this thought.
>
> uhhh... sure.  Feed me.

I'm still unfed.  Anyone have a sentence to offer that will satisfy this 
suggestion?

>>> 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
>>
>> 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.
>
> 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.

To confirm, I think this reduces to removing all references except the 
problem statement.

>>> 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.
>>
>> 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. }

Use the new text I suggest?  If not, someone needs to offer an 
alternative that folks like better.

>>> - 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.
>>
>> 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.

H E L P!  I don't know what to replace this with.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net