Minutes IETF97: stir

Meeting Minutes Secure Telephone Identity Revisited (stir) WG
Title Minutes IETF97: stir
State Active
Other versions plain text
Last updated 2016-11-23

Meeting Minutes

IETF97 - Secure Telephone Identity Revisited (STIR) Minutes


draft-ietf-stir-rfc4474bis, draft-ietf-stir-passport, and
draft-ietf-stir-certificates are in IESG Evaluation, and a few
discuss positions have been entered.  The group briefly discussed
the most significant changes likely to be made to resolve the
discuss positions for the stir-certificates document.

There was strong consensus in the room to add PASSporT extensions
and using ACME for STIR certificate enrollment to the working group's
charter.  Proposed charter text will be sent to the working group mail
list shortly after the meeting.

Raw notes taken by Jean Mahoney during the STIR WG session follow.

Wednesday 0930-1100

0930 ( 5m) : Administrivia (chairs)

Note taker: Jean Mahoney
Jabber scribe: Matt Miller

slide 1: Title

slide 2: Note Well

slide 3: Agenda

Russ Housley - No changes to the agenda. 

0935 (10m) : Status of rfc4474bis, passport, certificates (chairs)

Robert Sparks - All in a position of discuss clearing. probably won't come
back to the WG.

Jon Peterson - Steven had a large issues list on the certs draft. Can work
through it. The main one is the PERPASS implications for the OCSP validation
of TNs. Parties for realtime validation would be sending over the wire the
question: Is the cert valid for the number?The answer is unfortunately sent
in the clear. We will roll back the strength of the recommendation. Look at
other cert strategies - short-lived certs. We may kinda punt on this. The
certs document will cover some strategies but won't recommend OCSP like we
did. Any issues?

Russ Housley - There's another aspect to this - Either the Security
Considerations section is going to explain or there will be a new Privacy

Jon - We will call out the issue. I'm inclined to roll back the
recommendation, and describe a couple of ways to do it. We'll need to
experiment before realtime validation before making a strong recommendation. 

Russ - I agree, but about short-lived certs - if they are short lived enough,
you don't need to any revocation checking, you include the no rev check

Jon - I'll talk about it in the stir with acme presentation.

Eric Rescorla - short-lived certs are a viable option. The current OSCP
design - OSCP server is an oracle that maps SPIDs to TNs. If you are going to
map the cert system, you need something acme. I have a credential that
authorizes that that SPID. When I need it I get a cert that validates the TN
not the SPID. Otherwise there's not way to validate the SPID. Need a separate
SPID resolution mechanism.

Jon - a separate SPID resolution mechanism for SPID to TN.  Nothing in the
doc says that you have to perform that check.  We can find an oracle that can
do that translation.

ekr - for those not familiar with SS7, if you could provide a layout of what
those options are. 

0945 (35m) : Out-of-band (Jon Peterson)

slide 1: Title

slide 2: Thread necromancy

slide 3: Do we still need it?

slide 4: Limits of in-band RFC4474bis

slide 5: PASSporT and out-of-band


slide 7: Basic STIR Out of Band

slide 8: Obvious Questions

Jon - If you squint at it, looks like VIPR. VIPR had problems. There's a DHT
way of doing it, locate CPSes. LoST, DNS. Lot of options. Don't need to
standardize just one as the One True Way. 

slide 9: Components of an OOB solution

slide 10: Another Case: IP-PSTN Gateways

slide 11: and its many cousins...

slide 12: IP-PSTN-IP even? Sure!

Jon - SS7 indicator doesn't handle this very well. 

slide 13: Well, let's not get carried away

Jon - Doesn't matter to the CPS who stores the information. It just looks at
the passport itself, is it valid. 

Chris Wendt - You want to limit writing, but need to be open from a reading
perspective. The problem with the passport object has all CDRs in it. 

Jon - this depends on your key for retrieving CPS. 

Eric Burger (remote) - MIC: except for providing an easy point for pervasive
metadata monitoring, why do we require a CPS instead of an end-to-end
transfer of the PASSportT token, where we can use all of the IETF end-to-end
integrity mechanisms to (1) deliver the token and (2) ensure its integrity?

