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

Subir Das <subirdas21@gmail.com> Wed, 18 April 2018 14:00 UTC

Return-Path: <subirdas21@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF11612D80E; Wed, 18 Apr 2018 07:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozOk1-EKu1lA; Wed, 18 Apr 2018 07:00:26 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20521241FC; Wed, 18 Apr 2018 07:00:24 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id d1-v6so5134764wrj.13; Wed, 18 Apr 2018 07:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eRALVOGDD7Nh/ypF8YBe4wT8tT+L3uk8I3O9MJnWrG8=; b=G2xek1jeGa0Lr4pSjiv7VE1i3GXblhgCQIS/OK13cW9A14720kpOo/TDfoKKt7IJ1c DrgOBwoHVROgqowQof/rXc+AKK21AHkC3XB52KPkxfcch9WAn4B7WieEq/8JzkPz4Ocr 0WWOVH02qjRbJGF44vIVWSkhZhtgFcigsCPkvibnBa8nH6t2VMBxOBwIeOo/QguZv4nP 2HI6YC6hfkr6nDMVL3cJLCBMpgZyexYXtCMpG9DsDm9iEB9Wa9OdF/+3Rw3GDXBfIGmm RUH45tEaso3Ahxp8uT/k2rjeJ7WWpRi6lUHcuGW2fAbsxsuGI4QJfQ41sNn4dMT/pmxd C1cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eRALVOGDD7Nh/ypF8YBe4wT8tT+L3uk8I3O9MJnWrG8=; b=iF4LCKAIhcQDKCxWXp/jQg3S4JEAu/jzPAPHS/PbbMDSHCKoVxyG03p2c0li15ntVy f2jKQqzrK34FZois1KZo0Rf2Y3dVlISa8W+iOJpyAOLGXWTGNPaOP8Qm1FT0j9+LLneF /1ch5FjLnh5l0zE6EASERC5GavBIlJzAvCnSIrfohDLX7tO4BF0k1BMc0b23w53XT9EN J0omuWDno2sZWkE7R/6RshSqvJh73qUo2KMOg8Gk8D13rdvaSxh7PIVkIaqXxIo3UiP6 E5vHXhuQHXtfn6/QvoJI1obaYOL0+C9rihNpDjy1mdKxL7Ffi7NjUFhJVP4+5IXiky62 c6eA==
X-Gm-Message-State: ALQs6tDkU6Bno9qAE9xnQ3+KAYvvVnmJ0LeviYmlHMjaONyeXK1OOyPi rU0qfw/e/d2Yx0T7cKeSCxN4cxq5faGKeO15tpUX7Q==
X-Google-Smtp-Source: AIpwx4+X38TPToVkuyoBpzLPY8rHzj+QxGacmjozAx6CKzT/nLYDvGJatFivqOLkLpnwRMo1dpSxD/TYcJf4KPX52K8=
X-Received: by 10.28.208.202 with SMTP id h193mr1505527wmg.6.1524060023250; Wed, 18 Apr 2018 07:00:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.69.25 with HTTP; Wed, 18 Apr 2018 07:00:21 -0700 (PDT)
In-Reply-To: <152392641446.26140.16049118175653349746@ietfa.amsl.com>
References: <152392641446.26140.16049118175653349746@ietfa.amsl.com>
From: Subir Das <subirdas21@gmail.com>
Date: Wed, 18 Apr 2018 10:00:21 -0400
Message-ID: <CAFb8J8pXQ69bAEoFUUPW1RH_PUcFMcxNkawRs1jhniN7bGKoYA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: secdir@ietf.org, IETF STIR Mail List <stir@ietf.org>, draft-ietf-stir-rph.all@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1940fa4d680f056a1fe041"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3bFbSCwiKNZ2nAAdPJwg58cGOdQ>
Subject: Re: [secdir] [stir] Secdir telechat review of draft-ietf-stir-rph-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 14:00:30 -0000

Hello Christian,

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



Regards,

_Subir



-----Original Message-----
From: Christian Huitema <huitema@huitema.net>;
Sent: Monday, April 16, 2018 8:54 PM
To: secdir@ietf.org
Cc: stir@ietf.org; draft-ietf-stir-rph.all@ietf.org; ietf@ietf.org
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 <huitema@huitema.net>;
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
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>