Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?

[Subir Das <[e-mail]>]

Hello Christer,
The signing entity does not have always the authority to assert the caller
identity in rph. We are submitting ver-03 draft  and it is clarified  as
follows:
"The credentials (e.g., authority responsible for authorizing
Resource-Priority) used to create the signature must have authority over
the namespace of the“rph" claim.."

-Subir

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> Another question for clarification.
>
>
>
> Section 3 contains the following example:
>
>
>
>     { "orig":{"tn":"12155551212 <(215)%20555-1212>"}
>
>      "dest":{["tn":"12125551213 <(212)%20555-1213>"]},
>
>      "iat":1443208345,
>
>      "rph":{"auth":["ets.0","wps.0"]}
>
>
>
> …and the following text:
>
>
>
>    “The credentials (e.g., authority responsible for authorizing Resource-
>
>    Priority) used to create the signature must have authority over the
>
>    "rph" claim…”
>
>
>
> Since the claim also contains “orig”, is the assumption that the signing
> entity always also has authority to assert the callers identity? I think it
> would be good to explicitly mention it.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* stir [mailto:[e-mail]] *On Behalf Of *Adam Roach
> *Sent:* 20 January 2018 00:15
> *To:* STIR Chairs <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* [stir] AD Review: draft-ietf-stir-rph-02
>
>
>
> I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who
> has worked on this document, and the authors and chairs in particular.
>
> The technical content here looks generally good to me. I'd like to see a
> few issues addressed before IETF LC. In short sumary:
>
>    - The validation section needs to add a discussion of how to treat
>    calls when the priority values in "rph" passports and SIP
>    "Resource-Priority" header fields aren't 100% identical.
>    - The examples need some adjustment.
>    - There is a minor point of ambiguity in the Security Section, but
>    this should be easy to fix, as long as the WG knows what was intended.
>    - The IANA actions need a little bit of adjustment.
>    - There are a number of minor editorial issues to be cleaned up.
>
> Detailed comments on these points are inline in the document below. I've
> removed some portions of the document on which I have no comments.
>
>
>
>
> Abstract
>
>    This document extends the STIR PASSporT specification to allow the
>
>
>
> "...the Secure Telephone Identity Revisited (STIR) Personal Assertion
> Token (PASSporT) specification defined in RFC 8122..."
>
> (See <https://www.rfc-editor.org/materials/abbrev.expansion.txt>
> <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for guidance
> on abbreviations)
>
>
>
>    inclusion of cryptographically-signed assertions of authorization for
>    the values populated in the SIP 'Resource-Priority' header field,
>    which is used for communications resource prioritization.
>
> ...
>
> 1.  Introduction
>
>    PASSporT [I-D.ietf-stir-passport] is a token format based on JWT
>    [RFC7519] for conveying cryptographically-signed information about
>    the identities involved in personal communications; it is used with
>    STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the
>    identity of the participants in real-time communications established
>    via a protocol like SIP.  This specification extends PASSporT to
>
>
>
> "...like SIP [RFC3261]..."
>
> (We want to cite SIP the first time it is mentioned)
>
>
>
>    allow cryptographic-signing of the SIP 'Resource-Priority' header
>    field defined in [RFC4412].
>
>    [RFC4412] defines the SIP 'Resource-Priority' header field for
>    communications Resource Priority.  As specified in [RFC4412], the
>    'Resource-Priority' header field may be used by SIP user agents
>    [RFC3261], including, Public Switched Telephone Network (PSTN)
>
>
>
> "...including Public Switched..."
>
> (remove the comma)
>
>
>
>    gateways and terminals, and SIP proxy servers to influence
>
>
>
> "...and by SIP proxy servers, to influence..."
>
> (add "by" and comma)
>
>
>
>    prioritization afforded to communication sessions,including PSTN
>
>
>
> "...sessions, including..."
>
> (space after comma)
>
>
>
>    calls.  However, the SIP 'Resource-Priority' header field could be
>    spoofed and abused by unauthorized entities.
>
>    The STIR architecture [RFC7340]assumes that an authority on the
>
>
>
> "...STIR architecture [RFC7340] assumes..."
>
> (space before "assumes")
>
>
>
>    originating side of a call provides a cryptographic assurance of the
>    validity of the calling party number in order to prevent
>    impersonation attacks.  The STIR architecture allows extension that
>
>
>
> "...allows extensions..."
>
>
>
>    can be utilized by authorities supporting real-time communication
>    services using the 'Resource-Priority' header field to
>    cryptographically sign the SIP 'Resource-Priority' header field and
>    convey assertion of the authorization for 'Resource-Priority'.  For
>    example, the authority on the originating side verifying the
>    authorization of a particular communication for Resource-Priority can
>
>
>
> Single quotes around 'Resource-Priority'.
>
>
>
>    use a PASSPorT claim to cryptographically-sign the SIP 'Resource-
>
>
>
> "...cryptographically sign..."
>
>
>
>    Priority' header field and convey an assertion of the authorization
>    for 'Resource-Priority'.  This will allow a receiving entity
>    (including entities located in different network domains/boundaries)
>    to verify the validity of assertions authorizing Resource-Priority.
>
>
>
> Single quotes around 'Resource-Priority'.
>
>
>
>    Cryptographically-signed SIP 'Resource-Priority' headers will allow a
>
>
>
> "...cryptographically signed SIP 'Resource-Priority' header fields..."
>
> (remove hyphen, and replace "headers" with "header fields")
>
>
>
>    receiving entity to verify and act on the information with confidence
>    that the information have not been spoofed or compromised.
>
>
>
> "...has not been spoofed or compromised."
>
>
>
>
>    This specification documents an optional extension to PASSporT and
>    the associated STIR mechanisms to provide a function to sign the SIP
>    'Resource-Priority' header field.  This PASSporT object is used to
>    provide attestation of a calling user authorization for priority
>    communications.  This is necessary in addition to the PASSporT object
>    that is used for calling user telephone number attestation.  How the
>    optional extension to PASSporT is used for real-time communications
>    supported using SIP 'Resource-Priority' header field is defined in
>    other documents and is outside the scope of this document.
>
>
>
> I assume these other documents are under development? If so, they should
> be cited here.
>
>
>
>
> 2.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>
>
>
> This document has several non-normative uses of "must", "should," and
> "may," and so it needs to use the RFC8174 boilerplate instead of the
> RFC2119 boilerplate.
>
>
>
>
> 3.  PASSporT 'rph' Claim
>
>    This specification defines a new JSON Web Token claim for "rph",
>    which provides an assertion for information in SIP 'Resource-
>    Priority'header.
>
>
>
> "...Priority' header field."
>
> (space after closing quotation mark, "header field" instead of "header")
>
>
>
>
>    The creator of a PASSporT object adds a "ppt" value of "rph" to the
>    header of a PASSporT object, in which case the PASSporT claims MUST
>    contain a "rph" claim, and any entities verifying the PASSporT object
>    will be required to understand the "ppt" extension in order to
>    process the PASSporT in question.  A PASSPorT header with the "ppt"
>    included will look as follows:
>
>    {  "typ":"passport",
>      "ppt":"rph",
>      "alg":"ES256",
>      "x5u":"https://www.example.org/cert.cer"
> <https://www.example.org/cert.cer>}
>
>
>
> Ideally, this would be either pretty-printed or canonicalized. Since it's
> too long to fit on a line in canonical form, I propose:
>
> {
>   "typ":"passport",
>   "ppt":"rph",
>   "alg":"ES256",
>   "x5u":"https://www.example.org/cert.cer"
> <https://www.example.org/cert.cer>
> }
>
>
>
>
>    The "rph" claim will provide an assertion of authorization,"auth",
>
>
>
> "...authorization, "auth", ..."
>
> (space between comma and opening quotation mark)
>
>
>
>    for information in the SIP "Resource-Priority" header field (i.e.,
>    Resource-Priority: namespace "." r-priority) based on [RFC4412].
>
>
>
> The use of the string 'namespace "." r-priority' here and elsewhere in the
> document has a detrimental impact on readability. I strongly suggest
> replacing it with "r-value" (the name of this production in RFC4412)
> everywhere.
>
>
>
>    Specifically, the "rph" claim includes assertion of the priority-
>    level of the user to be used for a given communication session.  The
>    value of the "rph" claim is an array containing one or more of JSON
>    objects for the content of the SIP 'Resource-Priority' header that is
>    being asserted of which one of the "rph" object, is mandatory.
>
>
>
> This last sentence is very hard to parse; and (based on the example) the
> value is intended to be a JSON Object (curly braces) rather than a JSON
> Array (square braces). I suggest: 'The value of the "rph" claim is an
> Object with one or more keys. Each key is associated with a JSON Array.
> These arrays contain Strings that correspond to the r-values indicated in
> the SIP "Resource-Priority" header field.' (note: "header field", not
> "header")
>
>
>
>
>    The following is an example "rph" claim for a SIP "Resource-Priority"
>    header field with a "namespace "." r-priority" value of "ets.0" and
>    with a "namespace "." r-priority" value of "wps.0".
>
>     { "orig":{"tn":"12155551212 <(215)%20555-1212>"}
>      "dest":{["tn":"12125551213 <(212)%20555-1213>"]},
>      "iat":1443208345,
>      "rph":{"auth":["ets.0","wps.0"]}
>
>
>
> As above, I recommend pretty-printing this. It's also missing a comma
> after the "orig" value, and the top-level structure is missing a closing
> brace. The value for "iat" needs to be enclosed in quotes.
>
> The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much
> of which remains assignable (cf <https://www.nationalnanpa.
> com/pdf/NRUF/ATIS-0300115.pdf>
> <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).
>
> Putting all this together, I believe what you want is:
>
> {
>   "orig":{"tn":"12155550112 <(215)%20555-0112>"},
>   "dest":{["tn":"12125550113 <(212)%20555-0113>"]},
>   "iat":"1443208345",
>   "rph":{"auth":["ets.0","wps.0"]}
> }
>
>
>
>
>    After the header and claims PASSporT objects have been constructed,
>    their signature is generated normally per the guidance in
>    [I-D.ietf-stir-passport] using the full form of PASSPorT.  The
>    credentials (e.g., authority responsible for authorizing Resource-
>    Priority) used to create the signature must have authority over the
>    "rph" claim and there is only one authority per claim.  The authority
>    MUST use its credentials (i.e., CERT) associated with the specific
>    service supported by the SIP namespace in the claim.
>
> 4.  'rph' in SIP
>
>    This section specifies SIP-specific usage for the "rph" claim in
>    PASSporT.
>
> 4.1.  Authentication Service Behavior
>
>    The Authentication Service will create the "rph" claim using the
>    values discussed in section 3 based on [RFC4412].  The construction
>    of "rph" claim follows the steps described in Section 4 of
>    [I-D.ietf-stir-rfc4474bis].
>
>    The resulting Identity header for "rph" might look as follows:
>
>
>
> "...header field..."
>
>
>
>
>    "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd
>    ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO
>    aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW
>    EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW
>    pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR
>    VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z
>    aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D
>    l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_
>    oos2P2Dyw"; info= "https://www.example.org/cert.cer"
> <https://www.example.org/cert.cer>;alg=ES256;
>    ppt="rph"
>
>
>
> This example has a number of issues:
>
>    - In the Identity header field, the signed-identity-digest shouldn't
>    be quoted.
>    - In the Identity header field, info is enclosed in <> rather than "".
>    - In the Identity header field, ppt is a token rather than a quoted
>    string.
>    - The signed-identity-digest header needs to indicate a "typ" of
>    "passport" rather than JWT, and it needs to include both a "ppt" and "x5u"
>    field.
>    - The signed-identity-digest body should contain only the passport
>    claim rather than a JSON object that itself contains a base64-encoded JWS
>    header concatenated with a claim.
>    - I believe that, even when the body is included, values in the header
>    and body need to be be canonicalized (i.e., all on one line, no spaces, in
>    alphabetical order, etc.)
>
> I would also recommend following the convention of indicating that
> line-wraps are only for readability, and including the header field name in
> the example. Putting all this together, I believe what you want is:
>
>    For example, a Identity header field for "rph" might look
>    as follows (backslashes shown for line folding only):
>
>    Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
>    iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \
>    Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \
>    6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \
>    AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \
>    18vYYFy3blXvs3fslM_oos2P2Dyw;info=<https://www.example.org/cert.cer \
>    >;alg=ES256;ppt=rph
>
> (Note: this example assumes the calling and called party numbers in the
> previous example are changed to 12155550112 <(215)%20555-0112> and
> 12155550113 <(215)%20555-0113>, respectively)
>
>
>
>
>    A SIP authentication service typically will derive the value of "rph"
>    from the 'Resource-Priority' header field based on policy associated
>    with service specific use of the "namespace "." r-priority" values
>    based on [RFC4412].  The authentication service derives the value of
>    the PASSPorT claim by verifying the authorization for Resource-
>    Priority (i.e., verifying a calling user privilege for Resource-
>    Priority based on its identity) which might be derived from customer
>    profile data or from access to external services.
>
>    [RFC4412] allows multiple "namespace "." r-priority" pairs, either in
>    a single SIP Resource-Priority header or across multiple SIP
>
>
>
> Single quotes around 'Resource-Priority'.
>
> "...header field..."
>
>
>
>    Resource-Priority headers.  However, it is not necessary to sign all
>
>
>
> Single quotes around 'Resource-Priority'.
>
> "...header fields..."
>
>
>
>    content of a SIP Resource-Priority header or all SIP Resource-
>
>
>
> Single quotes around 'Resource-Priority'.
>
> "...header field..."
>
>
>
>    Priority headers in a given SIP message.  An authority is only
>
>
>
> Single quotes around 'Resource-Priority'.
>
> "...header fields..."
>
>
>
>    responsible for signing the content of a SIP Resource-Priority header
>
>
>
> Single quotes around 'Resource-Priority'.
>
> "...header field..."
>
>
>
>    for which it has authority (e.g., a specific "namespace "."
>    r-priority").
>
> 4.2.  Verification Service Behavior
>
>    [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that
>    specifications defining "ppt" values describe any additional verifier
>    behavior.  The behavior specified for the "ppt" values of "rph" is as
>    follows:
>
>    The verification service MUST extract the value associated with the
>    "auth" key in a full form PASSPorT with a "ppt" value of "rph".  If
>    the signature validates, then the verification service can use the
>    value of the "rph" claim as validation that the calling party is
>    authorized for Resource-Priority, which would in turn be used for
>
>
>
> Single quotes around 'Resource-Priority'.
>
> This text is ambiguous about whether the validation indicates that the
> calling party is authorized to use the priorities indicated in the passport
> object, or the values in the SIP 'Resource-Priority' header field; and
> (taken on its face) implies the latter, when the intention here should
> clearly be the former.
>
> "...authorized for 'Resource-Priority' indicated in the claim. This value
> would in turn be used for..."
>
> The text also needs to say something about comparing values in the claim
> to values in the 'Resource-Priority' header field, and what a mismatch
> might mean. The document says elsewhere that the signature might only cover
> some of the r-values, which makes it entirely possible that the
> 'Resource-Priority' field might contain more values than are signed. On the
> other hand, intermediaries might reasonably remove r-values as the call is
> processed. This probably means that those removed priorities should not be
> used, even if they are present in the passport. It seems reasonable to say
> that *typical* processing by a receiving party would be to take the *union*
> of all RPH passports that they trust, and *intersect* that with the
> priorities in 'Resource-Priority' header fields to get the actual priority
> or priorities to be applied to the call (subject to local policy).
>
>
>
>    priority treatment in accordance with local policy for the associated
>    communication service.
>
>    In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires
>    "iat" value in "rph" claim to be verified.
>
>    The behavior of a SIP UAs upon receiving an INVITE containing a
>
>
>
> "...of a SIP UA upon..."
>
> or
>
> "...of SIP UAs upon..."
>
>
>
>    PASSporT object with a "rph" claim will largely remain a matter of
>    implementation policy for the specific communication service.  In
>    most cases,implementations would act based on confidence in the
>
>
>
> "...cases, implementations..."
>
> (space after comma)
>
>
>
>    veracity of this information.  The use of the compact form of
>
>
>
> Paragraph break before "The".
>
>
>
>    PASSporT is not specified in this document.
>
> 5.  Further Information Associated with Resource-Priority
>
>
>
> Single quotes around 'Resource-Priority'.
>
>
>
>
>    There may be additional information about the calling party or the
>    call that could be relevant to authorization for Resource-Priority.
>
>
>
> Single quotes around 'Resource-Priority'.
>
>
>
>    This may include information related to the device subscription of
>    the caller, or to any institutions that the caller or device is
>    associated with, or even categories of institutions.  All of these
>    data elements would benefit from the secure attestations provided by
>    the STIR and PASSporT frameworks.  The specification of the "rph"
>    claim could entail the optional presence of one or more such
>    additional information fields.
>
>    A new IANA registry has been defined to hold potential values of the
>    "rph" array; see Section 6.2.  The definition of the "rph" claim may
>    have one or more such additional information field(s).  Details of
>    such "rph" claim to encompass other data elements are left for future
>    version of this specification.
>
> 6.  IANA Considerations
>
> 6.1.  JSON Web Token Claims Registration
>
>
>
> I think there's some confusion here. You're registering a PASSporT ppt
> value, not a new JWT claim. That is to say, you're adding an entry to this
> table:
>
> https://www.iana.org/assignments/passport/passport.xhtml
>
> Not to this table:
>
> https://www.iana.org/assignments/jwt/jwt.xhtml
>
> You would only use the second table if you had a new key to add to the
> PASSporT header -- this specification does not do that.
>
> This section also needs some introductory text to let the IANA know
> exactly what to do; e.g. "This document registers a new value for the
> "Personal Assertion Token (PASSporT) Extensions" table.
>
>
>    o  ppt value: "rph"
>
>    o  Specification Document(s): Section 3 of [RFCThis]
>
> 6.2.  PASSporT 'rph' Types
>
>    This document requests that the IANA add a new entry to the PASSporT
>    Types registry for the type "rph" which is specified in [RFCThis].
>
>
>
> There isn't an IANA table called "PASSporT Types." I presume this is the
> registration we just discussed in section 6.1, and so the above two lines
> can be removed.
>
>
>
>    This specification also requests that the IANA create a new registry
>    for PASSporT "rph" types.  Registration of new PASSporT "rph" types
>    shall be under the specification required policy.  This registry is
>    to be initially populated with a single value for "auth" which is
>    specified in [RFCThis].
>
>
>
> This needs to be very clear about the fields to be included in this new
> registry (e.g., "Registry entries must contain two fields: the name of the
> 'rph' type and the specification in which the type is described").
>
>
>
>
> 7.  Security Considerations
>
>    The security considerations discussed in [I-D.ietf-stir-rfc4474bis]
>    in Section 10 are applicable here.
>
> 7.1.  Avoidance of replay and cut and paste attacks
>
>    The PASSporT extension with a "ppt" value of "rph" MUST only be sent
>    with SIP INVITE when 'Resource-Priority' header is used to convey the
>
>
>
> "...header field..."
>
>
>
>    priority of the communication as defined in [RFC4412].  To avoid the
>    replay, and cut and paste attacks, the procedures described in
>    Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed.
>
> 7.2.  Solution Considerations
>
>    The use of extension to PASSporT tokens with "ppt" value "rph" based
>    on the validation of the digital signature and the associated
>    certificate requires consideration of the authentication and
>    authority or reputation of the signer to attest to the identity being
>    asserted.  The following considerations should be recognized when
>    using PASSporT extension with "ppt" value of "rph":
>
>    o  An authority (signer) is only allowed to sign the content of a SIP
>       'Resource-Priority' header for which it has the right authority.
>
>
>
> "...header field..."
>
>
>
>       The authority that signs the token MUST have a secure method for
>       authentication of the end user or the device.
>
>    o  The verification of the signature MUST include means of verifying
>       that the signer is authoritative for the signed content of the SIP
>
>
>
> It's not clear what authority is being claimed here. Is this supposed to
> mean something like "...verifying that the signer is authoritative for the
> originating tn in the PASSporT..."? Or "...authoritative for the resource
> priority namespace in the PASSporT?" Whatever the server is purportedly
> authoritative for needs to be clearly spelled out.
>
>
>
>       'Resource-Priority' header.
>
>
>
> "...header field."
>
>
>
> /a
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>
>