Re: [stir] current draft charter
"Peterson, Jon" <jon.peterson@neustar.biz> Sun, 16 June 2013 23:28 UTC
Return-Path: <jon.peterson@neustar.biz>
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 B580A21F9D41 for <stir@ietfa.amsl.com>; Sun, 16 Jun 2013 16:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.526
X-Spam-Level:
X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ZMIfBAZVRHeL for <stir@ietfa.amsl.com>; Sun, 16 Jun 2013 16:28:05 -0700 (PDT)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 818C921F9D4B for <stir@ietf.org>; Sun, 16 Jun 2013 16:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371425175; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=LHbvTS6EYF P1e93R/0RxYv6Yj8hksCgBFQfW5ign3rM=; b=APFrc5VoXnMEvAuCdZDsp4HD+3 SlO58DVj7+tsNFm321wm4J6mSwgISGD+d6gSCWScufCKcTXT9rQHRcSoQCtQ==
Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19600652; Sun, 16 Jun 2013 19:26:13 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 19:27:55 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Thread-Topic: [stir] current draft charter
Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgA=
Date: Sun, 16 Jun 2013 23:27:55 +0000
Message-ID: <CDE38BC3.20F76%jon.peterson@neustar.biz>
In-Reply-To: <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [192.168.128.73]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: uS2uB5qOWSLIeEHVtvuqxQ==
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <82977A88504F4E46BCB78DFDEA7AFA2B@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "stir@ietf.org" <stir@ietf.org>
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: Sun, 16 Jun 2013 23:28:09 -0000
> >> RFC 4474 has been standards track for 7 years; that's a long time. >> >> What is its level of operational deployment and use, so far? If the >>answer is "not much", then it's not clear that automatically invoking >>its application here is as comforting or facilitative as one might wishŠ > >The answer is less than "not much"... more like "not at all". >I'd argue the reasons it has never been deployed are: (1) people didn't >believe there was an identity spoofing problem yet, (2) it only really >validates email-style identities such as alice@foo.com, not E.164 >numbers, and (3) it's not deployable due to B2BUAs changing the fields it >would sign. I agree with those three reasons. I'd further say (1) is part of a broader trend in which the deployment community hasn't shown much interest in the security mechanisms available in SIP versus operating in effectively private environments. These identity spoofing concerns show a limitation of transitive trust in these private communities. >> If I understand the RFC 4474 model correctly, a validated Identity >>field has the semantics of asserting that the From field is valid. So >>the assertion is not limited to the owner of the From field value. >>Correct? While such a model is understandable, it dramatically >>increases the reputation-management complexity of the task. I'm not >>aware of an extant service over the public Internet of similar >>complexity. We weren't exactly proposing a domain assurance council or something like that. The authorization decision was supposed to be checking the reference integrity of the domain in the From header field against the domain in the subjectAltName of the cert (provided the cert is valid and the root trusted): if there's a match, then this was signed for by the right entity, if not, then not. I'm not sure what you mean by "not limited to the owner of the From field value." In so far as the originating domain is the "owner," then only they can sign it, if that's the limitation you're concerned about. >> >> Better still is that it's the entity making the assertion that tells >>the verifier where to look for verification information... What's seems >>to be missing from the text in RFC 4474 is how the verifier can tell >>whether the credential is a valid authorization for use of the From >>field value. (If it wasn't clear before, now you can understand why I'm >>curious about the concrete details of this authentication service.) >I think the general idea was a DKIM-like model, so if the From field >value is 'bob@foo.com', then you check the cert it points you to is for >foo.com and signed by a CA you trust. That works for email-style names >like that, because you can verify it's coming from foo.com, and foo.com >is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust >are not compromised of course) Correct. The entity making the assertion tells the verifier where a cert can be fetched, in the case that the verifier doesn't already have a cert for the signer. Whether the cert is valid, or the CA itself is trusted by the verifier, is however a different and prior question. >The hard part comes with E.164 numbers, because even if they appear as >user@domain strings, like '+12125551212@foo.com', most SIP devices would >treat it as an E.164 number - and that means it's not scoped to foo.com >at all but rather a separate, global namespace that foo.com has no >natural authority for. So with 4474 you'd have to believe foo.com is >authoritative for the number based on reputation alone - i.e., you have a >local list of domains you trust to claim E.164 numbers. That would work >for a limited number of domain names, for example the domain names of the >major carriers within a country, but it would fall apart quickly if we >ever want Enterprises to sign, or international scenarios to work. Right. At the risk of waxing philosophical about it, I'd say that RFC4474 took for granted the baseline assumption that RFC3263 would be how SIP requests were routed. If you assume SIP requests get routed by taking the domain portion of the request-URI and looking it up in the DNS to locate a SIP server, RFC4474 probably isn't a bad fit for what you do. If however SIP requests get routed based on the user portion of the Request-URI (like a TN) without reference to the DNS, then probably having a domain sign for identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty much all about that. >So one proposal so far is that there would be certs which identify the >E.164 numbers they're authoritative for (in a CN/SAN field for example), >and that cert would be signed by some CA (or chain leading to one) that >you trust. If it's a chain rather than directly signed by a CA, then >it's not clear how one goes about retrieving the certs for the chain's >links, and doing so could cause unacceptable delay. It also means we >need revocation checks for the chain. And I'd argue the management >aspects for this thing would be just as difficult as anything else >proposed so far. Although I'm not the expert, my understanding is that there are various cert chain compression techniques that could be applicable here. I've squinted a bit at OCSP and other possible real-time revocation checks for this as well. The exact amount of tolerable delay is a very interesting dimension of this problem space. I suspect we have a considerable amount of time, given all the human expectations about both post-dial delay and the wait for someone to pick up after altering. I think it's enough time to perform some non-trivial operations. But I do agree that there's no such thing as a free lunch, and that implementing a credential system for telephone numbers, even just in a single nation state, is operationally complex. In my day job, we have a few different credentials today that carriers can use to interface with various NANPA/NPAC system, and some of them already have requirements similar to what we've discussed here, like delegation for example. I think if we go down this STIR path, at the end of the day we'll end up with a system that relies on many numbers aggregated behind a single credential, on signatures and validations being performed by network elements much more so than endpoints, and similar optimizations. Provided we can do this without making e2e security impracticable, I think we'll be on the right track. Jon Peterson Neustar, Inc. >-hadriel >
- [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter Wilhelm Wimmreuter
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- [stir] Nature vs. nurture -- semantics vs. encodi… Dave Crocker
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- [stir] Not just "called party" - Re: current draf… Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] Not just "called party" - Re: current … Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] Not just "called party" - Re: current … Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Paul Kyzivat
- Re: [stir] Not just "called party" - Re: current … Dan York
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Barnes
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter Wilhelm Wimmreuter