Jon - This is for cases where there is not an e2e IP connection between the
authentication service and verification service. 

Jonathan Lennox - how to protect the CPS from being a PERPASS target.

Jon - I don't have a complete solution. When you connect to CPS as a
verification service for a passport, and ask are there any passports from
this originating number? TLS and login for protection before you can access
passports. You will need to prove that you are the right target for a call
from that number. May not be sufficient - looking at using some kind of hash
of originating and terminating number, but not sufficient because you could
calculate those hashes, for say Lady Gaga calling Madonna, and poll for
whether the call is made. Need polling prevention. We can't carry a nonce.
Have to assume a discontinuity. Only have these 3 factors - originating
number, terminating number and timestamp. We have the ability to prove that
you are the authority for a set of numbers. Those are the moving pieces. 

Henning - To frame the requirements from privacy perspective, we should be no
more or no less strict than who can access CDRs? The originating,
intermediate carriers, terminating carriers. Protecting beyond that is
pointless. Assuming CPS security isn't any less that CDR security.
Authenticate the terminating entity equally strong and use the same trust
relationship with their carrier. They don't know originating carrier. If it
gets deposited in the terminating carrier's CPS. The customer has an oauth
token... a range of authentication mechanisms, strong or weak, individual or
corporate. That transforms the problem for the model - the originating entity
has to find the terminating carrier and we know how to do that.

Jon - if we could do that, could do e2e SIP. 

Henning - a db will give you good approximation of terminating carrier. Or an
entity that has a contractual relationship with terminating carrier, like a
SIP trunking service. get numbers through 3rd party, like Level3, holder of
record for the terminating number.

Jon - the use of certs for STIR to prove that you have the authority for the
number can take place of the trust relationship that you described, and allow
the CPS to be decoupled from the admin of either the originating or
terminating carrier. Worth considering.

Henning - If I can compromise the CPS, I have problem. 

Jon - Credentials can be encrypted then, right? 

Henning - If the passport can be encrypted ...by opaque hash. credentials can
be used for ...

Jon - it's indexed at the CPS by the hash, that's different than saying the
passport contains a hash. The passport can be encrypted with an opaque hash.
If you have credentials allow you to assert ownership of a number they can be
used for encryption as well.  

Robert - back up to "Sure!" slide. You fundamental premise that you use the
CPS when there is no direct internet connection, but that's flawed. You could
gateway to a protocol that can't carry the information even if you have an
internet connection between endpoints. 

Jon - I said that there could be IP. Just stripping identity headers could be
a problem. 

RjS - that CPS is a logical role could live in an endpoints. The e2e
transport security that Eric was talking about could be applied. It's a
unique use case. an edge. Don't preclude that.

Jon - agree

Jonathan - assumption - signer and verifier have internet access. Why would
the CPS hold the passport at all, the CPS could just be a rendezvous service. 

Jon - I'm looking for general framework that would also work for, say, XMPP
to SIP.

Jonathan - I would like to minimize the info the CPS has. Could be a
rendezvous point. Rather than big database of every call on the net.

Jon - Having the records encrypted at the CPS will be part of the design. I'm
not trying to create a backchannel to negotiate SIP or something else,
against the wishes of the things in the middle. Just give me the passport.
The passport won't give you mlines. 

Jonathan - There are use cases where I don't have bandwidth for voice call
but can pass 1k data around. 

Jon - On the IP-PSTN GW slide, it's a pots call that's come in. If we had a
rendezvous function, could set up the SIP call and drop the pots. 

Jonathan - I don't want to set up a SIP call. OK I'm doing audio over pots
for a reason, It doesn't mean that the information passing has to be store
and retrieval.

Jon - agree that the CPS could be a place to get a pointer to the passport.

Cullen - what info do we use that access this pointer, and pointer may not
buy you anything. VIPR - can have useful IP path but they go over PTSN
anyway. Important problem to solve.

Dave Crocker from Jabber room - Mic:  If there is standardized naming of the
actors, there needn't even be a rendezvous function, since the passport could
be stored in the DNS under that (domain) name.

