Minutes IETF105: stir
minutes-105-stir-00

STIR WG 
IETF 105, Montreal, CA
Monday, 22-Jul-2019 10:00-12:00 Duluth

Summary: 

Discussion of draft-ietf-stir-cert-delegation expanded to take the
entire hour, and will continue on list. The chairs will schedule an
virtual interim in September to follow-up and to make progress on
draft-ietf-stir-passport-rcd.

------------------------------------------------------------------------
Detailed Minutes:

Administrivia 
Chairs: Robert Sparks, Russ Housley
https://datatracker.ietf.org/meeting/105/materials/slides-105-stir-chair-slides-00

Minute Taker - Jean Mahoney
Jabber Scribe - Eric Burger

slide 1: Title

slide 2: Note Well

slide 3: STIR WG Agenda

Robert - anyone have an agenda bash?

Brian Rosen - I would like to talk about emergency calling and what would
be necessary to make a call back from the 911 system.  If the 911 system
wants to, and they often don't, show a 3 digit number.

Robert - if there's time.

Martin Dolly - IP-NNI is working with ECIF to define requirements for
when 911 is dialed getting to PSAP and getting a call back.

------------------------------------------------------------------------
STIR Certificate Delegation
draft-ietf-stir-cert-delegation
Jon Peterson
https://datatracker.ietf.org/meeting/105/materials/slides-105-stir-stir-certificate-delegation-00

slide 1: Title

slide 2: draft-ietf-stir-cert-delegation-00

slide 3: Why are we talking about this?

slide 4: SPCs and TNs

Mary Barnes - There are non-carriers that have OCNs.

Jon - Yes.  The draft doesn't say, don't do that.  There are cases where
you want to do that.  There are other cases, say, an enterprise that has
had numbers for twenty years, nothing gets ported in or out, they're
contiguous.  It might make sense for these entities to use TN blocks
themselves in the certs.  One size doesn't fit all.  Sometimes OCN is
overkill.  The hard edge is the concept of "encompassing", we stole this
idea from RKPI.  This is an open issue in the draft - the terminating
side needs to determine if the call should have been signed by the
signer.  Need to understand where in the architecture to make the
encompassing check.  Could do it when certs are issued or realtime during
call processing at the VS.  Could impact call setup time.  Could do it in
both places.

Mary - We have a dependency on existing identifiers assigned to service
providers.  Complicated because of number portability.  If you check on
the verification side - have to check in more than one place.  You could
do it on the authentication side - bind the CA token with the OCN and the
TN.

Jon - This architecture would allow you to bind an OCN to OCN as a
delegation.

Mary - We have the notion of overall OCNs as well. 

Jon - Where do we want the authority and responsibility to reside in the
architecture?  My preference is that it happens offline rather than
during call processing.

Mary - Whether or not we can make that decision here, we need to provide
the tools.

Jon - We do the plumbing here.  We can offer guidance on tradeoffs.

Mary - I don't think we'll say you can only do it this way.

Jon - I wouldn't leave the certification out.  The AS is also during call
processing.

Mary - Can do it with the SPC token.

Jon - You could. 

Chris Wendt - It should be possible to do lookup on LERG and NPAC and
there's a mapping there.  Enable on both sides and let folks chose the
front end or back end.

Jon - Definitely.

Chris - The key is that the end-to-end can be validated on both sides and
you don't have to trust one side over the other.

Jon - Verification services are going to access all kinds of analytics
before alerting a user, any number of checks can be performed.

Russ (WG Chair hat off) - The CA should check what it can before it
issues the certificate; this is important for the reputation of the CA.
There's an interval where certificate is valid, but things around it
could change.  Allowing validation later is not a bad thing.  We need
to accommodate those checks by people who can't do an NPAC lookup.

Jon - That's the virtue of having the TNs be inscribed themselves for
these enterprises in cases where it does work.  Having TNs in there helps
the verification service that normally doesn't interface with the NPAC
and the LERG.

Richard Barnes - +1 to what Russ said - the CA should verify things -
those are ground rules for PKI.  Need to make sure we're not engineering
ourselves into a circle.  If these things can only be verified by doing a
live check, the PKI is not adding value.  Given the sunk costs for PKI
concepts, don't throw that way.

Sean Turner - I don't know how you would write a CP that says in the
validation section, "put whatever you want in there."  No relying party
will buy into that.  You have to do pre-validation somewhere, otherwise
what's the certificate good for?

