Minutes: STIR (Secure Telephone Identity Revisited) : IETF96 Tuesday, Afternoon Session I 1400-1600 : Schoeneberg Summary: The group discussed the three documents currently in WG Last Call: - draft-ietf-stir-rfc4474bis-10 - draft-ietf-stir-passport-04 - draft-ietf-stir-certificates-07 The conversation resulted in these decisions and actions: For rfc4474bis: - When a bad Date is encountered, the document will specify returning a 403 and define a standard Reason phrase for this situation. - We will keep the current canon mechanism, but add some explanatory text. - We will retain the current way of working with PAI. - Noting that someone may choose to do so as an extension later, we will not address call diversion at this time. For PASSporT: - In places where multiple identities are allowed, always use a list even if there is only one identity. Text noting that future systems that make use of multiple identities must specify how verification works in that system will be added. - Ted Hardie will provide text to best navigate how to encode URIs that include non-ASCII range Unicode characters. Percent-encoding is the usual approach for URIs. For certificates: - Add clarification text about why we chose "SHOULD" instead of "MUST" when saying that an OCSP Responder SHOULD NOT return "not good". - Sean Turner will provide early IANA code point allocation request text to Alissa Cooper. For all docs: - Updates to these Internet-Drafts that reflect the WG Last Call discussion will be issued quickly after Last Call ends, with a goal of getting these documents through the IESG and into the RFC Editor queue before November. For the chairs: - Work with Alissa Cooper to refresh the WG Charter milestones. ------------------------------------------------------------ Raw notes from Mary Barnes 5m Administrivia 45m draft-ietf-stir-rfc4474bis : Jon Peterson - In WGLC - time for folks to review Some list discussion, some private correspondence - Bad dates - How to respond when a Date header is stale? - 2 options: 1) new status code 2) could send e.g., a 400 Bad request Proposal: new error code Discussion: - EKR: This isn't reparable - Jon: e.g., request takes a long time, misconfigured - EKR: 1st principles. a new Reason phrase is likely better - Alan Ford: agree with a new Reason phrase - Ted: maybe 403 forbidden - Martin: prefer a new error code. Interop has been screwed up with reuse of error codes to the point that they can be meaningless. - Jon: maybe not so generic as bad request. 403 with an appropriate error phrase. - Martin: a Reason phrase is okay if it's standardised Conclusion: put this (403 with new reason phrase) in the revised doc - "canon" or something else - ala issue raised by Christer on mailing list 2 other paths: 1) should we always include the whole PASSport? 2) If not, should we use the baseline RFC 7515 Appendix F mechanism - seems to let us omit the claims, not the header Jon thinks this is a big change to the spec at this point. Need motivational text and at least one solid "canon" example Discussion: - Chris: think you encapsulated our discussions well. Part of this is getting this in the network and making sure we don't have 2 round trips in INVITEs. There are other arguments at scale - reconstructing header claims. - Jon: you always have to do that work (extracting and comparing). Don't see a savings on computation. This is just about bits on the wire. - Chris: string compare versus string manipulation. If # bits on wire make an impact, then some of things won't be visible until we have this in the network. Fine with option now - canon all the time. - Jon: concern if the bare minimum aren't so much, extensions will be added on top of this so these objects can get large. - Chris: fine if we are flexible. Need to make sure it works without a lot of 400 errors. - EKR: if you think we're going to end up with carrying canon all the time, we should suck it up and do it now. The by construction mechanism is slightly easier from a security perspective, because you can't omit checks. If you have to comparisons, easy to not do correctly. If you are carrying canon, instead of checking can you simply stop - take value out of canon. - Jon: provided that the end result of however we order comparision is that we get reference integrity, then we can talk about other strategies - EKR: not concerned about non-compliance with JWS. This a compression mechanism. - Matt Miller: the compliance thing is that at the point you want to shove it through an existing JWT implementation, doesn't matter how it gets there. Concerns with JSON without a defined canonalization. Make sure strings are represented the right way. Appendix F allows you to remove payload as what goes into processor matches up. Header harder to remove. Trickier to put through existing implementation so probably want to carry header. - Jon: from reading Appendix F, we need to flush this out. F is non-normative. More work needs to be done on JWS. - Matt: need to consider what's already out there. - Chris: some of those existing implementations assume JWT as the type. - Matt: there are JOSE implementations and JOSE+JWT - those are not the same. - Jon: from purely selfish perspective, getting this done as expediently, don't want to define every instance of canon. Think what we have is good enough - can set canon all the time later after we see this implemented. - Rich: we can do more in profile documents (e.g., if folks decide their requirements need canon all the time). Fine if we can later update specs after operational experience. Conclusion: Keep what we have (with agreed updates per discussions) - PAI: baseline or an extension - Currently "orig" can come from From or PAI - Suggestion to add ppt extension - to be explicit - Why we didn't do this in the first place - because any environment where you will use PAI already knows that they are using PAI. Discussion: - Martin: with PAI, in this environment, if PAI were trusted and not tainted, we could just use PAI. Problem today is that enterprises send PAI that's not verified by the carrier. Carrier only processes based on subscription ID of enterprise. PAIs also come from other untrusted environments. There is not a train of trust in managed networks. Helpful to know it's a PAI signed. - Jon: who would use PAI and Identity at the same time? Agree that there is value in signing. Issue here is slightly different - should we provide a copy of Identity header along with one from PAI. PAI is used in environments where theres' junk in the FROM. Prefer to clobber. - Paul: question is around about those that know they're using PAI? What about an environment where PAI is not end to end? - Jon: there is text around that in 4474bis. There is a privacy risk based on 3325 (3324)- PAI is required to be removed at trust boundaries and it's possible that canon wouldn't be removed, thus canon could leak PAI. Right now this is noted in 4474bis. You could remove canon also - not required. - Paul: concern that the far end wouldn't be able to verify - Jon: there will be environments where there is private identifiers that are secure and those escape, validation failure is probably appropriate. - Robert: this is a direct consequence of transiting that boundary. - Olle: Remote Party ID may have a role (rather than PAI). - Jon: how many P-headers contain some version of original calling number? This is a consequence of a fast proliferation of identifiers (e.g, from other networks). Think PAI has status and deployment profile justifying it. Reluctant to look at others. - Olle: can take out the number of phones with PAI, RPID and From - pretty high as compared to other headers. - Chris: the reality is that it's based on peering agreements, you're going to have to have AUTH and verification services that can adjust to your environment. Conclusion: No change. - Diversion: - Got comments about how to handle forwarding and other cases where the effective "To" changes. - Could possibly have a ppt extension. Possibly chain able with History-Info - Not willing to make this change now. Conclusion: no change at this time. - Housekeeping - add Terminology section - address nits from Olle to be addressed - add examples - Robert: as you are considering what to add, suggest to take a conservative approach - Olle: two of my comments were 1)had a problem seen how this would work with Outbound 2) B2BUAs - Jon: would never delegate anything to STIR. - Olle: B2BUAs should at least be mentioned - Jon: this group was based on the bare minimum we could get through B2BUA. Prepaas makes it essential we have a way of managing fingerprints. Should be a failure if it gets stripped. - Olle: then we should document that. - Robert: disagree with Olle - Chris: also disagree. You should be validating tokens earlier - probably before B2BUAs. 30m draft-ietf-stir-passport : Chris Wendt Change in identity claim names - 03 included a "dgrp" claim that allowed for multiple destination identities - Rather than an additional claim, decided to clean everything up and make it more consistent. Go back to original "orig" and "dest" and allow for either "tn" and "uri" each which can have an array of identity strings. Discussion: - Christer: If you have multiple URIs, how is verification going to happen? Especially if you're not sending claims. - Chris: destination should only look to make sure they're included in that list. This verification is meant to prevent replay attacks. - Jon: The verification service recipient would pick if any of the identities applies to them. - Chris: both should validate correctly. - Jon: there is not a way to say where Bob's name lives in the SIP request. On the fence as to whether we even need this. Not sure we need multiple things now. Anyone that has more needs to describe SIP behaviour. Imagine semantics would be if any of those matches, then willing to accept. - Christer: sender creates this - calculates identity value. So, when the receiver gets it, he has to do the same thing or he will get a different value. - Chris: this doesn't apply to 4474bis - EKR: trying to figure out desired security property. - Chris: this is based on discussion on how to support multiparty. - EKR: that's not a security property - that's a use case. There's no where to put this outside the trust boundary. - Chris: asserting my identity to Alice and Bob at the same time. - EKR: there seems to be some desire to inspect exterior messaging. - Jon: e.g., email. Any using application needs to explain how it will be using multiples - Chris: need logic around authentication service - Russ: always use brackets on TN or URI. Conclusion: Agreement on proposal (considering Jon's comments on application/user considerations and Russ' comment on brackets) Removed the ability to extend passport without fix lexicographic - wouldn't be Passport if bare minimum claims removed Conclusion: Agreement on proposal Order in examples - Need lexical order in examples Conclusion: make changes to fix this. Discussion: - Sean: thought we discussed on list requiring JWS being signed with ES-256. MTI in Passport? - Chris: Yes - in doc - Jon: This is in STIR certs - tracking what's in Passport - Matt: lexical ordering. If you have something that will be true Unicode (beyond Ascii), you might need a statement that this is minimum required encoding. - Chris: thinks JWT points to something talking about this - Matt: JWK thumbprint spec talks about this. All keys today are simple ascii. Should at least make a note. - Chris: general question is what do we say about Unicode. - Jon: just keys - Matt: this is anywhere you are doing ordering - Jon: concerned about IRIs. If you look at URI normalization procedures in 4474bis. Can't imagine we'll have this anywhere other than in an IRI and there is an ordering ambiguity. Doesn't seem extremely likely. - Ted: If example.com gets replaced with .arabic TLD, you have 3 choices. 1) don't get benefit of STIR 2) must treat this according to a specific encoding 3) or allow this and then do string compare here because it's not going to get dereferenced. Can easily get Unicode string wrong, need domain names in an ordered set. - Ted: presentation form of DNS forms include Unicode. If these get filled in by someone using a form, whoever translates from presentation form, needs to pick between 2 forms of ascii encoding. - Chris: is this already addressed. - Jon: can Ted put a note to list on this? - Ted: is there anybody in the room that would get hurt if we said to use percent encoded for values that are not in ascii? Conclusion: Ted post to the list with his proposal and get consensus. 30m draft-ietf-stir-certificates : Jon Peterson Now at -07, and in WGLC - Shifted to ECDSA P-256 and SHA-256 - Aligned with PASSporT - Still allowing RSA for certificate signature verification - Furnished the ASN.1 module (Appendix A) - Added a Level of Assurance (LoA) for certs - Tightened the (optional) OCSP profile - Eliminated TBDs, put in some organization - IANA and references clean-up Levels of Assurance Want to distinguish different methods of enrollment - Some interest in the SHAKEN model as well levels of Assurance Decided to reuse an existing registry Level of Assurance Profiles (RFC 6711) (SAML registry) - Created a STIR sub-registry - Requires Certificate Policy (CP) to add a new LoA value to the registry - Better than defining the CP/CPS ourselves here Discussion: - Chris: is this baked at cert level? Some of what we discussed are at per call. - Jon: this is per cert - enrolment procedure. Proof of possession certs. built into credential. - Chris: could you have the model where service provider signs on behalf of clients? Would SP have different classes of certs. - Jon: Need to know GW for accountability - Chris: want to pass level of assurance to verifier - Martin: one of the ideas was with mobile device - fingerprint reader so you know users identity. with video would be useful to have verification of user. - Jon: not proposing to punt. Providing structure where these can be populated Conclusion: general agreement with proposal OCSP Profile Profiling away the "unknown" response - Servers SHOULD send "not good" instead of "unknown" - "clients MUST treat returned "unknown" responses as "not good" Also note that OCSP responses MUST be signed with the same alg as the cert itself which could be ECDSA or RSA Discussion: - Eric Burger: SHOuLD send not good otherwise "what"? - Jon: can clarify why this is a should - Sean: where do we stand on early codes? - Russ: raised this on the list. have only received supportive comments. - Action: Sean write the text and send to Alissa. Conclusion: general agreement with proposal (with clarification noted for the SHOULD) In-Band STIR architecture - think it's done Jon wants to start looking at out-of-band. Discussion: - Alissa: suggesting milestone updates, noting privacy analysis - Russ: if we get anything back from the IESG, need to handle that and then move to next steps. - Robert: when Last call closes (end of next week) is there anything that would prevent a relatively quick spin? - Jon: thinks Passport has the most material needing to be scrutinized. - Chris: will spin a new version based on discussions - Jon: noting SIPBrandy WG - profile for STIR - Robert: if you have an implementation, then come to SIPit in September at UNH.