Subject: [stir] stir-06: general edits

From: Eric Burger <[email-masked]>
Date: Thu, 10 Dec 2015 21:15:53 -0500

Page 7, section 4.1
OLD
   This document specifies a role for SIP entities called an
   authentication service.  The authentication service role can be
   instantiated either by an intermediary such as a proxy server or by a
   user agent.  Any entity that instantiates the authentication service
   role MUST possess the private key of one or more credentials that can

NEW
   This document specifies a role for a SIP entity called an
   authentication service.  The authentication service can be
   instantiated, for example, by an intermediary such as a proxy server or by a
   user agent.  Any entity that instantiates the authentication service
   MUST possess the private key of one or more credentials that can

Page 8, section 4.1
OLD
   If the authentication service is not authoritative
   for the identity in question, it SHOULD process and forward the
   request normally, but it MUST NOT follow the steps below to add an
   Identity header.

NEW
   If the authentication service is not authoritative
   for the identity in question, it SHOULD process and forward the
   request normally unless local policy is to block such requests.  The
   authentication service MUST NOT follow the steps below to add an
   Identity header for an identity that the authentication service is not
   Authoritative for.

Page 8, section 4.1
OLD
   for the authentication service, see Section 5.1 for more information.

NEW
   for the authentication service; see Section 5.1 for more information.

Page 8, section 4.1
OLD
   An authentication service MUST add a Date header field to SIP
   requests if one is not already present.  The authentication service

NEW
   An authentication service MUST add a Date header field to SIP
   requests that do not have one.  The authentication service

Page 9, section 4.1
OLD
   Finally, the authentication service MUST verify that the Date header
   falls within the validity period of its credential.

NEW
   Finally, the authentication service MUST verify that both the Date header
   and the current time falls within the validity period of its credential.

Page 11, section 4.2
OLD
   how the implementation service is implemented, and on local policy.

NEW
   how the implementation service is implemented and on local policy.

Page 13, section 5.3
OLD
   purely informationally as an optimization for the verification

NEW
   purely as an optimization for the verification

Page 15, section 6
OLD
   it's clear that the signer must have authority over the telephone

NEW
   its clear that the signer must have authority over the telephone

Page 17, section 6.1
OLD
   service role will sometimes alter the telephone numbers that appear

NEW
   service will sometimes alter the telephone numbers that appear

Page 18, section 7
The Identity ABNF needs to conform to yucky 72-column ASCII RFC format

Page 19, section 7
OLD
      Note if the "alg" parameter is absent it is assumed to the value
      "RS256".

NEW
      Note if the "alg" parameter is absent the default value MUST be
     "RS256”.

Page 19, section 7
The text talks about signed-identity-digest out of nowhere. If you are well-versed in 4474, you will know what it is about. However, a SIP implementor implementing this will have no clue. I would suggest something like
   To create the claims JSON object used in the construction of the
   signed-identity-digest (see ABNF below)

Page 20, section 7
OLD
      NumericDate (as UNIX time, per [RFC7519] Section 2)/.

NEW
      NumericDate (as UNIX time, per [RFC7519] Section 2).

Page 20, section 7
OLD
   The precise formulation of this digest-string is,
   therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]):

NEW
[uh… it is therefore, what, precisely?]

Page 21, section 8
OLD
   subtracted re-ordered.  Specifying new claims follows the baseline

NEW
   subtracted or re-ordered.  Specifying new claims follows the baseline

Page 21, section 8
OLD
   correspond to any field of the SIP request, but then the optional

NEW
   correspond to any field of the SIP request, the normally optional

Page 22, section 9
OLD
   claims can be quite, and because the information it contains is

NEW
   claims can be quite long, and because the information it contains is

Page 22, section 9
OLD
   objects used to generate the hash and signature (see Section 7), but
   if the "canon" parameter is not present, the contents of the objects
   can be regenerated by constructing the object anew from the SIP
   header fields.

NEW
   objects used to generate the hash and signature (see Section 7).
   If the "canon" parameter is not present, the contents of the objects
   can be regenerated by constructing the object anew from the SIP
   header fields received.

Page 22, section 10
OLD
   assurance that the URI given in the From header field value can
   legitimately be claimed by the originator.  This URI may contain a

NEW
   assurance that a cryptographically assured authority asserts
   the originator can claim the URI given in the From header field.
  This URI may contain a

Page 23, section 10
OLD
   a valid domain portion is "this is a known user in my domain that I
   have authenticated, but I am keeping its identity private".  The use
   of the domain 'anonymous.invalid' entails that no corresponding
   authority for the domain can exist, and as a consequence,
   authentication service functions for that domain are meaningless.

NEW
   a valid domain portion is "this is a known user in my domain that I
   have authenticated, but I am keeping its identity private".

   It is worth noting two features of a fully anonymous identity.
   By fully anonymous, we mean where the domain is also an anonymous
   Domain such as 'anonymous.invalid'. The first is there is no such
   concept as an authenticated anonymous domain.  The use
   of the domain 'anonymous.invalid' entails that no corresponding
   authority for the domain can exist, and as a consequence,
   authentication service functions for that domain are meaningless.
   The second feature is more germane to the threats this document
   are mitigating [RFC 7375].  None of the relevant attacks, all of
   which rely on the attacker taking on the identity of a victim or
   hiding their identity using someone else's identity, are enabled
   by an anonymous identity.  As such, the inability to assert an
   authority over an anonymous domain is irrelevant.

Page 23, section 10
OLD
   header field; P-Asserted-Identity holds a definitive identity for the
   sender that is somehow known to a closed network of intermediaries
   that presumably the network will use this identity for billing or

NEW
   header field.  P-Asserted-Identity holds a definitive identity for the
   sender that is somehow known to a closed network of intermediaries.
   The closed network may use this identity for billing or

Page 23, section 10
OLD
   form of the telephone number of the originator of a call.  In some

NEW
   form of the telephone number of the originator of a call, if the signature
   is over a telephone number.  In some

Page 24, section 10
OLD
   leave the trust domain.

NEW
   leave the trust domain.  As a side note, history shows that closed
   networks never stay closed and one should design their implementation
   assuming connectivity to the broader Internet.

Page 24, section 11
OLD
   (see Section 23 in particular).  The following section details the

NEW
   (see Section 23 of RFC 3261 in particular).  The following section details the

Page 24, section 11
OLD
   It addresses the solution-specific attacks again in-band solutions

NEW
   It addresses the solution-specific attacks against in-band signaling

Page 24, section 11.1
OLD
   The From header field value (in ordinary operations) indicates the
   identity of the sender of the message, and the SIP address-of-record
   URI, or an embedded telephone number, in the From header field is the
   identity of a SIP user, for the purposes of this document.  Note that
   in some deployments the identity of the sender may reside in P-
   Asserted-Id instead.  The sender's identity is the key piece of
   information that this mechanism secures; the remainder of the signed
   parts of a SIP request are present to provide reference integrity and
   to prevent certain types of cut-and-paste attacks.

NEW
   For the purposes of this document, the From header field value (in ordinary operations) indicates the
   identity of the sender of the message.  The SIP address-of-record
   URI or an embedded telephone number in the From header field is the
   identity of a SIP user.  Note that
   in some deployments the identity of the sender may reside in the P-
   Asserted-Id header instead.  The sender's identity is the key piece of
   information that this mechanism secures; the remainder of the signed
   parts of a SIP request are present to provide reference integrity and
   to prevent certain types of cut-and-paste attacks.

Page 25, section 11.1
OLD
   spoofed; because a message with an identical Date from the same

NEW
   spoofed because a message with an identical Date from the same

Page 25, section 11.1
OLD
   The To header field value provides the identity of the SIP user that
   this request originally targeted.  Providing the To header field in
   the Identity signature serves two purposes: first, it prevents cut-
   and-paste attacks in which an Identity header from legitimate request
   for one user is cut-and-pasted into a request for a different user;
   second, it preserves the starting URI scheme of the request, which
   helps prevent downgrade attacks against the use of SIPS.  The To
   offers additional protection against cut-and-paste attacks beyond the
   Date header field: for example, without a signature over the To, an
   attacker who receives a call from a target could immediately forward
   the INVITE to the target's voicemail service within the Date
   interval, and the voicemail service would have no way knowing that
   the Identity header it received had been originally signed for a call
   intended for a different number.  However, note the caveats below in
   Section 11.1.1.

NEW
   The To header field value provides the identity of the SIP user that
   this request originally targeted.  Providing the To header field in
   the Identity signature serves two purposes.  First, it prevents cut-
   and-paste attacks in which an Identity header from a legitimate request
   for one user is cut-and-pasted into a request for a different user.
   Second, it preserves the starting URI scheme of the request, which
   helps prevent downgrade attacks against the use of SIPS.  The To header
   offers additional protection against cut-and-paste attacks beyond the
   Date header field.  For example, without a signature over the To, an
   attacker who receives a call from a target could immediately forward
   the INVITE to the target's voicemail service within the Date
   interval, and the voicemail service would have no way of knowing that
   the Identity header it received had been originally signed for a call
   intended for a different number.  However, note the caveats below in
   Section 11.1.1.

Page 25, section 11.1
OLD
   cut-and-pastes a legitimate request: although the target of the
   attack may accept the request, the attacker will be unable to
   exchange media with the target as they will not possess a key
   corresponding to the fingerprint.  For example there are some baiting
   attacks, launched with the REFER method or through social
   engineering, where the attacker receives a request from the target
   and reoriginates it to a third party: these might not be prevented by

NEW
   cut-and-pastes a legitimate request.  Although the target of the
   attack may accept the request, the attacker will be unable to
   exchange media with the target as they will not possess a key
   corresponding to the fingerprint.  For example there are some baiting
   attacks, launched with the REFER method or through social
   engineering, where the attacker receives a request from the target
   and reoriginates it to a third party.  These might not be prevented by

Page 26, section 11.1.1
OLD
   the backwards in a dialog, as the dialog identifiers may not match

NEW
   the backwards direction in a dialog, as the dialog identifiers may not match

I have attached the compendium of edits with change bars.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 17:51:52 +0000

Thanks for this close read, I think these kinds of fixes are at about the
right level at this point in the maturity of the document. I follow nearly
all of this. We have a bit more surgery to do to entirely split out the
JWT format from the baseline document, but this will wrap into our edit
that I aim to have out in January.

Jon Peterson
Neustar, Inc.

On 12/10/15, 6:15 PM, "stir on behalf of Eric Burger"
<[email-masked] on behalf of [email-masked]> wrote:

>     "RS256².
>The text talks about signed-identity-digest out of nowhere. If you are
>well-versed in 4474, you will know what it is about. However, a SIP
>implementor implementing this will have no clue. I would suggest
>something like
>[uhŠ it is therefore, what, precisely?]
>
>
>Page 21, section 8
>OLD