Subject: Re: [stir] Credentials (-certificates-02 draft)

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Oct 2015 19:37:11 +0000

Looking at the -cert-02 draft, I did notice that it could benefit from additional information:

(1) Is the CN field in the Subject field of the X.509 structure a phone number or range?

(2) Would there need to define an Extended Key Usage OID since the existing 

TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)

Found in most web certs don't seem to fit the current usage.

Henning

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Monday, October 19, 2015 7:04 PM
To: Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [stir] Credentials (was: Encoding considerations)

I meant primarily the former, yes, the means of indicating how various bits of information useful to STIR verifiers might be associated with
X.509 certificates.

The issues around OCSP and stapling (which the room in Prague clearly found overcomplicated) are in some respects generic to SIP: one could make an argument that there should be a way to do OCSP stapling for SIP, say, as a general optimization for overall TLS usage. I didn't mean to suggest that STIR is chartered to do that work today, and perhaps that would belong somewhere else if we were to pursue it.

We have however entertained a design where the means you associate the "various bits of information" with X.509 certificates would be by reference, from an interface specified in the cert itself. Once you start going down that path, collapsing that into OCSP quickly becomes attractive (and that in turn quickly leads you to stapling). That's how the mechanics of OCSP ended up being the center of attention in that discussion.

But my point here was just to say that the approach to this in stir-certs is not required for using RFC4474bis, and that the presence of these certificate extensions should be optional: verifiers wouldn't need to use them if they had other policies for trust, and auth services wouldn't be compelled to acquire certificates supporting these proposed extensions. I still do believe there are environments where those extensions would be useful, and that it's worth pursuing this among other credential strategies. 

Jon Peterson
Neustar, Inc.

