Re: [stir] current draft charter

Wilhelm Wimmreuter <wilhelm@wimmreuter.de> Fri, 28 June 2013 14:00 UTC

Return-Path: <wilhelm@wimmreuter.de>
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 C859A21F9AA9 for <stir@ietfa.amsl.com>; Fri, 28 Jun 2013 07:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level:
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moYbwJ1g8W9X for <stir@ietfa.amsl.com>; Fri, 28 Jun 2013 07:00:05 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B921F9A77 for <stir@ietf.org>; Fri, 28 Jun 2013 06:59:44 -0700 (PDT)
Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lr6Rz-1UNt653tml-00eWAH; Fri, 28 Jun 2013 15:59:43 +0200
Received: by wwnet.ww (Postfix, from userid 783) id 06C1910124D; Fri, 28 Jun 2013 15:59:41 +0200 (CEST)
Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 7F4E910123F; Fri, 28 Jun 2013 15:59:35 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="iso-8859-1"
From: Wilhelm Wimmreuter <wilhelm@wimmreuter.de>
In-Reply-To: <CDDDFE2C.1F609%jon.peterson@neustar.biz>
Date: Fri, 28 Jun 2013 15:59:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E502F34-57B8-439B-A439-8235369CA87D@wimmreuter.de>
References: <CDDDFE2C.1F609%jon.peterson@neustar.biz>
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.1085)
X-Provags-ID: V02:K0:7MMpHOCOOvfdyi3c22yYz6qjEuT7pT8eDzvPRait1lb xYjEnsJv+SuTJXh5yHbL8MZHjXDnQlk3/C1jkCZbNCGNscIDw0 VlImoJCY/IItdJ6IMv3FQ+OaH5ea72Dlx8BjJoPmrINQNPYXLB QaFaPf/84WQ/c2UN9gxMCzJbYVPESmEbxogrDlK8eQcmGC8lHE Y4c19oWFIYRw45Zgeakz6u1a/ga5VL4CZ/pASpNCaLfSbv20Th eNAijJP+sTNS5fJ2em6T9hIjFIVSb8K6cLHHhCOtNAEt/s3f8y 7n6En+FuexTbLDDGIsJDOLHXZeS93QkhOtuZLFSjp3CyfeURn4 6BbzBCui0tVl9rFcri2x8NrJFVtyYSFIi38PV4un0
Cc: "stir@ietf.org" <stir@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [stir] current draft charter
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 28 Jun 2013 14:00:09 -0000

Sorry, overlooked this replay.

Guess it basically does not matter how many certs we have.

There must be just be at least one authoritative cert be attached to each number.

 This can be a cert of an end-user or the cert of the operator that is attached to multiple numbers in case the operator / PBX or service provider signs "on behalf of" users.

 Such a model also would allow re-signing of "legitimate spoofers" such as call-centers and that like.

 It perfectly supports a delegation model which by default can be setup in a way to make the telco the primary signee and that allows the end user become a signee later on.
... This of course will allow some fiddling on the access part prior we reach the signee in that case the telco. Therefore we shall try to make the end-user the only signee for the long run.


Willi




On 12.06.2013, at 19:49, Peterson, Jon wrote:

