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

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Jan 2015 03:20:17 +0000

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 [[email-masked]] on behalf of Robert Sparks [[email-masked]]
Sent: Tuesday, November 25, 2014 11:06 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Richard Shockey <[email-masked]>
Date: Mon, 26 Jan 2015 22:42:25 -0500

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 +1 703-593-2683

On 1/26/15, 10:20 PM, "Henning Schulzrinne" <[email-masked]>
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?
>
> it's
>repercussion of those transformations  how far can transformations be
>taken

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 27 Jan 2015 21:10:09 +0000

Actually Sean and I and the chairs just had a call about the certs
mechanism last week. Do expect to see a rev of the document in the
not-too-distant future. In Dallas, expect that we're going to focus
discussion on ways to manage large and non-contiguous number blocks in a
single cert, as well as real-time methods for verifiers to determine the
freshness or staleness of credentials. I think these are the major
questions we need to resolve to finish up the certs mechanism. We'll come
to it with a concrete proposals - but happy to have some list discussion
about these questions first, if there's a will here to do so.

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

We are worried about that in so far as we are on the hook to define some
ways for verifiers to acquire the certs needed to perform their function -
though we will leave the door open to alternatives, as we imagine one size
won't fit all. It is also unlikely we will proscribe any one true way for
signers to get private keying material, though I imagine having at least
some idea would be nice.

Jon Peterson
Neustar, Inc.