Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Dave Crocker <dhc@dcrocker.net> Thu, 18 August 2016 17:06 UTC

Return-Path: <dhc@dcrocker.net>
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 0B87E12DAC1 for <stir@ietfa.amsl.com>; Thu, 18 Aug 2016 10:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.988
X-Spam-Level:
X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 bCiwk6fmtKKW for <stir@ietfa.amsl.com>; Thu, 18 Aug 2016 10:06:00 -0700 (PDT)
Received: from simon.songbird.com (unknown [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EEB12DA66 for <stir@ietf.org>; Thu, 18 Aug 2016 10:05:59 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7IH66Ul014753 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Aug 2016 10:06:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1471539967; bh=/41cOVbe5l6n5tVLYc6nuYuV1MhtS3V+EbsFwkaaiVA=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=qTva6ixeZgM9GTLqvXYoC5a+ag+sPG9wxUNZFQ/3N6EhLG6tbS3FL27xK9Gl4fjA4 rHVUK6enJcfNtX6QswMqsdl3fNjuoIlw3MxZHZvuKEH9QwaFPh4uIk/EIl6Cov/929 RMv3+dJSVlCooIsITlKG6LM1sZZLRBFLYeTjTuR8=
To: "Peterson, Jon" <jon.peterson@neustar.biz>, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>
References: <c3a85ffc-8340-ac54-4d8e-21a16fefd032@dcrocker.net> <D3D41210.1A72E4%jon.peterson@neustar.biz> <CAHBDyN7W8zkgGjeUqzGaxLfRD-nFDgD9R3kxioQ47Kbp4_B8EA@mail.gmail.com> <6bd1e4bc946a4a02a1f4fdac385984b9@PLSWE13M08.ad.sprint.com> <D3DB2EE9.1A7B59%jon.peterson@neustar.biz>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <fbf38cef-bfb0-60df-175d-c57362917c4c@dcrocker.net>
Date: Thu, 18 Aug 2016 10:05:48 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <D3DB2EE9.1A7B59%jon.peterson@neustar.biz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/wLNkWOBlEjw3Fhc4rYukvxVfahw>
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
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, 18 Aug 2016 17:06:01 -0000

On 8/18/2016 9:48 AM, Peterson, Jon wrote:
> Oh, we've allowed for multiple Identity headers for some time - the
> problem is we don't really give any reason why we allow them or any
> sense of what it might mean to have more than one. We need to say at
> least something about that, though largely this is a matter of forward
> compatibility with some future use cases that we know are under
> consideration that we don't want to rule out.


1. In the abstract, there could be different identifiers that are 
authenticated.  That's probably not supposed to be allowed for a SIP 
environment, but since there apparently can be different identifiers 
used as input to validation, perhaps it is allowed.

2. There can be different authorities used to create the authentication. 
This permits trust assessment of a combination of entities making 
validity assertions.

3. There can be different technical details to the signature.  Different 
canonicalizations, different crypto algorithms, different keys.  All of 
these might affect survival through transit and/or ability of the 
recipient to process.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net