Jon - It puts a requirement on the CA to have access to those resources.
Need to note in the architecture.

Mary - As long as CAs are willing to buy into it.

Jon - The CA and PA functions are modularized in SHAKEN.  We don't design
SHAKEN here.  We aren't going to decide whether it is the CA's job or the
PA's job.

Mary - The databases are not real time.  Daily downloads are a newer
feature.

Chris - The CA should be able to rely on the authority token.

Jon - Agreed.  This is part of why we're not saying what we want to do in
ACME because we're trying to figure this out.

Richard - The "A" in "CA" is authority.  They exist to make statements
upon which other parties rely.

slide 5: To CA or not CA?

Eric Burger for Wilhelm Wimmreuter - Do they want to delegate Endpoint or
CA-Issuing certificates?

Jon - We are talking about potentially delegating CA-issuing
certificates.  Multiple chains of delegation - SPs that get numbers from
a carrier that then provide those numbers to multiple customers.  I can
imagine multiple levels of delegated certificates.  For typical
operations, you as carrier would give your enterprise an EE certificate.

Sean - If you decide to do TLS subcerts, you will get free security
analysis to make sure you aren't blowing up TLS.  This idea might be
better because there will be a formal proof to show the security works.

Jon - My preference is classic X.509 delegation with the CA bit set.  If
there is a market constraint against that, I would be willing to build a
variant of subcerts just to get something out there, but that is not my
preference.

Max Pala - What about proxy certificates that are X.509 certs with
everything just restricted delegation.  They are meant to delegate to
someone else without being CA.

Jon - There is not a lot of them support the narrowing of the scope of
the name.

Mike - It's up to who is validating the certificates.

Jon - We want the CA to tell you what you need to do to validate without
having to do an external check.  If we hope to build that into the
certificate, we need something that has a particular set of qualities.
Think about RPKI encompassing, if you have a /16 and you want a subcert
for a /24, does that work with proxy certificates?

Russ - Yes, but not using the name constraints extension. 

Jon - We don't use classic X.509 name constraints.  We can look into it.
Good suggestion.

Cullen Jennings - Either of these paths solve the problem.  I lean
slightly toward subcerts.  When I tell an operator or an SP that they
will need to manage private keys for a certificate, they say, "Oh, no!"
But if I tell them that they need to manage a token that enables you to
do everything, they don't have problems with it.  One's easy, one's hard,
but they're the same thing.

Richard - I lean slightly the opposite.  The X.509 delegation is cleaner.
There's more machinery, it just works.  The subcerts can be made to work,
but it's greenfield, would have to add stuff to make it work with
multiple levels of delegation.

Jon - We would have to do another draft.

Richard - There's running code though.  You won't get the
interoperability that PKI has.  Between STIR-specific PKI and subcerts,
might be a tie.

Clint Wilson - I lean towards the subcerts.  We've working on
implementing, it's more tenable from CA implementation perspective.  The
X.509 delegation is a big no-no in web PKI, harder to make ... that
supports that ability. 

Jon - I am sympathetic to that.

Nick Sullivan - TLS subcerts is a key delegation, not a credential
delegation.  It takes what's valid in the certificate and narrows the
scope.  I don't see a problem with making a different variant.  This
draft is for key lifetime narrowing.  I can see something completely
different based on this work.

slide 6: Smaller Questions

Jon - Are we locked into x5u?  Is there too much code out there?
Probably better to use x5c.  Chris, what do you think?

Chris - I need more detail.

Jon - The JWT can use either x5u or x5c. 

Chris - The chain is separate?

Jon - It would be more syntactically accurate to use x5c to point to that
chain.

Richard - It's just a value or reference question.  The x5c is a literal.
On x5u, can you provide multiple certificates in the response?  I think
it is the case.

Jon - I thought it worked.

Mary - I like the x5c.  We're discussing how to do the chaining in
SHAKEN.  The x5c gives us desirable properties.  Chris is shaking his
head.  We need to talk about it. 

Jon - We can say, let's allow either.

Jon - Is there value in the "good bit"?  Some CAs can do the validation
against these databases, others can't.  Maybe it would make sense to have
a distinction between those CAs.  Those that can't do the validation
would set the bit to no.  Maybe no one ever shouldn't?  I hear a vote for
that.

Chris - I was reading the JWT thing. 

Jon - Mary was saying she wanted x5c.