Jon - Storing in DNS, it's not off the table. DNS would contain pointers.
These are short lived. Just for the duration of the call's alerting. Not sure
best fit. 

ekr - Is something like this valuable? I think yes. Is it implementable in a
way that is acceptable? That's a question. I've worked on this design but I'm
not happy with it. Point of exploring this. 

slide 14: CPS Design Questions

slide 15: Next steps

Jon - we don't have this licked. Let's do some work. We have part of the PTSN
story in ATIS. This part will get a few more kinds of endpoints participating
in the STIR ecosystem. 

44:13 - (lose audio here)

Henning - Be open to a variety of architectures. Base CPS storage. Carrier

Jon - I'm not saying that they don't work. My concern with carriers - you can
perform the rendezvous. 

Henning - We have a coordination problem - interoperability, certificate ...,
entities in the middle and edges. The endpoints can do things on their own,
but advocates for solutions that can be deployed with minimal coordination. 

(get back - 47 m)

Jon - There's nothing about this that says CPS is monolithic or centralized.
It's logical. Have no problem with that. 

Cullen - we have lots of IP-IP networks. Even if it's all IP - deal with it
on the edges don't have to upgrade the stuff in the middle. 

Ekr - I don't think storing it in the endpoints won't work well. The CPS will
be in the cloud somehow.

Jon - and what is in the cloud may just be a pointer. but we only have the 3
factors and they must give you the same answer on where you go get this.

Henning - we have 3 piece of info, but also have existing databases that
allow us to do the mapping. Can rely on external infrastructure in some

Jon - I don't have an ask about this today. There will probably be a virtual
interim meeting next year.

1020 (20m) : Passport Extensions (Jon Peterson, Chris Wendt)

slide 1: Title

slide 2: Twofold PASSporT extensibility model 

Jon - We've changed passport a lot in the last 4 months. 

Jonathan - I'm confused by this slide - sub-bullets look identical.

Jon - geez, you're right. 

slide 3: Demonstrating extensibility

slide 4: draft-peterson-passport-divert-00

Jon - didn't we publish diversion as an historic RFC? 

Cullen - after being published on Cisco's website for 10 years, it finally
got it published. 

Christer - discussions of History-info - is it a retarget or just diversion?
Can you use for retarget or rerouting? Can you differentiate?

Jon - Canonicalization removes things in URI, but that doesn't change the
dest. Don't need new passport. 

Mary - I need to think about it some more. 

Jon - this is new. This is a proposal for extending passport. 

Mary - I can see how this can work, but there will be duplicated info. 

Chris - this mirrors history-info. 

Jon - yes, what's in div is what is in history-info, but it's crypto signed.
We talked about signing history-info but we decided not to.

Mary - we have tools now to sign. 

Jon - this is a -00, this is an example of what we could do after a recharter.

Alan Ford - I appreciate this as a example. It's confusing having a single
domain. Let's say the domain is example2, does example2 sign both, are there
are two identity headers? 

Jon - div is signed with credential for the original destination not
originator. Extensibility model lets us do this so long as ppt is mandatory. 

Alan - need 2 identity headers then?

Jon - yes.

Alan - it seems like it would work. 

Jon - Yes, it's different from History-Info because of the canonicalization,
it doesn't capture reasons. Once you create an extension you could create a
bucket to hold other things like reasons.

Chris - When you go hop-by-hop, you would add to history-info, and an
identity header for in-band. 

Jon - works differently in out of band. In band and if you have History-Info,
you can walk back and find out if it should have been sent to you. 

Chris - you have this div ppt. with original identity header, another one for

Jon - right. Canonicalization would eliminate some minor things that are
tracked by history-info. I'm just trying showing that the extensibility
property would work. 

slide 5: Inverting the usual rule

slide 6: For an original PASSporT...

slide 7: "div" with "ppt"

slide 8: draft-peterson-stir-cnam-01

Jonathan - something in the root cert saying that I'm willing to sign cnams.
If I get a cert for my phone number and I prove it's my phone number, then
send you a passport saying Jon Peterson, that's pretty bad. 

Jon - proof of possession certs have a different LOA. We have to talk about
it. Those certs will have different powers. 

