Re: [stir] Minutes: STIR: IETF91 - stirring the pot

[Richard Shockey <[e-mail]>]

Yes please.

Is anyone willing to discuss the structure of the 509 or the CRL for
instance?

Don¹t worry about the distribution mechanism. That is being discussed in
other forums.

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN [phone]





On 1/26/15, 10:20 PM, "Henning Schulzrinne" <[e-mail]>
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 [[e-mail]] on behalf of Robert Sparks
>[[e-mail]]
>Sent: Tuesday, November 25, 2014 11:06 AM
>To: [e-mail]
>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=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 <originating carrier>".  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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir