Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-09.txt

From: [email-masked]
Date: Wed, 25 May 2016 17:50:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Telephone Identity Revisited of the IETF.

        Title           : Authenticated Identity Management in the Session Initiation Protocol (SIP)
        Authors         : Jon Peterson
                          Cullen Jennings
                          Eric Rescorla
                          Chris Wendt
	Filename        : draft-ietf-stir-rfc4474bis-09.txt
	Pages           : 38
	Date            : 2016-05-25

Abstract:
   The baseline security mechanisms in the Session Initiation Protocol
   (SIP) are inadequate for cryptographically assuring the identity of
   the end users that originate SIP requests, especially in an
   interdomain context.  This document defines a mechanism for securely
   identifying originators of SIP requests.  It does so by defining a
   SIP header field for conveying a signature used for validating the
   identity, and for conveying a reference to the credentials of the
   signer.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 May 2016 01:04:27 +0000

We will discuss this in more detail on Friday's interim call, but for
those eager for an advance look at rfc4474bis-09, the interesting changes
are as follows:

Some text has been added to better explain verification service handling
of multiple Identity headers, especially in failure cases. As a part of
that, the response codes of RFC4474 have been amended slightly to take
into account the potential for multiple Identity headers, as well as some
prior changes to the protocol syntax (like Identity-Info being replaced
with the "info" parameter of Identity). Much of that was overdue clean-up.

The authentication service and verification service sections now both have
specific text about how "canon" is sent and received, as well as some
motivational text for "canon". Early implementer feedback suggested this
was vague, hopefully it is more crisp now. The text about when and how
verifiers can prefer "iat" in "canon" over the Date header has been beefed
up as well.

rfc4474bis now just points to PASSporT for the description of how "mky" is
populated, as well as for all algorithms used internally within PASSporT
to sign the headers and claims. For that reason, the algorithm registry
defined by RFC4474 has now been deprecated. Certificate signing algorithms
are out of scope of rfc4474bis, of course, and should instead appear in
stir-certs. Also, the gatewaying section is gone - most of that
conceptually resides in the PASSporT spec now.

Jon Peterson
Neustar, Inc.

On 5/25/16, 5:50 PM, "stir on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Fri, 27 May 2016 09:55:24 -0400

Jon:

Thanks for posting the update.

I think the document is ready for WG Last Call.  That said, I do have two fairly minor comments:

In Section 4, the 4th paragraph talks about "JSON representations of headers and claims which mirror certain parts of the SIP request.”  Then, the PASSporT object includes a signature over these JSON representations.  In the next paragraph, we find out that the “cannon” parameter can carry some JSON.  I think we need to be clear that the “canon” must contain exactly the same JSON representations of headers and claims as were signed.  The “canon” parameter does not solve anything if they can be different in any way.  Also, you may want to say something about base64 encoding here.

Section 5.2.1 says that “canon” is provided "purely as an optimization and debugging mechanism for the verification service.”  I thought we talked about some cases where it is needed to make things work.  I think the reason for the MAY in the second paragraph of this section is to allow those cases to work properly.  I’m not suggestion that those cases be included here, but maybe this statement should be dropped.

Russ