Russ - I'm concerned that this has turned into an NPAC-centered
discussion.  We need a solution that will work worldwide. 

Jon - Yes.  These tools will work worldwide.

Chris - You can chain or certificate pointed to in both x5u or x5c.

Jon - Let's keep x5u for now.

Eric - As a validator, I can see that the good bit is good information
that I can take into account.  But I can also see it as a restraint of
trade.  Only special people get to be really good CAs.  We can discuss on
the list whether people would use it, or is it just more lines of code to
write?

Jon - We don't want to create 2 classes of citizens, and suggest one of
them is bad.

Richard - If the good bit is false, and the encompassing semantics have
not been verified.  What is the semantic that the certificate supposed to
convey?

Jon - It conveys who the parent is, what their OCN is, what has been
attested.  You might want to make sure it's correct.  I can imagine the
case where you are doing a sub-delegation from a TN range to another TN
range, you can look at it and know.  No need to look at an industry
database.  It wouldn't require setting the good bit for you to be able to
trust it on the verifying side.

Richard - What would the semantic of the good bit being true be?

Jon - The good bit is not relevant to that case, it doesn't need to be
set.  The good bit would be relevant to its parent, from getting from an
OCN to the initial TN range.

Mary - You are correct.  It increases the confidence.  It can add to the
analytics.  We are building up information of what we know.  This isn't
as deterministic as you would like.

Richard - Usually when an authority signs a certificate, it is saying it
has verified it.  Here that statement is a one of a collection of facts.

Jon - It is merely an input to broader analytics.  I would be content to
dispense with the evil bit, I mean good bit, and just have the
certificates.  If a CA is issuing them, it makes sure the encompassing
semantics have been validated.  It is auditable offline.  There are not
that many certificates.

Chris - Being able to check 2-3-4 different ways is always good thing.

Jon - We want to be able to verify in as many ways as we can.  We want
this to work with as few shenanigans as possible during call setup time.

slide 7: Next Steps

Jon - Anyone think we're asking the wrong questions?  Anything else we
should be doing?

Martin Dolly - We talked about delegated certificates with our IPPBX lab
in Middletown; will they do verification of IPPBX before they connect to
our network?  They unanimously said hell no.  I shared this with IP-NNI,
and I am sharing it here.

Eric - Why?

Martin - In the early 2000s, the IPPBX community was pulling IT functions
into the enterprise, then later the pendulum swung, and the enterprises
wanted the carrier to do more on their behalf.  Today, with cloud, it's
moving further away from the enterprise.  Our vendors and customers are
not going to be doing things like this.  In AT&T Flex ... servers our
biggest servers, in our database, we have a list of numbers that our
customers are using that are AT&T's, numbers that are customers are using
that come from another carrier, we added a field for vanity numbers for
display.

Cullen - I'm confused.  I'm the CTO of the largest enterprise vendor of
enterprise PBXes, and I know we want this, and we are implementing it,
and we want to delegate it.  I believe what you are saying, but there is
some miscommunication between the two of these.

Jon - I have also talked to enterprises and carriers that want to
delegate.  Some people may not want to delegate, and that's okay.

Martin - Cisco was one of the vendors that I was speaking about.

Cullen - Martin, I know you heard what you heard.  There are people
moving more services to the cloud.  That's pushing a need for the
delegation even more.  We could pull information from the vendors and
find out what the actual need.

Jon (going back to "Why are we talking about this" slide) - The
motivation "push credentials from TN owners to an AS able to sign for the
call" does not necessarily mean the enterprise will have these delegated
certificates.  Maybe it's a cloud service or the outbound carrier.
Martin, maybe your service will get the delegated credential from Verizon
to sign for numbers that are for Verizon's customers, and you'll be the
one using it.  My greatest fear is an outbound carrier that signs even
though they don't own the number with credentials that have no
relationship to the ownership that number, and we end up right where we
started.  We have to get past it.

Chris - The 2 use cases I see most are not PBX, but VOIP providers that
do not have direct access to TNs and want a solution.  We have wholesale
customers that support this work.  And the other, outbound call centers
that want to sign the call and control what's being to shown to their
customers.

Eric - I would offer that the last two statements [on the slide] are dead
wrong; delegated certificates will make it better.  When AT&T gives
attestation to Fidelity, that's enough for realtime blocking, for
penalizing them if they're lying.  Making statements that AT&T is going
to break --

