Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 03 November 2016 19:22 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F983128B44; Thu, 3 Nov 2016 12:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=3e917kSe; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=juNnEzGx
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 OiJ1djQpPQaV; Thu, 3 Nov 2016 12:22:30 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B84112965B; Thu, 3 Nov 2016 12:22:30 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 84E19207F0; Thu, 3 Nov 2016 15:22:29 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 03 Nov 2016 15:22:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=yEL8tWZDMae8OKG v/ZlM/M12K0M=; b=3e917kSesQgGoHywdu7LDZtwdzJ0RP2/m6cE+PRHOzfWymJ 8HoHY2rVI5cHHXig4k6jLErrKTw9sRV8V56yUlzcqVFeAKpN86bm94P5Q5WpKCH1 RDD7OpPIdKZMrYtBwDbRFvZzpvzFG5RUJBYrob768MhcxN3tTxCjQP7HGAik=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=yEL8tWZDMae8OKGv/ZlM/M12K0M=; b=juNnEzGx+9dpq8JJp+Qf Og73fAKo8gm6Lppvr0x1vq2n7Dxjo2q/YX7QIIDTGgLmgzzEhJgrj+nRuQ3aS9o+ 8WKvsyHsCueFa5AIVvo+I1Br7WhDmC4FbXi0NUBnYyrecuwrdtZkLTf3N4k7EKHj OCIaGsgxIksJYulV2LsDj6I=
X-ME-Sender: <xms:dY4bWHRRMsNmTW01M3FVCJh0ukW3AvizU39JFaEzKlZRzTmJW9-ymQ>
X-Sasl-enc: ox7ju6D/Ed2QS9zGH4KvSgiPMbOxraN29tzUSf/AgeUI 1478200949
Received: from dhcp-10-150-9-153.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 0428EF29CD; Thu, 3 Nov 2016 15:22:28 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net>
Date: Thu, 03 Nov 2016 15:22:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <A848074C-3B55-4BC1-BD75-AA82B9159E08@cooperw.in>
References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <BE53511C-3C37-4C94-8C01-681EB413C670@sn3rd.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/5n1wwO65bOMy8L-Il8248m39IzM>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, Russ Housley <housley@vigilsec.com>, IETF STIR Mail List <stir@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 19:22:31 -0000

Hi Dave,

> On Nov 2, 2016, at 2:52 PM, Dave Crocker <dcrocker@gmail.com> wrote:
> 
> On 11/2/2016 11:41 AM, Alissa Cooper wrote:
>> My understanding of the JWT Claim Constraints is that a CA can use them to constrain which claims it expects to receive when asked to validate a cert. Let’s imagine a context in which the base set of claims defined in this spec has been extended to include a “confidence” claim that allows a carrier to differentiate between cases where a number block is fully operated by a customer (e.g., Carrier X assigns a block to Enterprise Y), delegated to a wholesaler, or operating via an SBC. Imagine that the “full,” “delegated,” and “sbc” claims about a “confidence” claim have all been specified. The permitted and excluded constraints could be used to limit claims to one of these categories, e.g., permitted would be set to “full” for the claim “confidence” for numbers in the block used by Enterprise Y.
> 
> 
> Alissa,
> 
> This presumes that claims are to be made about 'interesting' properties and issues, whereas the actual task the work is chartered for is far simpler, namely authentication of a call's identifier.

The above was a hypothetical example provided to help Alexey understand how the JWT Claim Constraints may be used. Section 8.1 of draft-ietf-stir-passport specifies the requirements for additional claims, which need to relate to the required claims and behaviors. What is presently documented is simply the extension point, not any particular extensions.

> 
> More generally, you have described here a broad model for processing that is to be performed by the receiver, based on these (standardized?) claims by the caller (or, rather, the caller's operator.)
> 
> Do you have examples of such a distributed, multi-administration policy and decision model being used successfully?
> 
> What has been defined and what you describe is quite a complex system.

I think the existing system of relationships and network paths that comprise the phone system is the root of the complexity here; the challenge for STIR has been to provide building blocks with enough flexibility to help address the requirements in RFC 7340 across a variety of different deployment scenarios and use cases.

Alissa

> 
> d/
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net