Subject: [stir] Draft minutes for STIR at IETF92

From: Robert Sparks <[email-masked]>
Date: Wed, 08 Apr 2015 14:19:12 -0500

Draft minutes are available at
http://www.ietf.org/proceedings/92/minutes/minutes-92-stir
Please send any additions/corrections to the list or the chairs before 
May 11.

Thanks go to Eric Burger for the excellent notes!

RjS

---

From: Eric Burger <[email-masked]>
Date: Wed, 15 Apr 2015 06:23:05 -0400

The minutes state:
> Authorization check options:
> Do we need to check if a particular number is in the scope of validity for a cert, or do we need to list the numbers asserted in the certificate? After lots of discussion, just want to know if the certificate covers the number.
> Eric offers that it is not practically useful to worry about revocation. Not knowing whether a particular signer is authorized to sign for a number RIGHT NOW will make no difference in user behavior.
> Jon thinks Eric is saying it does not matter what number is in the certificate. Violent discussion ensues, as Jon is arguing the whole point of STIR is to have the number in the certificate and Eric is arguing it does not matter if the attestation has not been revoked. Realization hits as room falls asleep.

I thought it would be good to expand on what I was trying to convey at the meeting. The whole point of STIR is to authenticate the number being presented to the called party. As such, the whole point of the certificate is to attest the number being presented is the number of the caller.

The debate was about what level of perfection do we need in the real world to make STIR useful. What I was trying to lay out is the argument that real-time verification of certificate validity is not necessary to achieve the goals of STIR.

To recap: we need a mechanism whereby a service provider vouches for the identity of a caller. In the U.S. market, it looks like we are converging on using the X.509 model of a single, national root CA. The root CA delegates signing to various registered and regulated service providers. Those service providers issue certificates to end user devices, asserting the identity of the end user, specifically (in the case of STIR), the end user’s “phone number” or, colloquially, their Caller ID string. Redundantly, we use the X.509 certificate’s private key to sign the asserted Caller ID in the SIP signaling.

Here is an observation: with sufficiently short certificate lifetimes, having an on-line validation check of the certificate does not materially impact the integrity of STIR with respect to its promise of authenticating the caller. Let us say the service provider issues certificates with two week lifetimes. This is a reasonable assumption as the presumption for the whole STIR mechanism is certificate management is remotely managed by the service provider. The reason that is a reasonable assumption is the IETF itself has shown it cannot reliably manage to manually keep the IETF.ORG certificate up to date. If we cannot do it manually, grandpa in Iowa is certainly not going to manage his phone's certificate manually. Anyway, what are we protecting against? We are protecting against the end user lying about their identity. First off, they cannot put something in that is different than what the service provider is attesting is their number. Why? Because the certificate, generated by the service provider, cryptographically asserts what the number is. Any mismatch between the number in the certificate and the number asserted in the SIP signaling is an authentication failure.

But what about number porting, you might ask? Let us say an entity gets service from provider T. With that service, the entity gets a phone number N. Now let us say some time later, the entity ports their service to provider V. On porting, provider V issues a new certificate for number N.  When the entity places a call now, they might try to be nefarious and use T’s certificate. However, for the purposes of STIR, the fact the entity uses the ‘wrong’ certificate is irrelevant. The ‘wrong’ certificate still only allows the entity to make an assertion on the number N, which does not change in the porting process.

By having a relatively short lifetime for the certificate we ensure that someone does not grab a number, release it, and then masquerade later as being the authoritative owner of the number. Two weeks is well short of the usual number fallow period, so that alone eliminates this problem. Someone might try to be nefarious and attempt some SWATing or robocalling after they ‘disconnect’ service. In this case, it will be obvious who is doing the calling, as one and only one entity will have the certificate, given the certificate’s limited lifetime.

One objection privately raised after the exchange is what happens if an entity in the signing chain becomes compromised. Let us take the easy one first. That is the case where the Grace L. Ferguson Telephone And Storm Door Company’s [1] loses their certificate and someone nefarious starts issuing certificates in their name. This is also known as the DigiNotar case [2]. There is an easy / modest solution to this problem and a hard / hard solution. The easy / hard solution is to limit the lifetime of the intermediate certificate. That is easy, because client devices need do nothing. When they validate the certificate issued by the compromised intermediate CA, they will notice the CA’s certificate, issued by the root CA, has expired. It is modest for the service provider because it means they need to be sure to use their latest certificate when they generate their customer’s keys. That is not at all onerous, but it is not free. The hard / hard solution is an online check like OCSP. It is hard for the user and end user devices, because it means on-line in-line checking of inbound signaling. It is hard for the service providers because they have to keep the OCSP lists up to date.

Now for the hard one: what happens if a national root CA is compromised? The best I can say is all bets are off. Short of the kind of update that followed DigiNotar, I am not sure how, using an X.509-based system, one can deal with securely updating devices. With the root gone, the device literally cannot trust anyone. This is a clue that end devices will need multiple roots installed, so that if one root is compromised, another authentication chain can be used to update the end device’s root store.

In short, OSCP or other on-line checks of end device certificate validity adds complexity and cost, which will inhibit deployment, allowing the SWATers and robo callers to continue their evil ways.

[1] http://en.wikipedia.org/wiki/Bob_Newhart#Personal_comedic_style
[2] http://en.wikipedia.org/wiki/DigiNotar

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Apr 2015 09:45:38 -0400

I think you are making assumptions that many of us are not making.

One of them is certificate per number.  ISTM you are assuming each number gets their own credential.  Many of us are not assuming that.   Credentials holders should be able to manage mapping of number to credentials from one per number to one per holder.  If you have multiple numbers per certificate, potentially millions of numbers (if a big carrier decided they wanted one credential for all their numbers) then you need something that tells you that the certificate is good for that number.  That same query, whatever it is, can also attest to the validity of the cert.  Whether you actually use something like OCSP, or you just try to follow some URI to get a list of numbers associated with the cert, you can get the validity of the cert, for that number, determined reliably.

The other assumption you are making is that certificated carrier is by definition “good” and other entities don’t manage certificates.  Many of us don’t subscribe to that notion, and don’t plan to have any special status for certificated carriers.  Any delegation gets recorded in a database.  There need not be one database, but it’s not database per certificated carrier.  As you heard in the meeting, regulators  (and not just in the US) are rethinking to whom numbers are delegated, and the notion that certificated carriers have some special status with respect to number delegation is becoming obsolete.

I do think that implementations need to plan for the possibility of compromise of the root key.  We need to be able to change the root key, any sub-root keys and re-issue all certificates in a short time period.  If you can revoke a key, then you need something (CRL or OSCP-like) to check that.  I believe that two weeks of compromised keys is unacceptable, so I believe we want an on-line real-time validity check.  I think in the scheme of things, that’s not a big increase in complexity of deployment.

I think all of this is one call to a database where you send the credential and the TN and get back a yes/no.  You can imagine ways to optimize the entire mechanism of start with a signature and a URL to a credential and end with a yes/no for the entire checking process (fetch credential, validate it, check signature).  

Brian

> On Apr 15, 2015, at 6:23 AM, Eric Burger <[email-masked]> wrote:
> 
> The minutes state:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir