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
>