Re: [secdir] [stir] Secdir telechat review of draft-ietf-stir-rph-03

[Subir Das <[e-mail]>]

Hello Christian,

Thanks for your review and comments. Please see the answers inline.



Regards,

_Subir



-----Original Message-----
From: Christian Huitema <[e-mail]>
Sent: Monday, April 16, 2018 8:54 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Secdir telechat review of draft-ietf-stir-rph-03



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.


On Mon, Apr 16, 2018 at 8:53 PM, Christian Huitema <[e-mail]>
wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>