Jon - I didn't say that.  It's fine if AT&T does for Fidelity, but not so
great if other carriers with different policies do it.  It's a
goose/gander problem.  From a goose perspective, I don't want to have to
do a lot, I just want to sign things.  The problem is the verification
side once this gets to the gander.  This could tank this entire effort.

Eric - Is this because of the focus of what is an attestation?

Jon - The attestation levels are a factor, but I'm concerned that there
is a class of carriers before STIR/SHAKEN came along who were willing to
send illegitimate calling party numbers out into the telephone network,
that are responsible for impersonation, voicemail hacking, and robo-
calling.  If we say, "Hey it's okay for carriers to sign for whatever
number they want" - with the best intention of having a set of reliable
carriers, is that these irresponsible actors will leverage that to
continue to impersonate.  Except now it will be signed with STIR/SHAKEN,
and we've accomplished nothing.

Eric - They will find themselves at the wrong end of an enforcement
action.

Jon - They will in trace-back terms.  It will take three months.

Eric - It will be a lot faster.  That statement is not helpful.
 
Jon - Real-time blocking and authorization have changed the story a bit.
Attestation is orthogonal to this.  You need the information in real time
if you're going to do real-time blocking.  Trace back has a different
purpose.  I don't see the word attestation on here.

Eric - Why do you say this doesn't enable real-time blocking?

Jon - If the principle you're willing to accept is: "Okay, this was
signed for by a carrier, someone who NECA is willing to give these
things."

Eric - And if that carrier is known to be delivering bad stuff and that
number was signed by the carrier, it will get blocked.

Jon - I said it was a good start.

Eric - That's not a trace back thing, it's a whack the call thing.

Jon - It's a real-time after trace back.

Richard - Your assumption is that there some service who will tell me who
the bad OCNs are, bad carriers.  Someone's has get on that list first,
then they can be subject to real-time enforcement.

Jon - And that is based on a pattern of bad behavior.

Richard - There is validation of the control of the assets upfront.
Someone cannot sign something they do not own.

Jon - Even better.  Good start does not mean that it does not work.

Ted Hardy - In other carriers, one of the issues is that it is relatively
easy for somebody who wishes to behave as a gander to mint a new
identity, and become a gander over and over again with new identities.
This occurs in spam and impersonation, it occurs other places.

Jon - This is question of how Newco works, and how you get OCNs.

Ted - Is there a way for somebody who has previously been given an OCN,
which has ended up on this list, to be traced to future applications to
the same authority or not?  If the answer is no, then you are setting up
a periodicity that's related --

Jon - I get it.  It isn't quick, but there's are a lot of them out there.
Some people may have opportunity to cycle through them rapidly, but it's
a relatively constrained resource.  They're relatively difficult to get.
There could be analytics that could let you make correlations, but it's
tricky.

Ted - In this case, since the OCN is relatively difficult to get, the
threat model is whether the burden of creating a new OCN is met by the
financial gain of being willing to be the originator of this sort of
traffic.  We could figure out where that break point is.  That turns the
question into whether the better situation where you never have to go
through this 15 minutes already.  You never have to do this OCN lookup at
all.  Is it worth the the additional effort and money that will go in to
enabling these other use cases?  There's a risk here, which is not the
same risk we see in environments where they're freely minting identities.
It is not clear how that risk/reward will match once this is very common.

Jon - There are more wrinkles.  Pseudo OCNs, like SPCs that are not quite
OCNs, could have very different properties in terms of how they acquire
them and how quickly they can be correlated.  There's a lot of edges that
we'd need to analyze.  I was not trying to pick a fight with this, and I
apologize if the way I put it was divisive.

Mary - The overhead of getting another OCN won't be worth the effort.

Jon - But if it's a pseudo OCN -- 

Mary - They have to go through the rigamarole of setting up an account
with the PA.

Jon - Depends on how they are issued.  If it depends on the PA to issue
them.

Robert - We are out of time.  We will set up a virtual interim in early
September.  I'll send out a poll.

ACTION: Robert to send a poll for virtual interim meeting in September.

Russ - Let's keep the discussion going on the list.

[ End of meeting; ran out of time.                                        ]
[ Agenda topics for draft-ietf-stir-passport-rcd and updates on post-WGLC ]
[ documents draft-ietf-stir-oob and draft-ietf-stir-passport-divert were  ]
[ not covered.                                                            ]