Minutes : STIR : IETF 91 : 11-Nov-2014 Key Points and Action Items: ITU Liaison Statements: * Richard Barnes will drive creation and review of responses to the two statements from ITU-T SG 17 draft-ietf-stir-rfc4474bis: * Discussion supported the need to speak about multiple fingerprints. The next revision of 4474bis will propose a mechanism * The broad latitude for local policy in canonicalization will be preserved, and reasoning behind leaving this latitude will be explained in the text. * Discussion supported including To: in the canon parameter. * Discussion supported accepting that given the protection of the fingerprint, gatewaying through other protocols (at least those that are not using DTLS-SRTP) is very likely to fail. No additional work will occur in 4474bis around gatewaying other than to ensure this consequence is clearly documented. * Discussion converged on recommending a one-minute threshold for inspecting Date header fields for staleness. * Compliance examples would be useful - Robert Sparks and Cullen Jennings will investigate whether prior work on tools generating 4474 examples can help * While some editorial work is expected in addition to the points above, the draft is essentially complete, and the next version will likely be ready for WGLC. draft-ietf-stir-certificates: * Discussion supported moving forward with a baseline mechanism for retreiving credentials by dereferencing the Identity-Info URI. The mechanic should support credential caching (including invalidation). * Discussion supported exploring an indirection mechanism for determinining what set of numbers a certificate is currently covered by a certificate. The chairs and ADs will discuss how to structure this work. * Discussion of what should be telegraphed through the certificate's subject name was inconclusive and will continue on list. Checkpoint: out-of-band: * It is likely the certificates being defined for the in-band solution will be reusable for out-of-band. Please keep out-of-band in mind as the work progresses. Details (based on notes from Peter Yee): Cullen Jennings says that the Cisco may have some IPR draft-ietf-stir-rfc4474bis. He's working with Cisco legal to make that determination and will let the WG know as soon as possible. ***** ITU Liaison Statements: (Jon Peterson) 2 liaisons received. ITU-T SG 17 (Security) indicates that voice spam may have a solution in draft Recommendation ITU-T X.ticvs. This is done by analyzing SS7 data and blocking calls within the network. There are privacy concerns over the methods used to combat voice spam. A reply to liaison is due by the end of the March. The IETF solution to voice spam is more VOIP focused, so there may be no clash between the two solutions. A volunteer is needed to write the response. The other liaison also from SG 17, but it VoIP oriented (via VoLTE). An IMS-based server hanging off the IMS core would make determinations of whether to pass calls based on their determination of the spaminess of a call. They are interested in hearing from the IETF for feedback and information on what we are doing in this space. This liaison seems more like a request for info than the previous one which seemed more defensive. Keith Drage: Calling out IMS is a red herring. You don't need to know anything about IMS to respond. It's just a centralized server accessed via SIP. Peterson notes that the accompanying picture does show a lot of IMS infrastructure and seems specific to IMS. Drage reiterates that you shouldn't need to know anything about IMS to answer the liaison. The IMS Core doesn't really matter. 3GPP has discussed something similar to the question in the second liaison, but their new study item is more closely related to STIR. Richard Barnes: summary: don't see a lot of conflict, they seem to cover separate domains, STIR's work would cover both cases. Barnes accepted the pen for writing the responses, although he kept the right to pass the pen on to others. ***** RFC4474bis: (Jon Peterson) Jon Peterson: rfc4474bis-02: Work is separated into two buckets: 1) signaling (what is signed, how signing/verification works, canonicalization) and credentials (how signers enroll, how verifiers acquire credentials, how to determine the authority of a credential for a identity). This draft deals with signaling. Since the -01 draft, changes are: 1) added mandatory signature over a=fingerprint; 2) integrated "canon"; 3) split the references; 4) filled in IANA Considerations; 5) added pointers to the STIR problem statement and threats. For 1) generally there isn't a problem with using multiple certificates – it's a corner case. Jennings suggests sorting the fingerprints by value and dropping them in. We need to make sure the case is covered, but more consideration is needed. Is something more beyond media security needed to address baiting attacks? Robert Sparks thinks Peterson's text on the issue is fine. On the "canon" issue: a) Is the latitude for local policy too broad? If it is too broad, it's harder for the far side to successfully generate the value. "canon" is only used with From. Should it cover To? Perhaps not. Example given is that a toll-free number ends up translated to a different destination URL than the number dialed. Since the auth service can munge the To/From headers before signing, text has been added to make this possibility clear. Is there a narrower constraint that can be added to delimit the scope of the further transformations that are applied to the To/From fields and the repercussion of those transformations – how far can transformations be taken before the recipient is unable to recreate the canonical values. There's a real problem with cut-and-pasting of packet headers to spoof calls. Brian Rosen: "canon" is not part of the signature. So you can't use it to determine the origin of the call. Peterson: the recipient canonicalizes the To field and compares it with the To field in "canon". If they match, then it's probably worth processing the call. Otherwise, perhaps not. On the gateway issue, what about tunneling cryptographic signatures across non-SIP protocols. Protocols such as XMPP, SS7 UUI, etc. Rosen (channeling Hadriel Kaplan) a=fingerprint will not work through gateways, so don't bother trying. Other data could work through a gateway and would have meaning to other protocols. Martin Dolly: gatewaying shouldn't be done. With AT&T and Verizon doing VoLTE interop, there's much less call for gatewaying. Peterson will not continue working on gateway for the draft, other than to document (or verify that the existing text documents) that all but the simplest of gateway scenarios will likely cause failures. Path forward: 1) the Date threshold text is inconsistent for what the cut-off is. 1 hour is far too generous. Input is requested on the duration that provides suitable security without requiring ultra precise synchronization. Brian Rosen thinks a minute would be a suitable value. The draft should have a recommendation and explanation of that value, but it shouldn't be a hard requirement because some unusual scenarios might take several sigmas more time than the usual case. The group consensus is that a minute should be fine as the default value when no other value has been determined by the use case. 2) Are compliance examples merited? It seems like they are genuinely useful to get the draft right. 3) The major stuff is in place. Any cruft remaining that should be excised? Any objection to going to WGLC with the next draft? ***** Certificates: (Jon Peterson) Jon Peterson: STIR Certificate Credentials: the draft is now a working group item for a certificate-based STIR credential system. Covers telephone numbers and number ranges with some new attributes. Defines ways to obtain these certificates. But it uses certs differently from X.509 PKIs. Enrollment can be done through 1) direct assignment (from an authority or provider, which is the traditional model), delegation from above (from intermediate holders of numbers), and 3) proof of possession (demonstrated ability to use the number "proves" it's yours; Cullen Jennings will present on this topic later). Do we need to have different levels of assurance for the different enrollment schemes and the resulting credentials? It should be made clear that signing can be done by endpoints or (more likely) intermediaries. Credential verification can be done an intermediary or endpoint as well. Question: how does a verifier find a credential? Given an incoming call, what does the verifier need in order to retrieve a credential from a certificate store? Peterson suggests using the Identity-Info URI to provide the disambiguating information that allows for a certificate retrieval. Sean Turner says a lookup pointer is mandatory. This particular one seems fine. Rosen: I thought this was a hint, not the answer. Peterson: the original 4474 does say this is a hint. Rosen: what about going to the logical authority and asking for all of the certificates assigned to a number. That's not likely to be a large number. Russ Housley: this doesn't work in the delegated certificate issuing model. Rosen: a delegator should cause the certificate to be issued by the logical authority. Housley: it's unlikely that we're going to see a single certificate issuer. Delegated issuance is pretty certain. Rosen: remember, we had the logical authority to prevent long, difficult-to-handle chains of trust. Credential caching is migrating to the credential specification rather than being in the RFC4474bis. Question: should the Identity-Info contain a lightweight credential hash to allow verifiers to know they already have the relevant credential. Jennings: a serial number suffices for this need. Turner: Agreed. That way you don't have to worry about picking among hashing algorithms. Peterson: there are options for how the hash is represented in the URI. Rosen thinks that the URI should change with the certificate. Peterson feels that a single URI with a changing hash attribute would be helpful for cleaning up the cache. Otherwise, stale URIs are cached with no way direct way to find and remove them. For credential acquisition protocols, there are (too) many methods: push/pull/prefetch/others. Do we need a mandatory-to-implement method such as dereferencing the Identity-Info URI? Rosen: I'm leaning that way. We want to document push, make Identity-Info URI mandatory, and have a bulk/go-to-the-source method available as well. Peterson: why isn't there a notification system to alert an entity when a new credential is available? Housley: historical perspective: way back when, LDAP was believed to be on a trajectory to be available ubiquitously as a way to find certificates. Peterson: do we take prefetch off the table? Or do we actually run with it? Jennings: we should talk to the Security Area and ask them for a way to do it. SIP SUBSCRIBE is probably not the right way to do it. Peterson: I could add web push. Turner: I do have an extension to EST that allows for pulling down other certificates. Rosen: I really want to have a simple web service where I supply a phone number and get all the assigned certificates in response. Consensus to go with Identity-Info URI as the MTI. HTTPS will be used for confidentiality, primarily, not integrity. Another open issue: how to handle ranges. STIR certificates can have handle many numbers in it. A major carrier might have a single certificate that can sign for any of their numbers. Delegation might split an authorities range of numbers over multiple sub-authorities. Adam Roach: how is number portability handled? Numbers can be moved to new authorities with ease, but that would lead to constantly changing certificates, especially if a certificate covers a large range. If putting the number or number range in the certificate is problematic, how about putting a pointer (URL) into the certificate that points to the list of numbers. Or perhaps the URL points to a service that can answer whether the number is covered by the certificate. Peterson: please give me input on these ideas. He doesn't feel, given the threat model, that a CA would be unwilling to sign a certificate that points to a non-signed list of numbers. Rosen: if you have a cert, you need to do cert validation, and you could use something like OCSP with extensions to check both the validity of the cert and the validity of the cert for a particular number. Barnes: are lists meant to solve a bloat problem or some other problem. And it would be a good idea to make sure the certificate/number binding validator is actually correlated with the provider. Jennings: the churn on a certificate depends on how many numbers are covered by a certificate. Knowing the optimal number for entries covered by a certificate would be really useful to know in order to reduce churn without having a massive number of small-range certificates. This also seems to point to using the by-reference approach as a solution. Rosen: a simple OCSP extension seems like it would be do the trick with ease. Peterson: I hope this would be palatable to others; I like the idea. Barnes: in the WebPKI, OCSP is not very popular at the moment due to the latency it adds. A new charter item for this scheme seems reasonable. And there are optimizations that can be done to reduce latency. Last issue: should certificates be public or confidential. The subject name is the attribute in question, giving the ability to assemble of list of numbers that are affiliated with which provider. We need feedback from the operator community to know if they care about this issue. Martin Dolly (AT&T): we do see some value in the terminating carrier being able to display a message that says "verified by ". There is some information we would want to protect from our competitors, but it's not a problem. Barnes: from the RPKI, subject names are not meaningful. There's also the PKIX subject information access attribute that can be used as well. Housley: consider the overlap between the RPKI and WHOIS as a useful example. Jennings: I question whether confidentiality is really an issue. ***** Out-of-Band: (Cullen Jennings) (This discussion was pressed for time) Cullen Jennings: trying to revive the out-of-band signaling case. (It was originally agreed to work on the in-band case first). In the out-of-band case, the security data is sent to a CRS (Call Recording Service) while the actual call is cleanly passed over a network that doesn't handle in-band signaling. The receiving entity talks to a proxy that verifies the calling identity via the CRS. There are 3 pieces of work to be done in specifying out-of-band certificate usage: Proof-of-possession enrollment, proof-of-possession acquisition, and out-of-band certificate discovery. Let's pay attention to out-of-band requirements while we are working on in-band certificate support. It's not clear that in-band and out-of-band certificates are the same. They might be.