Jonathan - VZW gives me a cert that says I own this phone number. there needs
to be something in the cert that says that you are allowed to sign it. 

Jon - if you look at stir-certs, Russ added a JWT claim constraint. If this
claim is in the passport it has to have this value or don't accept it. 

slide 9: "cna" without "ppt"

slide 10: "cna" with "ppt" 

slide 11: Elaborating on "cna"

Alan - if the receiver couldn't validate, is it up to local policy, does it

Jon - up to local policy. The draft's a sketch. Within the CNA something else
appears, there's no provision that it has to fail. 

Alan - if you don't define ppt then it's local policy.

Jon - yes. 

slide 12: Sanity checking

Henning - Reducing general confusion - using the term "cnam" itself, it
implies a name and a db lookup mechanism. This is not cnam - It's not subject
to the same restrictions and doesn't originate from the same databases. It's
call info largely plus the display name. 

Jon - it's a secure call info.

Christer - there could be a case where there's multiple ppt values in a
passport. div with something else. 

Jon - I don't think div would ever be together with something else. You have
2 identity headers if you have two things. Let me know if it's not clear in
the spec. Alternatives look bad.

Alan - if you have multiple identity headers, someone can remove one of them.
Someone could edit the called name.

Jon - Yes, they can remove the identity header. No one can edit the called

Chris - in practical deployments, you will have a ppt itself or just add
certain claims, not 12 identity headers just for the heck of it.

ekr - I think it's unwise to have multiple identity headers. Have it be
parallel. Trying to harmonize the view fails cryptographically. Russ may

Russ - No, when there's multiple signatures, you don't know which to

Jonathan - make it clear to the cert issuers that they need to think about
future, unknown claim extensions when making their certs. Need claim
constraints - I can only sign baseline.

Russ - we did not define a wildcard for claims. So if that's important - We
didn't say can't include *.

Jonathan - There needs to be guidance saying - think about extensibility of
signing claims. 

Russ - agree

Jon - we still have work to do.

Chris - It's the opposite problem - you need to trust the person that you are
validating, local policy should be to ignore claims that you don't want to
receive or can't understand. You can say don't trust. 

1040 (10m) : Using STIR with ACME (Jon Peterson)

slide 1: Title

slide 2: ACME

slide 3: STIR and ACME

slide 4: ACME (through a STIR lens)

slide 5: What are interesting proofs?

slide 6: Fancy applications

slide 7: Next steps

Mary - this is interesting and we should pursue it, we're looking at this in
the NNI taskforce. We should work together on this.

Simon - I like this, would implement. 

Rich Salz - I'm co-chair of acme. There are long-lived certs that can live in
the sim. acme will be LC soon but is extensible. this is cool. Certs for
phones will swamp CAs.

Chris - support this as well. In addition to IPNNI work, we're making this
compatible with service provider certs and moving to TNs. Think there is a
path there.

Danny McCarney, Let's Encrypt - having a use case like this will help the
acme WG for clarifying whether we have the right things in that aren't DNS

Cullen - very supportive and happy to contribute.

Matt Miller - Eric burger is also supportive. 

Jon - We're not chartered to do this. I propose a general charter slot for
extensions. I would like something like this - something to explore cert

Chris - +1 for extensions

Ben - For extension item for charter would you expect work discussed in
SIPBRANDY, DISPATCH would be don't here. 

Jon - I don't think sipbrandy work needs to be done here. I don't want to
create a constraint that the work must be done here. 

Martin Dolly - Add an RPH example.

Jon - got it. 

1050 (10m) : Charter checkpoint - recharter? (chairs)

Robert, as chair - I would like a show of hands of people who are willing to
work on passport extensions, and are willing to review them, and think this
is the appropriate venue to do so?

[Lots of hands in the room]

Robert, as chair - I would like a show of hands from people who want to work
on integrating stir and acme and think this is the appropriate venue to do

[Lots of hands in the room]

RjS - I think that's sufficient support to show that we have energy. We'll
work out proposed charter text with ADs, and post text to the list shortly
after the meeting. 

Russ - we are out of time.