From nobody Mon Jan 26 19:20:32 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D7F1A1B7F for ; Mon, 26 Jan 2015 19:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFBuHAqXBVAq for ; Mon, 26 Jan 2015 19:20:21 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED811A1BA4 for ; Mon, 26 Jan 2015 19:20:19 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] Minutes: STIR: IETF91 - stirring the pot Thread-Index: AQHQOeAsR3yCUU0VI0ycL1HsschMbg== Date: Tue, 27 Jan 2015 03:20:17 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [stir] Minutes: STIR: IETF91 - stirring the pot X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 03:20:31 -0000 The last frozen turkey left-over have hopefully been consumed, but it's got= ten awfully quiet on the list. The minutes below identify a number of list = discussion issues. Anybody care to kick off a new round?=0A= =0A= ________________________________________=0A= From: stir [stir-bounces@ietf.org] on behalf of Robert Sparks [rjsparks@nos= trum.com]=0A= Sent: Tuesday, November 25, 2014 11:06 AM=0A= To: stir@ietf.org=0A= Subject: [stir] Minutes: STIR: IETF91=0A= =0A= Please send any necessary corrections to the chairs.=0A= The proceeding submission cutoffs are 5-Dec for draft and 26-Dec for=0A= corrections.=0A= -------------=0A= Minutes : STIR : IETF 91 : 11-Nov-2014=0A= =0A= Key Points and Action Items:=0A= =0A= ITU Liaison Statements:=0A= =0A= * Richard Barnes will drive creation and review of responses to=0A= the two statements from ITU-T SG 17=0A= =0A= draft-ietf-stir-rfc4474bis:=0A= =0A= * Discussion supported the need to speak about multiple fingerprints.=0A= The next revision of 4474bis will propose a mechanism=0A= =0A= * The broad latitude for local policy in canonicalization will be=0A= preserved, and reasoning behind leaving this latitude will be=0A= explained in the text.=0A= =0A= * Discussion supported including To: in the canon parameter.=0A= =0A= * Discussion supported accepting that given the protection of the=0A= fingerprint, gatewaying through other protocols (at least those=0A= that are not using DTLS-SRTP) is very likely to fail. No additional=0A= work will occur in 4474bis around gatewaying other than to ensure=0A= this consequence is clearly documented.=0A= =0A= * Discussion converged on recommending a one-minute threshold for=0A= inspecting Date header fields for staleness.=0A= =0A= * Compliance examples would be useful - Robert Sparks and Cullen=0A= Jennings will investigate whether prior work on tools generating=0A= 4474 examples can help=0A= =0A= * While some editorial work is expected in addition to the points above,=0A= the draft is essentially complete, and the next version will likely=0A= be ready for WGLC.=0A= =0A= draft-ietf-stir-certificates:=0A= =0A= * Discussion supported moving forward with a baseline mechanism for=0A= retreiving credentials by dereferencing the Identity-Info URI. The=0A= mechanic should support credential caching (including invalidation).=0A= =0A= * Discussion supported exploring an indirection mechanism for=0A= determinining what set of numbers a certificate is currently=0A= covered by a certificate. The chairs and ADs will discuss=0A= how to structure this work.=0A= =0A= * Discussion of what should be telegraphed through the certificate's=0A= subject name was inconclusive and will continue on list.=0A= =0A= Checkpoint: out-of-band:=0A= =0A= * It is likely the certificates being defined for the in-band=0A= solution will be reusable for out-of-band. Please keep=0A= out-of-band in mind as the work progresses.=0A= =0A= Details (based on notes from Peter Yee):=0A= =0A= Cullen Jennings says that the Cisco may have some IPR=0A= draft-ietf-stir-rfc4474bis. He's working with Cisco legal to make that=0A= determination and will let the WG know as soon as possible.=0A= =0A= ***** ITU Liaison Statements: (Jon Peterson)=0A= =0A= 2 liaisons received. ITU-T SG 17 (Security) indicates that voice spam=0A= may have=0A= a solution in draft Recommendation ITU-T X.ticvs. This is done by analyzin= g=0A= SS7 data and blocking calls within the network. There are privacy concerns= =0A= over the methods used to combat voice spam. A reply to liaison is due=0A= by the=0A= end of the March. The IETF solution to voice spam is more VOIP focused, so= =0A= there may be no clash between the two solutions. A volunteer is needed to= =0A= write the response.=0A= =0A= =0A= The other liaison also from SG 17, but it VoIP oriented (via VoLTE). An=0A= IMS-based server hanging off the IMS core would make determinations of=0A= whether=0A= to pass calls based on their determination of the spaminess of a call. The= y=0A= are interested in hearing from the IETF for feedback and information on=0A= what we=0A= are doing in this space. This liaison seems more like a request for=0A= info than=0A= the previous one which seemed more defensive.=0A= =0A= =0A= Keith Drage: Calling out IMS is a red herring. You don't need to know=0A= anything=0A= about IMS to respond. It's just a centralized server accessed via SIP.=0A= Peterson notes that the accompanying picture does show a lot of IMS=0A= infrastructure and seems specific to IMS. Drage reiterates that you=0A= shouldn't=0A= need to know anything about IMS to answer the liaison. The IMS Core doesn'= t=0A= really matter. 3GPP has discussed something similar to the question in the= =0A= second liaison, but their new study item is more closely related to STIR.= =0A= =0A= =0A= Richard Barnes: summary: don't see a lot of conflict, they seem to cover=0A= separate domains, STIR's work would cover both cases. Barnes accepted=0A= the pen=0A= for writing the responses, although he kept the right to pass the pen on to= =0A= others.=0A= =0A= ***** RFC4474bis: (Jon Peterson)=0A= =0A= Jon Peterson: rfc4474bis-02: Work is separated into two buckets: 1)=0A= signaling=0A= (what is signed, how signing/verification works, canonicalization) and=0A= credentials (how signers enroll, how verifiers acquire credentials, how to= =0A= determine the authority of a credential for a identity). This draft=0A= deals with=0A= signaling. Since the -01 draft, changes are: 1) added mandatory=0A= signature over=0A= a=3Dfingerprint; 2) integrated "canon"; 3) split the references; 4) filled = in=0A= IANA Considerations; 5) added pointers to the STIR problem statement and=0A= threats.=0A= =0A= For 1) generally there isn't a problem with using multiple certificates=0A= =96 it's=0A= a corner case. Jennings suggests sorting the fingerprints by value and=0A= dropping them in. We need to make sure the case is covered, but more=0A= consideration is needed. Is something more beyond media security needed to= =0A= address baiting attacks? Robert Sparks thinks Peterson's text on the=0A= issue is=0A= fine.=0A= =0A= On the "canon" issue: a) Is the latitude for local policy too broad? If=0A= it is=0A= too broad, it's harder for the far side to successfully generate the value.= =0A= "canon" is only used with From. Should it cover To? Perhaps not. Example= =0A= given is that a toll-free number ends up translated to a different=0A= destination=0A= URL than the number dialed. Since the auth service can munge the To/From= =0A= headers before signing, text has been added to make this possibility=0A= clear. Is=0A= there a narrower constraint that can be added to delimit the scope of the= =0A= further transformations that are applied to the To/From fields and the=0A= repercussion of those transformations =96 how far can transformations be ta= ken=0A= before the recipient is unable to recreate the canonical values. There's a= =0A= real problem with cut-and-pasting of packet headers to spoof calls. Brian= =0A= Rosen: "canon" is not part of the signature. So you can't use it to=0A= determine=0A= the origin of the call. Peterson: the recipient canonicalizes the To=0A= field and=0A= compares it with the To field in "canon". If they match, then it's probabl= y=0A= worth processing the call. Otherwise, perhaps not.=0A= =0A= =0A= On the gateway issue, what about tunneling cryptographic signatures across= =0A= non-SIP protocols. Protocols such as XMPP, SS7 UUI, etc. Rosen (channelin= g=0A= Hadriel Kaplan) a=3Dfingerprint will not work through gateways, so don't=0A= bother=0A= trying. Other data could work through a gateway and would have meaning to= =0A= other protocols. Martin Dolly: gatewaying shouldn't be done. With AT&T an= d=0A= Verizon doing VoLTE interop, there's much less call for gatewaying. Peterso= n=0A= will not continue working on gateway for the draft, other than to=0A= document (or=0A= verify that the existing text documents) that all but the simplest of=0A= gateway=0A= scenarios will likely cause failures.=0A= =0A= =0A= Path forward:=0A= =0A= 1) the Date threshold text is inconsistent for what the cut-off is. 1=0A= hour is=0A= far too generous. Input is requested on the duration that provides suitabl= e=0A= security without requiring ultra precise synchronization. Brian Rosen=0A= thinks a=0A= minute would be a suitable value. The draft should have a=0A= recommendation and=0A= explanation of that value, but it shouldn't be a hard requirement=0A= because some=0A= unusual scenarios might take several sigmas more time than the usual=0A= case. The=0A= group consensus is that a minute should be fine as the default value when n= o=0A= other value has been determined by the use case.=0A= =0A= 2) Are compliance examples merited? It seems like they are genuinely=0A= useful to=0A= get the draft right.=0A= =0A= 3) The major stuff is in place. Any cruft remaining that should be excised= ?=0A= Any objection to going to WGLC with the next draft?=0A= =0A= =0A= ***** Certificates: (Jon Peterson)=0A= =0A= Jon Peterson: STIR Certificate Credentials: the draft is now a working grou= p=0A= item for a certificate-based STIR credential system. Covers telephone=0A= numbers=0A= and number ranges with some new attributes. Defines ways to obtain these= =0A= certificates. But it uses certs differently from X.509 PKIs. Enrollment ca= n=0A= be done through 1) direct assignment (from an authority or provider,=0A= which is=0A= the traditional model), delegation from above (from intermediate holders of= =0A= numbers), and 3) proof of possession (demonstrated ability to use the numbe= r=0A= "proves" it's yours; Cullen Jennings will present on this topic later).=0A= Do we=0A= need to have different levels of assurance for the different enrollment=0A= schemes=0A= and the resulting credentials? It should be made clear that signing can be= =0A= done by endpoints or (more likely) intermediaries. Credential=0A= verification can=0A= be done an intermediary or endpoint as well.=0A= =0A= Question: how does a verifier find a credential? Given an incoming=0A= call, what=0A= does the verifier need in order to retrieve a credential from a certificate= =0A= store? Peterson suggests using the Identity-Info URI to provide the=0A= disambiguating information that allows for a certificate retrieval. Sean=0A= Turner says a lookup pointer is mandatory. This particular one seems fine.= =0A= Rosen: I thought this was a hint, not the answer. Peterson: the=0A= original 4474=0A= does say this is a hint. Rosen: what about going to the logical=0A= authority and=0A= asking for all of the certificates assigned to a number. That's not=0A= likely to=0A= be a large number. Russ Housley: this doesn't work in the delegated=0A= certificate issuing model. Rosen: a delegator should cause the=0A= certificate to=0A= be issued by the logical authority. Housley: it's unlikely that we're=0A= going to=0A= see a single certificate issuer. Delegated issuance is pretty certain.=0A= Rosen:=0A= remember, we had the logical authority to prevent long, difficult-to-handle= =0A= chains of trust. Credential caching is migrating to the credential=0A= specification rather than being in the RFC4474bis.=0A= =0A= Question: should the Identity-Info contain a lightweight credential hash to= =0A= allow verifiers to know they already have the relevant credential.=0A= Jennings: a=0A= serial number suffices for this need. Turner: Agreed. That way you=0A= don't have=0A= to worry about picking among hashing algorithms. Peterson: there are=0A= options=0A= for how the hash is represented in the URI. Rosen thinks that the URI=0A= should=0A= change with the certificate. Peterson feels that a single URI with a=0A= changing=0A= hash attribute would be helpful for cleaning up the cache. Otherwise, stale= =0A= URIs are cached with no way direct way to find and remove them. For=0A= credential=0A= acquisition protocols, there are (too) many methods:=0A= push/pull/prefetch/others.=0A= Do we need a mandatory-to-implement method such as dereferencing the=0A= Identity-Info URI? Rosen: I'm leaning that way. We want to document push,= =0A= make Identity-Info URI mandatory, and have a bulk/go-to-the-source method= =0A= available as well. Peterson: why isn't there a notification system to=0A= alert an=0A= entity when a new credential is available? Housley: historical perspective= :=0A= way back when, LDAP was believed to be on a trajectory to be available=0A= ubiquitously as a way to find certificates. Peterson: do we take=0A= prefetch off=0A= the table? Or do we actually run with it? Jennings: we should talk to the= =0A= Security Area and ask them for a way to do it. SIP SUBSCRIBE is=0A= probably not=0A= the right way to do it. Peterson: I could add web push. Turner: I do=0A= have an=0A= extension to EST that allows for pulling down other certificates. Rosen: I= =0A= really want to have a simple web service where I supply a phone number=0A= and get=0A= all the assigned certificates in response. Consensus to go with=0A= Identity-Info=0A= URI as the MTI. HTTPS will be used for confidentiality, primarily, not=0A= integrity.=0A= =0A= Another open issue: how to handle ranges. STIR certificates can=0A= have handle many numbers in it. A major carrier might have a single=0A= certificate that can sign for any of their numbers. Delegation might=0A= split an=0A= authorities range of numbers over multiple sub-authorities. Adam Roach:=0A= how is=0A= number portability handled? Numbers can be moved to new authorities=0A= with ease,=0A= but that would lead to constantly changing certificates, especially if a=0A= certificate covers a large range. If putting the number or number range=0A= in the=0A= certificate is problematic, how about putting a pointer (URL) into the=0A= certificate that points to the list of numbers. Or perhaps the URL=0A= points to a=0A= service that can answer whether the number is covered by the certificate.= =0A= Peterson: please give me input on these ideas. He doesn't feel, given the= =0A= threat model, that a CA would be unwilling to sign a certificate that=0A= points to=0A= a non-signed list of numbers. Rosen: if you have a cert, you need to do=0A= cert=0A= validation, and you could use something like OCSP with extensions to=0A= check both=0A= the validity of the cert and the validity of the cert for a particular=0A= number.=0A= Barnes: are lists meant to solve a bloat problem or some other problem.=0A= And it=0A= would be a good idea to make sure the certificate/number binding=0A= validator is=0A= actually correlated with the provider. Jennings: the churn on a certificat= e=0A= depends on how many numbers are covered by a certificate. Knowing the=0A= optimal=0A= number for entries covered by a certificate would be really useful to=0A= know in=0A= order to reduce churn without having a massive number of small-range=0A= certificates. This also seems to point to using the by-reference=0A= approach as a=0A= solution. Rosen: a simple OCSP extension seems like it would be do the=0A= trick=0A= with ease. Peterson: I hope this would be palatable to others; I like the= =0A= idea. Barnes: in the WebPKI, OCSP is not very popular at the moment due=0A= to the=0A= latency it adds. A new charter item for this scheme seems reasonable. And= =0A= there are optimizations that can be done to reduce latency.=0A= =0A= Last issue: should certificates be public or confidential. The subject=0A= name is=0A= the attribute in question, giving the ability to assemble of list of number= s=0A= that are affiliated with which provider. We need feedback from the operato= r=0A= community to know if they care about this issue. Martin Dolly (AT&T): we d= o=0A= see some value in the terminating carrier being able to display a=0A= message that=0A= says "verified by ". There is some information we=0A= would=0A= want to protect from our competitors, but it's not a problem. Barnes:=0A= from the=0A= RPKI, subject names are not meaningful. There's also the PKIX subject=0A= information access attribute that can be used as well. Housley:=0A= consider the=0A= overlap between the RPKI and WHOIS as a useful example. Jennings: I=0A= question=0A= whether confidentiality is really an issue.=0A= =0A= =0A= ***** Out-of-Band: (Cullen Jennings) (This discussion was pressed for time)= =0A= =0A= Cullen Jennings: trying to revive the out-of-band signaling case. (It was= =0A= originally agreed to work on the in-band case first). In the=0A= out-of-band case,=0A= the security data is sent to a CRS (Call Recording Service) while the actua= l=0A= call is cleanly passed over a network that doesn't handle in-band signaling= .=0A= The receiving entity talks to a proxy that verifies the calling identity vi= a=0A= the CRS. There are 3 pieces of work to be done in specifying out-of-band= =0A= certificate usage: Proof-of-possession enrollment, proof-of-possession=0A= acquisition, and out-of-band certificate discovery. Let's pay attention to= =0A= out-of-band requirements while we are working on in-band certificate=0A= support.=0A= It's not clear that in-band and out-of-band certificates are the same. The= y=0A= might be.=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From nobody Mon Jan 26 19:42:46 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AB21A1BBD for ; Mon, 26 Jan 2015 19:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf5YdO0VhsxJ for ; Mon, 26 Jan 2015 19:42:41 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 0D81F1A1B99 for ; Mon, 26 Jan 2015 19:42:40 -0800 (PST) Received: (qmail 6901 invoked by uid 0); 27 Jan 2015 03:42:36 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 27 Jan 2015 03:42:36 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id kriW1p00S1MNPNq01riZxj; Mon, 26 Jan 2015 20:42:36 -0700 X-Authority-Analysis: v=2.1 cv=BqwOn+n5 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Fm5PWBbyStgA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=YNv0rlydsVwA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=XYeb9JL5MEjcw2vmtsYA:9 a=dfkV4rY-5gGSrYx9:21 a=6vk6-t-z4AvUIhCM:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=GsFcmfD10aYPBcVbOkj4h+pHLK9Gv/tQzpjCR1gKcdk=; b=KY4c76DoyJannwYnhR25c+wpRm6Rq2yxaA0YFXmPgehGKU2/yhXWgHirP5UYi7WsAnxCnP/TP/1R2uT+IHY5S+XtRbOO3fxaUbsY4MgRNuMiOtpbKRlpZ7yZ4S7FAiZG; Received: from [108.56.131.201] (port=53049 helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YFx2s-0004tt-AU; Mon, 26 Jan 2015 20:42:30 -0700 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Mon, 26 Jan 2015 22:42:25 -0500 From: Richard Shockey To: Henning Schulzrinne , Robert Sparks , "stir@ietf.org" Message-ID: Thread-Topic: [stir] Minutes: STIR: IETF91 - stirring the pot References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Minutes: STIR: IETF91 - stirring the pot X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 03:42:45 -0000 Yes please. Is anyone willing to discuss the structure of the 509 or the CRL for instance? Don=B9t worry about the distribution mechanism. That is being discussed in other forums. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us Www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 1/26/15, 10:20 PM, "Henning Schulzrinne" wrote: >The last frozen turkey left-over have hopefully been consumed, but it's >gotten awfully quiet on the list. The minutes below identify a number of >list discussion issues. Anybody care to kick off a new round? > >________________________________________ >From: stir [stir-bounces@ietf.org] on behalf of Robert Sparks >[rjsparks@nostrum.com] >Sent: Tuesday, November 25, 2014 11:06 AM >To: stir@ietf.org >Subject: [stir] Minutes: STIR: IETF91 > >Please send any necessary corrections to the chairs. >The proceeding submission cutoffs are 5-Dec for draft and 26-Dec for >corrections. >------------- >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=3Dfingerprint; 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 >=AD 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 =AD 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=3Dfingerprint 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. > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jan 27 13:10:25 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F641A8ACB for ; Tue, 27 Jan 2015 13:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.368 X-Spam-Level: X-Spam-Status: No, score=-100.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bslswCVHev6W for ; Tue, 27 Jan 2015 13:10:19 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD051A8A58 for ; Tue, 27 Jan 2015 13:10:17 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t0RL0Keb022968; Tue, 27 Jan 2015 16:10:14 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1s6fvtr8jf-12 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Jan 2015 16:10:14 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc10.cis.neustar.com ([169.254.4.25]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 16:10:10 -0500 From: "Peterson, Jon" To: Richard Shockey , Henning Schulzrinne , Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] Minutes: STIR: IETF91 - stirring the pot Thread-Index: AQHQOeAsR3yCUU0VI0ycL1HsschMbpzTppiAgACenAA= Date: Tue, 27 Jan 2015 21:10:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.195] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7694 signatures=670622 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.44756429065751e-12 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501270207 Archived-At: Subject: Re: [stir] Minutes: STIR: IETF91 - stirring the pot X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 21:10:22 -0000 DQpBY3R1YWxseSBTZWFuIGFuZCBJIGFuZCB0aGUgY2hhaXJzIGp1c3QgaGFkIGEgY2FsbCBhYm91 dCB0aGUgY2VydHMNCm1lY2hhbmlzbSBsYXN0IHdlZWsuIERvIGV4cGVjdCB0byBzZWUgYSByZXYg b2YgdGhlIGRvY3VtZW50IGluIHRoZQ0Kbm90LXRvby1kaXN0YW50IGZ1dHVyZS4gSW4gRGFsbGFz LCBleHBlY3QgdGhhdCB3ZSdyZSBnb2luZyB0byBmb2N1cw0KZGlzY3Vzc2lvbiBvbiB3YXlzIHRv IG1hbmFnZSBsYXJnZSBhbmQgbm9uLWNvbnRpZ3VvdXMgbnVtYmVyIGJsb2NrcyBpbiBhDQpzaW5n bGUgY2VydCwgYXMgd2VsbCBhcyByZWFsLXRpbWUgbWV0aG9kcyBmb3IgdmVyaWZpZXJzIHRvIGRl dGVybWluZSB0aGUNCmZyZXNobmVzcyBvciBzdGFsZW5lc3Mgb2YgY3JlZGVudGlhbHMuIEkgdGhp bmsgdGhlc2UgYXJlIHRoZSBtYWpvcg0KcXVlc3Rpb25zIHdlIG5lZWQgdG8gcmVzb2x2ZSB0byBm aW5pc2ggdXAgdGhlIGNlcnRzIG1lY2hhbmlzbS4gV2UnbGwgY29tZQ0KdG8gaXQgd2l0aCBhIGNv bmNyZXRlIHByb3Bvc2FscyAtIGJ1dCBoYXBweSB0byBoYXZlIHNvbWUgbGlzdCBkaXNjdXNzaW9u DQphYm91dCB0aGVzZSBxdWVzdGlvbnMgZmlyc3QsIGlmIHRoZXJlJ3MgYSB3aWxsIGhlcmUgdG8g ZG8gc28uDQoNCj5Eb26p9nQgd29ycnkgYWJvdXQgdGhlIGRpc3RyaWJ1dGlvbiBtZWNoYW5pc20u IFRoYXQgaXMgYmVpbmcgZGlzY3Vzc2VkIGluDQo+b3RoZXIgZm9ydW1zLg0KDQpXZSBhcmUgd29y cmllZCBhYm91dCB0aGF0IGluIHNvIGZhciBhcyB3ZSBhcmUgb24gdGhlIGhvb2sgdG8gZGVmaW5l IHNvbWUNCndheXMgZm9yIHZlcmlmaWVycyB0byBhY3F1aXJlIHRoZSBjZXJ0cyBuZWVkZWQgdG8g cGVyZm9ybSB0aGVpciBmdW5jdGlvbiAtDQp0aG91Z2ggd2Ugd2lsbCBsZWF2ZSB0aGUgZG9vciBv cGVuIHRvIGFsdGVybmF0aXZlcywgYXMgd2UgaW1hZ2luZSBvbmUgc2l6ZQ0Kd29uJ3QgZml0IGFs bC4gSXQgaXMgYWxzbyB1bmxpa2VseSB3ZSB3aWxsIHByb3NjcmliZSBhbnkgb25lIHRydWUgd2F5 IGZvcg0Kc2lnbmVycyB0byBnZXQgcHJpdmF0ZSBrZXlpbmcgbWF0ZXJpYWwsIHRob3VnaCBJIGlt YWdpbmUgaGF2aW5nIGF0IGxlYXN0DQpzb21lIGlkZWEgd291bGQgYmUgbmljZS4NCg0KSm9uIFBl dGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCg==