Hello Christian,
Thanks for your review and comments. Please see the answers inline.
Regards,
_Subir
Reviewer: Christian Huitema
Review result: Has Nits
Summary: ready with nits.
The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make informed decisions before accepting a call. The draft extends the syntax of the JSON tokens to make claims about the "resource priority" levels that can be used in the call. The goal appears to be better management of resource in SIP gateways, e.g., chosing which of many incoming calls would get access to a scarce resource.
Or in any case that's what I understood after reading the draft. It would be helpful if the introduction explained the problem that the extension is solving, maybe with a reference to the problem statement in RFC 7340 or the threat model in RFC 7375.
SD> The first two paragraphs of the Introduction will be updated as follows:
“ PASSporT [RFC8225] is a token format based on JSON Web Token (JWT) [RFC7519] for conveying cryptographically signed information about the identities involved in personal communications; it is used with STIR [RFC8224] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP [RFC3261]. This specification extends PASSporT to allow cryptographic-signing of the SIP ’Resource-Priority’ header field [RFC4412], which is used for communications resource prioritization.
[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) gateways and terminals, and by SIP proxy servers, to influence prioritization afforded to communication sessions, including PSTN Calls (e.g., to manage scarce network resources during network congestion scenarios). However, the SIP ’Resource-Priority’ header field could be spoofed and abused by unauthorized entities, the threat models and use cases of which are described in RFC 7375 and RFC 7340, respectively. Compromise of the SIP ‘Resource-Priority’ header field [RFC 4412] could lead to misuse of network resource (i.e., during congestion scenarios) resulting in impacts to the application services supported using the ’Resource-Priority’ header field."
The third paragraph of the introduction could be rearranged. As written, it mentions an extension defined in RFC 7340, which had me puzzled for a time, as that RFC is a problem statement and a list of requirements. As far as I can tell, the extension uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not say that, instead of a vague assertion that "The STIR architecture allows extensions". Or, define what you actually mean by the STIR Architecture, arguably the combination of RFC 8824 and RFC 8825.
SD> Will update the paragraph as follows:
"The RFC 8225 provides a mechanism by which an authority on the originating side of a call can provide a cryptographic assurance of the validity of the calling party telephone number in order to prevent impersonation attacks. RFC 8225 also allows extensions that 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 use a PASSPorT claim to cryptographically sign the SIP ’Resource 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’. Cryptographically signed SIP ’Resource-Priority’ header fields will allow a receiving entity to verify and act on the information with confidence that the information has not been spoofed or compromised. "
Looking at security issue, it appears that the proposal reuses for resource priority the mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My main concern is with the levels of indirection. The security mechanisms will verify that a claim is authentic by verifying that it is properly authorized by the specified authority. But at that point, the gateway will have to verify that the authority behind the claim is actually authorized to consume the resource as specified in the resource priority header. This is potentially more complex than verifying an identity claim. Section 7.2. of the security consideration explains that, but I am curious to see whether that will work in practice.
SD> Yes, the security mechanism will only verify that a claim is authentic and is properly authorized by the specified authority. To allocate the gateway resource and for other service specific authorization, providers will have specific priority treatment policies. This is specified in other organizations (e.g., ATIS) who is currently the consumer of this STIR extension (specifically to support Emergency Telecommunication Service). In this draft, we do mention that this is outside the scope of this document.
Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224.
[I-D.ietf-stir-passport] has been replaced by RFC 8225.
SD> Will update.
Reviewer: Christian Huitema
Review result: Has Nits
Summary: ready with nits.
The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a
SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The
claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make
informed decisions before accepting a call. The draft extends the syntax of the JSON tokens to
make claims about the "resource priority" levels that can be used in the call. The goal appears
to be better management of resource in SIP gateways, e.g., chosing which of many incoming
calls would get access to a scarce resource.
Or in any case that's what I understood after reading the draft. It would be helpful if the
introduction explained the problem that the extension is solving, maybe with a reference to
the problem statement in RFC 7340 or the threat model in RFC 7375.
The third paragraph of the introduction could be rearranged. As written,
it mentions an extension defined in RFC 7340, which had me puzzled for a time, as that RFC is a
problem statement and a list of requirements. As far as I can tell, the extension
uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not
say that, instead of a vague assertion that "The STIR architecture allows extensions". Or,
define what you actually mean by the STIR Architecture, arguably the combination of
RFC 8824 and RFC 8825.
Looking at security issue, it appears that the proposal reuses for resource priority the
mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My
main concern is with the levels of indirection. The security mechanisms will verify that
a claim is authentic by verifying that it is properly authorized by the specified
authority. But at that point, the gateway will have to verify that the authority
behind the claim is actually authorized to consume the resource as specified in
the resource priority header. This is potentially more complex than verifying an
identity claim. Section 7.2. of the security consideration explains that,
but I am curious to see whether that will work in practice.
Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224.
[I-D.ietf-stir-passport] has been replaced by RFC 8225.
_______________________________________________
stir mailing list
stir@xxxxxxxx
https://www.ietf.org/mailman/listinfo/stir
