Minutes from the STIR WG IETF 92 Meeting - March 25, 2015 Summary: * Martin Dolly will provide text to add to the liaison responses. The group will review them on list, with comments due Tuesday March 31. * Discussion favored including PAI in canonicalization - Jon will put together text for further discussion on the list * Discussion favored leaving a place in the canonicalization result to plug in the result of CNIT * Both rfc4474bis and the certs draft are nearing completion ---------------------------------------------- Raw notes from Eric Burger, humble Note Taker Consumer's Union will video record the session. We had a discussion about the use of the session and if anyone had a problem with it. There were no issues and the session will be recorded. Richard Barnes was honored with a wine from Hawaii. ITU-T Liaison ============= [Jon Peterson] The liaison to the ITU-T on X.ticsc (1353) was presented with a Star Wars crawl. Martin Dolly points out that RCS and IMS security should be going on in 3GPP, not ITU-T. Perhaps give them information, but no direction as to what to do. ??? from SG-17 UK delegation said it may be important for us to hint this work should be in 3GPP, to postpone ITU-T's work in lieu of 3GPP working on it. Meeting is in a week. Jon asks Martin to propose appropriate text. He says he will do it tonight (26 March) Hui Deng – we should put timing into liaison, too 4474bis ======= [Jon Peterson] Jon presented updates in -03. No one had anything to say about canonicalization. Signing PAI: do canonicalization over PAI if present instead of From? Cullen: PAI works where it works; this will work in such networks; no worse Jon: if PAI cut, and then canon cut, nothing left. Answer: Right. Keith Drage: What if PAI stripped for anonymity purposes, but canon still there because the device does not understand cannon - that leaks caller information Robert Sparks: Breaks the same way if a device adds PAI Martin Dolly: PAI only pops in when one crosses CS to PS boundary. You might not know the provenance of the ISUP signaling, so carrier may not be able to believe the From address. As such a carrier may not sign the signaling. Keith: Consider business trunking: the IMS will be inserting PAI, not stripping it. Paul Kyzviat: Need to separate cases where PAI is From and where PAI does not. Martin: Thinks identity information should not be stripped, but also should not be signed as trusted when crossing boundaries. Jon: feels he needs to write this up and take it to the list. Keith: worried this will be changing the semantics and definitions of trust boundaries. Martin: If PAI present, 3GPP says PAI gets displayed. If PAI not present, From *may* be displayed. Often not done, so not an issue. Sign anything else? Proposal is to only add CNIT, but not a generic header signing mechanism. Martin: make a new canon (canonn?) field for signature over more / different fields. Jon: does not want multiple cryptographic passes Martin: but will not be backwards compatible Brian Rosen: OK with blank field Henning: Concerned that CNIT is in pre-conceptual phase. It may be by external reference, which would be hard to sign for, more especially if it is an internal reference to another header field that is not cryptographically protected. Henning: Need to deal with legacy CallerID systems that can only display 16 characters (millions) and new systems that can digest, e.g., XML. Dan: When STIR was chartered, CNIT was explicitly not in charter. Are we changing our mind? Jon: We are not addressing CNIT directly, but we are just leaving a blank field for someone to fill in some cryptographic thing once we know what the thing is we are signing. Henning & Sean: Multiple things signed means need to decide who is doing signing, who can do signing, and adds more computation and possibly protocol overhead. Sean: Just put in some text and we can fix later. RJS, Brian pile on +1's Since we have some time, Jon proposes we keep going down the rabbit hole. Brian: Thinks it will not be difficult to come up with the precise algorithm once CNIT done. But before that happens, could be real bad for us to start guessing. Much better to just leave a blank. Cullen: No way to upgrade in the future, so kind of need the placeholder now. Henning: But need something such that 'legacy' systems do not break when we start filling in the CNIT placeholder later. Either we are going to have two signatures, a by-reference name (e.g., based on number and LIDB and CNAME or by identity-info header) Brian: if we do not think the blank will work or it is looking like CNIT will not happen, then we just drop it before publishing STIR. Chris Wendt: Likes idea of using display name for CNIT for now and fixing it later when we get a CNIT solution. STIR Certificates ================= [Sean Turner] Sean goes over various certificate verification technologies. Proposing OCSP over SCVP and CRL, with the proviso of using SHA-256 instead of SHA-1 for OCSP. Rick Andrews: SHA-1 around in a lot of places, but SHA-256 works. Richard Barnes: OCSP widely used 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. Henning: certificate can be huge if enumerating all their numbers Sean: CSP can decide how they want to cut things up. A big certificate with a bunch of number ranges, a single certificate per number, or whatever in between. Use OCSP? Stapling: Richard Barnes: worried about implementation, particularly Criticality. Sean says we will have to address in our text. Concern that HVE OCSP profile does not allow extension? We can do our own. Authority Info Access Method: Check by reference instead of inline another way to go. Henning: two issues: what does the certificate apply to, versus revocation. So, authorization check option comes down to just checking if the number is in the scope of validity, not whether the number is associated with the certificate. Other work? ========== Jon: Out of band? Cullen says they will dump some stuff in soon. Brian: Proposes some Informational drafts letting national regulators know how to set this up. RJS: Any reason things will not be ready for WGLC by Prague? RJS: NOW is the time to bring up issues.