On 10/18/15, 7:49 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>Just to make this more concrete: Are you describing the need, for 
>example, to indicate how phone numbers, phone number ranges, carrier 
>identities or OCNs are encoded in X.509 certificates? (I'm trying to be 
>complete without implying that all of these are necessary or even
>IETF-relevant.) Recommendations on how to do stapling or OCSP and the 
>other revocation-related issues we have discussed?
>
>Henning
>
>________________________________________
>From: stir <[email-masked]> on behalf of Peterson, Jon 
><[email-masked]>
>Sent: Saturday, October 17, 2015 5:05 PM
>To: Paul Kyzivat; [email-masked]
>Subject: Re: [stir] Encoding considerations
>
>I hesitate to post about credentials in a thread called "encoding 
>considerations," but I would like to see if we can put the scope 
>question of the overall work here to rest and get back to the encoding 
>details for a little while.
>
>The IETF is not going to prop up a credential system for STIR. It's not 
>going to tell you whose credentials you should trust or what needs to 
>go in them. If some particular SIP deployment would like to create a 
>"Ring of Defense" model for trust based on existing web certificates, 
>then great, that deployment can trust whatever certificates it would 
>like, and that will be compatible with the encoding over-the-wire we 
>are defining here in STIR. If it isn't, then we're doing it wrong.
>
>Where the IETF does have a role in credentials is in specifying 
>anything new that credentials might need to do for our envisioned 
>deployments. STIR is chartered to produce work along those lines right 
>now, and yes, it's intended to address the sorts of use cases Paul is 
>raising (which are explicitly in STIR's threat model). But STIR 
>producing that work item does not obligate any deployment to use it, 
>any more than any IETF RFC obligates any deployment. When it comes to 
>the signing, our job is to design something that will work with 
>credentials like Richard is envisioning, and credentials like Paul is 
>envisioning. I have heard still other models for credentials under 
>consideration, like one involving OCNs, and then as Richard suggests 
>there are further signer use cases that will be orthogonal to any IETF work, I'm sure.
>
>Different communities out there want to approach credentials in 
>different ways, but it's not clear to me there's any need for an IETF 
>consensus to try to "resolve" that, or even that it's a problem in terms of deployment.
>I think it will turn out there need to be a few different approaches to 
>these credentials in the marketplace. Given that, our job here is to be 
>careful not to box our work in to a place where it serves only one of 
>those envisioned credentials and the full set our participants care about.
>If we do that, we'll be getting the scope right, I think.
>
>Jon Peterson
>Neustar, Inc.
>
>On 10/17/15, 1:35 PM, "Paul Kyzivat" <[email-masked]> wrote:
>
>>On 10/17/15 3:37 PM, Richard Shockey wrote:
>>>
>>> Disclaimer IMHO this is the way I see this if I had the magic wand. 
>>>If there is a emerging consensus on what STIR/SHAKEN is trying to do 
>>>its focus specifically on what goes on the wire and totally ignore 
>>>any discussion of how the credentails are created delegated etc. That 
>>>discussion is beyond wading in the weeds it would be rolling in the 
>>>poison ivy.
>>>
>>> I believe there is NO POSSIBLE WAY there is any support for signing 
>>>each and every TN. Its a non starter. In the NANP that is about 800 M.
>>>Yes its doable. There is ample precedent. Goodness there is some form 
>>>of RPKI for all kinds of things out there from our credit cards to 
>>>television set top boxes, but its not going to happen. The industry 
>>>will not pay for it.  Just banish that idea from any concept of where 
>>>we may be going for the time being. Oh and no one wants the mess we 
>>>saw in WEB certs. Consequently you are looking at a highly defined 
>>>delegation model.  It should not be surprising that there is a severe 
>>>allergy among TSP¹s for large numbering databases.
>>
>>I get it that this is hard, and likely won't happen any time soon.
>>And once something that works passably well is in place it will be 
>>hard to change.
>>
>>But at least it will be possible. Especially if the call can contain 
>>multiple signatures.
>>
>>> The focus therefore is on signing a claim by the originating TSP 
>>>that they trust this number ( they issued its to the consumer) and 
>>>that they are responsible for the session. Its a much different view 
>>>and a much more restricted view of what the chain of trust should be 
>>>than where I think we started.
>>
>>ISTM, at least for US providers, that will probably work reasonably 
>>well for individual numbers managed by the provider. (Not so much for
>>Nigeria.)
>>
>>I'm a little more concerned about calls originating from PBXs attached 
>>to those providers. Can we trust that the provider will really check 
>>that the number is one assigned to that PBX trunk? I have the 
>>impression that such checking is not universal today. For things to be 
>>ok I think the FCC will have to *insist* on this.
>>
>>> IMHO, and again this is not a IETF issue, the credential delegation 
>>>model would closely follow that for the numbers themselves and the 
>>>delegation is to the TSP itself and not the numbers under their control.
>>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or 
>>>so in the US and that does include Vonage and some interesting names 
>>>to follow ) and you have access to the Canadian NANP delegation you 
>>>have a little chat with the CRTC (or whomever they designate) and 
>>>pick you your private key by some trusted and secure methodology, 
>>>distribute your public keys in one of the many well known models and 
>>>start signing. If you muck things up there are some fine folks in 
>>>Gatineau ( read
>>>Enforcement) who will have a chat with you.
>>
>>If the CA chain is set up in such a way that I can simply keep a list 
>>of trusted CAs for this purpose (may be different than trusted CAs for 
>>web certs), then it seems tolerable. (Again, for the US. It is going 
>>to be hard to figure out what you can trust on international calls.)
>>
>>       Thanks,
>>       Paul
>>
>>> If folks want to do other things and want to build other kinds of 
>>>credential infrastructures to support other stuff ..fine but that is 
>>>for another time and place. Which is why I¹m very very insistant that 
>>>what ever SHAKEN/STIR looks like on the wire is fully extensible and 
>>>that the IANA considerations are as least restrictive as possible. 
>>>(!!!!!!!! NO RFC¹s !!!!!!!) Yes some of us have some very specific 
>>>use cases where different credentials might sign for different things 
>>>associated with the Session.
>>>
>>>
>>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>>><[email-masked] on behalf of [email-masked]> wrote:
>>>
>>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>>
>>>>> What you are saying is do you trust the North American Number Plan 
>>>>>delegation model.  Full disclosure I¹m a NANC member.
>>>>
>>>> I trust ATT only as long as I think their interests align with mine.
>>>> There seem to be many times when that isn't the case.
>>>>
>>>> I am much more inclined to trust their signature for a number they  
>>>>control than I am for one they don't control. So the question is 
>>>>whether  I will be able to determine if they are authoritative for 
>>>>the number  they are signing.
>>>>
>>>>> Second to you trust the authority by which the United States or 
>>>>>Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>
>>>> If the certs are tied to the specific numbers, or number ranges, 
>>>>then I  would trust them to certify "This is one of our numbers and 
>>>>we delegated  it to ATT".
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Frankly I don¹t care one way or the other.  The first order trust 
>>>>>model IMHO is do I trust ATT [my mobile provider] to give me 
>>>>>accurate information on who THEY trust.  I pay ATT by the way, 
>>>>>quite happily and Verizon for my trustworthy FIOS landline.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>>><[email-masked] on behalf of [email-masked]> wrote:
>>>>>
>>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>>> Most of the abuse comes from pink enterprise, so where do we 
>>>>>>>>draw the  line
>>>>>>>
>>>>>>> A couple of answers come to mind:
>>>>>>>
>>>>>>> - I only trust the enterprises I want to trust
>>>>>>>
>>>>>>> - The delegation model is tied to the cert chain. So I can trust 
>>>>>>>the  signature if I trust the CA. (ACME Corp obtained the number 
>>>>>>>from  ATT.com, so ACME's signature uses a cert with ATT as the 
>>>>>>>CA, and I trust
>>>>>>> ATT.)
>>>>>>
>>>>>> Or, better, ACME got the number from ATT and ATT got the number 
>>>>>> from FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> stir mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>
>>_______________________________________________
>>stir mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir
>