Re: [stir] current draft charter

["Peterson, Jon" <[e-mail]>]

On 6/16/13 10:32 PM, "Dave Crocker" <[e-mail]> wrote:

>[snip]
>>
>> I addressed that in my last mail. The "guy being validated" provides a
>> pointer to the cert, yes, but whether or not you trust that cert is a
>>fact
>> about your relationship to the CA that issued it.
>
>Then what is the point in having the pointer, rather than letting the
>validator decide where to get the cert from?
>
>I suspect the answer is that it's a search efficiency hack, rather than
>a required mechanism, helping to find a knowledgeable CA amongst
>potentially thousands.

I wouldn't say that's an unfair characterization. It gives the
verification service quick and easy access to the right cert, provided of
course that the signer provides the right cert. Otherwise there would have
to be some kind of cert discovery process implemented by the verification
service.

>>
>> Alice is not the signer, or owner, in this use case; the authentication
>> service is implemented by an intermediary. The intermediary is the
>>"owner"
>> (in the sense I'm guessing you) of the domain name that appears in the
>>URI
>> Alice puts in her From header field. I don't want to get too entrenched
>>in
>> terminology that we're unlikely to use here, but Alice only "owns" her
>>URI
>> to my mind in so far as it was allocated to her by the owner of the
>>domain
>> name  - they get to choose who gets to be [e-mail] and who gets
>>to
>> be [e-mail]. If they decide they don't like me anymore,
>> [e-mail] can vanish in the blink of an eye.
>
>That has become nicely confusing (for me.)
>
>The basic entity of interest is the phone number.  The basic ownership
>of internet is for the phone number.

Perhaps this has become confusing for you because RFC4474 doesn't make any
real provision for telephone numbers, but you're trying to read telephone
numbers into the RFC4474 text. Think like RFC4474 is only talking about
user@domain URIs. The proposed STIR work is, in part, to broaden the scope
of identity protection to include telephone numbers.

>
>Who owns the validating service is (or, for this topic, should be)
>secondary.
>
>
>>>     Section 5, Step 2:
>>>
>>>     The authentication service MUST determine whether or not the sender
>>>     of the request is authorized to claim the identity given in the
>>>     identity field.
>>>
>>> ditto.
>>>
>>> What you've defined permits multiple, separate third-parties to be able
>>> to make validity assertions about the use of the caller-id value.
>>
>> What we've defined allows the owner of example.com to decide who gets to
>> be [e-mail] and who gets to be [e-mail]. It doesn't allow
>> multiple entities to be example.com.
>
>That's not the constraint I read in the RFC.  What you've just described
>here is ownership of the string being validated.  In the SIP case, that
>means ownership of the phone number.  RFC 4474 does not specify that,
>according to my reading of it.

RFC4474 does not cover telephone numbers - we propose to fix that with
this new work.

>> Now that much said, if the relying party trusts thousands of trust
>>anchors
>> a la web PKI and we're in that space, then sure, there's always the
>> potential for mischief we've seen lately in web PKI.
>
>As I understand it, this model of thousands of trust anchors is showing
>some very rough edges for scaling, accuracy, and scope. I believe it
>also has had a single semantic, unrelated to the one being proposed.

Right, the rough edges there are why the current problem statement for
STIR suggests we do things a bit differently.

>>> The idea that an authorization-checking mechanism would somehow depend
>>> upon the SIP routing service doesn't make obvious sense to me.
>>> Consequently I do not see how it should/can/will affect choice of the
>>> validation query service.
>>
>> It's a subtle point, again dancing around the questions you were raising
>> about "owning" names. One of the reasons RFC4474 adopted the design it
>>did
>> was because the "owner" of example.com controls what traffic goes to jon
>> versus dave in the RFC3263 model, and authenticates jon or dave when
>>they
>> register to receive traffic.
>
>I think I'm beginning to understand:  The provider that is giving SIP
>service is the one that vouches for its use.  In effect, the provider
>has the authority of the number owner, rather than the user to whom the
>number is assigned.

Almost - again, RFC4474 doesn't cover telephone numbers, and neither did
RFC3263.

>That's not subtle; it's quite basic.  It would be like requiring that my
>ISP be the one that vouches for my use of my domain name.

If your ISP actually owned your domain name instead of you, sure. If in
fact you own your own domain name, RFC4474 lets you (as in, your UA) act
as your authentication service. The authentication service is a logical
function that can be instantiated by either the UA or an intermediary. Who
should do it depends pretty much entirely on who owns the domain name.

Do I own the email address "[e-mail]"? No, Neustar owns
it. I use it at their pleasure. If our IT staff wanted to, they could send
all my email to someone else in the company. I do own my own domain names,
though, and I control who gets what account under them. Since there are
similar use cases for SIP, we included this use case in RFC4474.

>> The trust relationships that were built for
>> that served as a model for the use case you were reviewing above, where
>> Alice authenticates to a local intermediary that instantiates the
>>RFC4474
>
>This sounds like a transitive trust model based on trust amongst telcos.

Not really. example.com gets to vouch for example.com addresses, and the
signature they add is end-to-end visible to verification services
implemented at intermediaries or at terminating endpoints.

>> authentication service role. In cases where those registration concepts
>> and routing concepts don't conform to the expectations of RFC3263 (which
>> includes routing to E.164 numbers), the assumptions of RFC4474 break
>>down.
>> Just giving more color on why RFC4474 didn't set the world on fire.
>
>+1
>
>
>>> The essential point behind this line of discussion is that an entirely
>>> new cert semantic and trust structure will need to be invented and
>>> deployed.
>>>
>>> Note that this must be globally integrated and openly accessible.
>>
>> I'm not sure it's a new cert semantic, or a new trust structure, or that
>> something needs to be "invented" to support this.
>
>Feel free to point to instances of each that are deployed and used.

The structures that underly trust in the proposed STIR work are simply the
extent ones in the telephone network. There are currently number block
assignees, delegates of those assignees, and ultimately end users who
possess numbers. Databases exist that contain all that information, and
credentials exist that reflect those scopes of authority. The proposed
work is only to leverage those structures.

Certs have I believe had the capacity to contain telephone numbers since
X.520 or so.

Jon Peterson
Neustar, Inc.

>Absent that, we can all be quite sure that all three assertions are...
>valid.
>
>d/
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net