> 
> If I understand you correctly, I agree this is a model we should explore:
> one where an authority over a number (like a carrier) could sign a
> credential controlled by an end user, who then uses that delegated
> authority to assert identity in a SIP request. While the end user cert, as
> you say, conceivably might not have the phone number in its cname or
> subjectAltName or what have you, relying parties could verify that the
> credential that signed this end user cert does indeed have that authority
> in scope.
> 
> I don't think anyone here expects a model where there would literally be a
> new certificate for every telephone number, but in some use cases, having
> a certificate for an individual telephone number might be appropriate. I
> don't think we need to make this an either/or choice, though, both models
> can coexist peaceably.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 6/12/13 2:52 AM, "Wilhelm Wimmreuter" <wilhelm@wimmreuter.de> wrote:
> 
>> Question on identifier usage:
>> 
>> Could one think about a model where the identifier "phone number" is
>> asserted in the digest of the service request and signed by any
>> authorized identity of the originating authority or user?
>> 
>> 
>> Identifier:        Authoritative Signee:
>> +1 xxx yyy zzzz    Signs private key of assigned
>>                  or delegated certificate
>>                  This cert does not necessary need the
>>                  phone number as a Cname or alt-cname
>> 
>> This would solve a number of issues discussed in various threats I think.
>> It also would allow free binding to existing certificates and could avoid
>> generating yet another cert for each phone number.
>> We shall avoid ending up in the same lifetime management issues as we
>> know from passwords today.
>> 
>> Willi
>> On 12.06.2013, at 03:46, Stephen Farrell wrote:
>> 
>>> 
>>> So based on many recent mails, I'd suggest adding "and threat model"
>>> to the problem statement deliverable and s/certificate/key management/g
>>> might be better so as not to preclude a non-certificate based
>>> solution.
>>> 
>>> And one near-nit: I think the term "identity" generates quite a bit
>>> of confusion and its generally better to talk about identifiers and
>>> not identities. In other cases that's more of a deal but since we're
>>> only dealing with phone numbers here its almost a nit.
>>> 
>>> Cheers,
>>> S.
>>> 
>>> On 06/12/2013 02:02 AM, Peterson, Jon wrote:
>>>> 
>>>> Below is the current draft of the charter, based on our prior
>>>> discussions.
>>>> 
>>>> Jon Peterson
>>>> Neustar, Inc.
>>>> 
>>>> ----
>>>> 
>>>> Name: Secure Telephone Identity Revisited (stir)
>>>> Area: RAI
>>>> 
>>>> Chairs: TBD
>>>> Area Advisor: TBD (Barnes)
>>>> 
>>>> Mailing list: (current source-auth)
>>>> To Subscribe: --
>>>> 
>>>> Over the last decade, a growing set of problems have resulted from the
>>>> lack of security mechanisms for attesting the origins of real-time
>>>> communications. Many of these problems are familiar from our experience
>>>> with email: bulk unsolicited commercial communications remain a
>>>> challenge for the traditional telephone network largely because the
>>>> source of calls can be hidden. Others are potentially more serious:
>>>> voicemail hacking, impersonating banks and similar attacks are becoming
>>>> commonplace. The technologies that obscure the caller¹s identity are
>>>> frequently gateways between the telephone network and the Internet.
>>>> 
>>>> SIP is one of the main VoIP technologies employed by these gateways. A
>>>> number of previous efforts have attacked the problem of securing the
>>>> origins of SIP communications, including RFC3325, RFC4474 and the VIPR
>>>> WG. To date, however, true cryptographic authentication of the source
>>>> of SIP calls has not seen any appreciable deployment. While several
>>>> factors contributed to this lack of success, two seem like the largest
>>>> culprits: 1) the lack of any real means of asserting authority over
>>>> telephone numbers on the Internet; and 2) a misalignment of the
>>>> integrity mechanisms proposed by RFC4474 with the highly interworked,
>>>> mediated and policy-driven deployment environment that has emerged for
>>>> SIP. The VIPR alternative, while promising, faced apparently
>>>> unavoidable privacy problems and other significant deployment hurdles.
>>>> 
>>>> Given the pressing difficulties caused by the lack of a useful
>>>> identity solution, the problem of securing the origins of SIP
>>>> communication must be revisited. Because SIP deployments are so closely
>>>> tied to the telephone network, we moreover must investigate solutions
>>>> that can work when one side of a call is in the PSTN ­ or potentially
>>>> even both. This will require a two-pronged approach: one prong relying
>>>> on information carried in SIP signaling; the other prong relying on
>>>> forming out-of-band connections between IP endpoints that are
>>>> participating in a call.
>>>> 
>>>> The changes to the RFC4474 approach to SIP signaling must include a
>>>> new capability for Identity assertions to cover telephone numbers,
>>>> rather than domain names. To conform with realistic deployments, we
>>>> must also study ways to rebalance the requirements for the scope of
>>>> RFC4474¹s integrity protection to emphasize preventing third-party
>>>> impersonation over preventing men-in-the-middle from capturing media.
>>>> 
>>>> Finally, the solution must encompass an out-of-band means for
>>>> endpoints to establish identity when there is no direct SIP signaling
>>>> path between them available, due to interworking or similar factors.
>>>> This working group will investigate a means for Internet endpoints to
>>>> discover one another in real time to verify that a telephone call
>>>> between them is in progress based on minimal evidence or configuration.
>>>> This architecture will, to the degree that is possible, reuse the
>>>> credentials defined for telephone numbers for the in-band signaling
>>>> solution, and define a discovery mechanism that provides better than
>>>> hop-by-hop security.
>>>> 
>>>> The working group will coordinate with the security area on
>>>> certificate management.
>>>> 
>>>> The working group will coordinate with RAI area groups studying the
>>>> problem of signaling through existing deployments, including INSIPID.
>>>> 
>>>> Identity is closely linked to privacy, and frequently one comes at the
>>>> cost of the other. This working group is not chartered to mandate the
>>>> presence of identity in SIP requests, and to the extent feasible it
>>>> will find privacy-friendly solutions that leak minimal information
>>>> about calls to third parties.
>>>> 
>>>> The working group will deliver the following:
>>>> 
>>>> - A problem statement detailing the deployment environment and
>>>> difficulties motivate work on secure origins
>>>> 
>>>> - A revision to SIP¹s identity features to provide several fixes:
>>>>   Changes to support certification for telephone numbers
>>>>   Changes to the signature
>>>> 
>>>> - A document describing the certificate profile required to support
>>>> telephone numbers in certificates
>>>> 
>>>> - A fallback mechanism to allow out-of-band identity establishment
>>>> during call setup
>>>> 
>>>> Milestones
>>>> 
>>>> Sep 2013   Submit problem statement for Info
>>>> Nov 2013   Submit RFC4474bis for PS
>>>> Jan 2013   Submit TN cert profile for Info
>>>> Mar 2014   Submit fallback for PS
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/stir
>>>> 
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>> 
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>