From nobody Fri Oct 12 08:07:23 2018 Return-Path: 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 9F6BA130DCB; Fri, 12 Oct 2018 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vudt5PKtH8C4; Fri, 12 Oct 2018 08:07:19 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582E3130DC6; Fri, 12 Oct 2018 08:07:18 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id o14-v6so11687435ljj.2; Fri, 12 Oct 2018 08:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bcIpI3J7fUwouDxic9xsIsa2/pjpWsqGpAxqJJ79agY=; b=B68BZtRho/Y8nxnJ5YYGe+DvBGT7cU30S+zfX2T2kr/olqmnn9OWBT1MH95hJSHRzC UfE/z7pO4Nt/W2LRlD947FdedKwMBr2e1V/kpYtTqRKy3XkEEIFonRvEX6Xn6JQ0mzJZ bSQ5lMSAty3gnKxIh8ukggFAy3tj72BqGF81jc37nn70n2TolQYhnEusUq1XIU67OsTU bquMz9kB+Zmd/Ly2SjioR/zAzVIOngiXMbZNtBEYxh6vSmYHnDMSWR090YKj9g2hFWZ1 5vGYOvFrXGL5YOJiSgUFGaIhVyCDnvvwHdlxiVSHkgulEDxznf6FRdfy9I/6gojrfIiu GgUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bcIpI3J7fUwouDxic9xsIsa2/pjpWsqGpAxqJJ79agY=; b=H28mVw2qsmdaRE+q1ybrkCuTJpzUX7KMLU2xJigQL+iJM11YgJ11v6il/8o8hPAChI DtJAR1mIe0pNF6dqRZGj1LBGg6GT9THEcASw9apg7RA2CYSfCuT9gMTx5rMn93b/v+Hs AbIxElajg55Lkrl7Xi1Xw7F2LCNMPw81mW12FevUwazF/e3ZUY0WV3zyMEtSqxayoavv V2XSe2FMWzU3m8nKepM+V8M5fBVlhGE14L4vgSVjkwsFeNMcsrJMQJmkqXk0YESd68Ji VFF+zEEVasZUVSlVcsg/4aZEv7DRLGNkh0f/zYaqdk2G9PsEAN5+8ifveaawKESuv3fg U8kQ== X-Gm-Message-State: ABuFfojsMqqOFCLWVvfOzqXfTtdUPYbk40UGZm06pocWVlDN5zrknvRq 8GXsUAAnOJZWn8+TcFhI8ajWxSKMLttQf4Prx7d9jXOA X-Google-Smtp-Source: ACcGV62rZ2VfQx9WBtg9SnXjtd2d/13DWBvG64UPtRGqeuVTXayNvge2obPcmJ5LOMj4TyClzl4rVeM6I5dFIxO9GjE= X-Received: by 2002:a2e:1241:: with SMTP id t62-v6mr4212726lje.81.1539356836209; Fri, 12 Oct 2018 08:07:16 -0700 (PDT) MIME-Version: 1.0 References: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> In-Reply-To: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> From: Mary Barnes Date: Fri, 12 Oct 2018 10:07:03 -0500 Message-ID: To: Robert Sparks Cc: "stir@ietf.org Mail List" , draft-ietf-stir-passport-shaken@ietf.org Content-Type: multipart/alternative; boundary="00000000000067aa250578097179" Archived-At: Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 15:07:22 -0000 --00000000000067aa250578097179 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi STIR WG, We've had some off list discussion between the authors and Robert. Chris and I had proposed text something like the following for the security section: This document defines a new PASSporT [RFC 8225] extension. In general the considerations related to the security of the PASSporT are the same as those described in RFC 8225. Along with the =E2=80=9Cdest=E2=80=9D, =E2= =80=9Corig=E2=80=9D and =E2=80=9Ciat=E2=80=9D claims, this document includes defines two new claims in the SHAKEN PASSport: =E2=80=98attest=E2=80=99 and =E2=80=98origid=E2=80=99. These are= informational elements that are not dependent on or impact the original security properties of the core PASSporT claims therefore no new security considerations are introduced. Robert has proposed text something like the following: This document defines a new PASSporT [RFC 8225] extension. The considerations related to the security of the PASSporT object itself are the same as those described in RFC 8225. RFC 8224 defines how to compare the values of the "dest", "orig" and "iat" claims against fields in a SIP containing a PASSporT as part of validating that request. The values of the new "attest" and "origid" claims added by this extension are not used in such a validation step. They are not compared to fields in the SIP message. Instead, they simply carry additional information from the signer to the consumer of the PASSport. This new information shares the same integrity protection and non-repudiation properties as the base claims in the PASSporT. Note, however, that this additional information affects the semantics of the PASSporT itself. In particular the "attest" claim provides additional information about the quality of the assertion the signer makes about the requester's authorization to use a particular calling identity. The consumer of the PASSporT object can factor that quality into its processing decisions as long as it understands the extensions defined in this document. Should a PASSporT using this extension arrive at an implementation unaware of the extension, the additional claims will be ignored. Thus it is important that signers only provide PASSporTs using this extension when semantics of the assertions made by the base PASSporT hold true. My view is that the "attest" and "origid" are purely informational claims from a protocol perspective and don't have security implications - i.e., they're independent of any other fields in the SIP message. The "attest" claim can be used by an application at the calling party device to display something reflecting an originating service provider's knowledge about (and thus level of trust in) the identity of the calling party - e.g., a calling party when a call comes through a gateway ("attest" =3D c) is likel= y to be less trusted than one coming from a calling party known to the originating service provider (e.g., one of their customers with an "attest"=3DA ), so what gets displayed might be different - e.g., green che= ck mark versus warning. And, the "origid" claim could be used for traceback. We don't have any text about potential uses for the information in this STIR document, but it is described in ATIS-1000074 (and we will be adding a link to that document in the references). But, we say absolutely nothing about the semantics with regards to the consumer of the PASSporT. The claims don't define anything prescriptive about how a call is handled in the network or by the consumer. We need WG feedback on this in order to progress the draft. I'm okay with Robert's suggested first 2 paragraphs, but I don't think the 3rd is directly related to security considerations. Regards, Mary. On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks wrote: > While performing the shepherd writeup, I notice the following things: > > 1) The document has no security considerations section. The document is > so straightforward, I can understand (but shake my head at) the group > missing that so far. The document really needs to say something here. > While I don't expect it to be long, "introduces no new considerations" > is clearly not right. > > 2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions > registry" instead of "PASSporT Types registry" (to match what's at > https://www.iana.org/assignments/passport/passport.xhtml . > > 3) Can (should?) we provide a stable link in the reference for > ATIS-1000074? > > RjS > > --00000000000067aa250578097179 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi STIR WG,

We've had some off list= discussion between the authors and Robert.=C2=A0=C2=A0

Chris and I had proposed text something like the following for the se= curity section:
This document defines a new PASSporT [RFC 8225] extensio= n.= =C2=A0=C2=A0In general the considerations related to the security of= the PASSporT are the same as those described in RFC 8225.=C2=A0=C2=A0=C2=A0Along with the =E2=80=9Cdest=E2=80=9D, =E2=80=9Corig=E2=80=9D and =E2= =80=9Ciat=E2=80=9D claims, this document includes defines two new claims in= the SHAKEN PASSport: =E2=80=98attest=E2=80=99 and =E2=80=98origid=E2=80=99= .= =C2=A0=C2=A0These are informational elements that are not dependent = on or impact the original security properties of the core PASSporT claims t= herefore no new security considerations are introduced.
Robert has proposed t= ext something like the following:

This document defines a new PASSporT [= RFC 8225] extension.=C2=A0 The
considerations related to the se= curity of the PASSporT object itself
are the same as those described in RFC 8225.

=
RFC 8224 defines how to compare the values of the "= ;dest", "orig" and
"iat" claims agains= t fields in a SIP containing a PASSporT as part of
validating t= hat request. The values of the new "attest" and "origid"= ;
claims added by this extension are not used in such a validat= ion
step. They are not compared to fields in the SIP message. I= nstead,
they simply carry additional information from the signe= r to the
consumer of the PASSport. This new information shares = the same
integrity protection and non-repudiation properties as= the base
claims in the PASSporT.

= Note, however, that this additional information affects the semantics
=
additional information about the quality of the asserti= on the signer
makes about the requester's authorization to = use a particular calling
identity. The consumer of the PASSporT= object can factor that quality
into its processing decisions a= s long as it understands the
extensions defined in this documen= t. Should a PASSporT using this
extension arrive at an implemen= tation unaware of the extension, the
additional claims will be = ignored. Thus it is important that signers
only provide PASSpor= Ts using this extension when semantics of the
assertions made b= y the base PASSporT hold true.


My view is that the "attest" and "orig= id" are purely informational claims from a protocol perspective and do= n't have security implications - i.e., they're independent of any o= ther fields in the SIP message.=C2=A0 =C2=A0The "attest" claim ca= n be used by an application at the calling party device to display somethin= g reflecting an originating service provider's knowledge about (and thu= s level of trust in) the identity of=C2=A0 the calling party=C2=A0 - e.g., = a calling party when a call comes through a gateway ("attest" =3D= c) is likely to be less trusted than one coming from a calling party known= to the originating service provider (e.g., one of their customers with an = "attest"=3DA ), so what gets displayed might be different - e.g.,= green check mark versus warning.=C2=A0 And, the "origid" claim c= ould be used for traceback.=C2=A0 =C2=A0We don't have any text about po= tential uses for the information in this STIR document, but it is described= in ATIS-1000074 (and we will be adding a link to that document in the refe= rences).=C2=A0 =C2=A0But, we say absolutely nothing about the semantics wit= h regards to the consumer of the PASSporT.=C2=A0 =C2=A0The claims don't= define anything prescriptive about how a call is handled in the network or= by the consumer.=C2=A0=C2=A0

We need WG feedback = on this in order to progress the draft.=C2=A0 I'm okay with Robert'= s suggested first 2 paragraphs, but I don't think the 3rd is directly r= elated to security considerations.=C2=A0

Regards,<= /div>
Mary.=C2=A0

On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <rjsparks@nostrum.com> wrote:
While performing the shepherd writeup, I notice the f= ollowing things:

1) The document has no security considerations section. The document is so straightforward, I can understand (but shake my head at) the group
missing that so far. The document really needs to say something here.
While I don't expect it to be long, "introduces no new considerati= ons"
is clearly not right.

2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions=
registry" instead of "PASSporT Types registry" (to match wha= t's at
https://www.iana.org/assignments/passport/pa= ssport.xhtml .

3) Can (should?) we provide a stable link in the reference for ATIS-1000074= ?

RjS

--00000000000067aa250578097179-- From nobody Fri Oct 12 08:21:41 2018 Return-Path: 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 42E73130E2A for ; Fri, 12 Oct 2018 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 WZfgIy4Ab3MT for ; Fri, 12 Oct 2018 08:21:36 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB4C130E22 for ; Fri, 12 Oct 2018 08:21:36 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id q40-v6so14234622qte.0 for ; Fri, 12 Oct 2018 08:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hdW2mcdo2be6751NFlhl8Ov3w+i+J4WGLWtcsH4O7rE=; b=QcId3Pqwq/sjoiCHrxhxZeVBk0XuWoZH44KRxS+ej+efoModB3xS1+GM7Hh7TE6ImO JDLaILol/JJqGjXZZL9Y3waGXyQ7dDNDbfCJRA4xMtsmoVBlOBYxSDDJRmHOi/Xgb6BE vQHTmNclp419YNTAOmzQaFLgrI6LXHuC9UJjVg8vnTvbubAg6sUZ/LBwemg5eLVu9kES /dMV+vv89LwjYKw1gbKIR12DESMJHRvP2ZzfBLEVSyPlQzXABTvsSf8T3b/2JbpFGpRC pDSg7rFuYWxl72S0zl/a51sM0SYVdbUq6ZCCDINqclgrf4sfU+dItfuTYIcpv5/4jfVN Vuzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hdW2mcdo2be6751NFlhl8Ov3w+i+J4WGLWtcsH4O7rE=; b=LgkHzWtGOvy8qTV9qviDg5nb6gvjpIMFI4Be2efyi4ZGC9lkK3Bgqh9qXngEpr7keK chmwKCvnHxDkthMaaKd1D1oL8glx0dfRBOem145IBYOGnhHeVNxWxNnBebllAlcVoypA By1idMFrgcgIgG/r6t40gBQXhS5dOsZJW+h3btYJ1di3fGSPidhYuzb4YESy16r7GGVg taDm/ODo4l3V2dRi8UlVg6smzt1XP3XRrJQLfDlbvJNVyo0uHOG0kz8bZ19OZ0gYkNEn w6LUGqbfom0eIKWhCVEa3mkE14QINt5RH7O6jD83gWV0XxcRQZX0dhPZwvzg3l16I78x a/6Q== X-Gm-Message-State: ABuFfojOqwo7n+2iz+G0t4sA0onSIAdAC49ff4XCU+SEfKofLvnaXex+ IVYB0GLDE86F3Lknc51mnMQtOQ== X-Google-Smtp-Source: ACcGV60SRrGjdpcNwHJg27Y/2vJolkTQck/ifRc1IdhT5mYWkKJrUfYgsXQBINnIOk06uJYXlfe/9Q== X-Received: by 2002:a0c:da0c:: with SMTP id x12-v6mr6293418qvj.123.1539357695606; Fri, 12 Oct 2018 08:21:35 -0700 (PDT) Received: from [192.168.200.21] (static-71-185-213-146.phlapa.fios.verizon.net. [71.185.213.146]) by smtp.gmail.com with ESMTPSA id n25-v6sm1150436qkl.8.2018.10.12.08.21.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 08:21:34 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B990D6F0-77BC-44AF-826A-304C0091DA80" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Fri, 12 Oct 2018 11:21:33 -0400 In-Reply-To: Cc: Robert Sparks , "stir@ietf.org Mail List" , draft-ietf-stir-passport-shaken@ietf.org To: Mary Barnes References: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 15:21:39 -0000 --Apple-Mail=_B990D6F0-77BC-44AF-826A-304C0091DA80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I guess put another way, the addition of the new claims doesn=E2=80=99t = alter the security properties of the verification of the claims and = mechanisms defined in 8224/8225, which i think is what Robert=E2=80=99s = second paragraph is saying. =20 The new claims provide additional contextual information to the = verifier, and we indeed want to make sure the claims are not altered in = transit or replayed, etc, etc. but none of those security properties are = changed based on the definition of the passport extension, so i would = also agree the third paragraph is not necessary. We are only stating = what the extension mechanism is defined to do, if you don=E2=80=99t know = how to handle the new claims in a passport extension, then you = shouldn=E2=80=99t be looking at that identity header in the first place. = This is common to all extensions. > On Oct 12, 2018, at 11:07 AM, Mary Barnes = wrote: >=20 > Hi STIR WG, >=20 > We've had some off list discussion between the authors and Robert. =20 >=20 > Chris and I had proposed text something like the following for the = security section: >>> This document defines a new PASSporT [RFC 8225] extension. In = general the considerations related to the security of the PASSporT are = the same as those described in RFC 8225. Along with the =E2=80=9Cdest=E2= =80=9D, =E2=80=9Corig=E2=80=9D and =E2=80=9Ciat=E2=80=9D claims, this = document includes defines two new claims in the SHAKEN PASSport: = =E2=80=98attest=E2=80=99 and =E2=80=98origid=E2=80=99. These are = informational elements that are not dependent on or impact the original = security properties of the core PASSporT claims therefore no new = security considerations are introduced. >=20 > Robert has proposed text something like the following: >=20 > This document defines a new PASSporT [RFC 8225] extension. The > considerations related to the security of the PASSporT object itself > are the same as those described in RFC 8225. >=20 > RFC 8224 defines how to compare the values of the "dest", "orig" and > "iat" claims against fields in a SIP containing a PASSporT as part of > validating that request. The values of the new "attest" and "origid" > claims added by this extension are not used in such a validation > step. They are not compared to fields in the SIP message. Instead, > they simply carry additional information from the signer to the > consumer of the PASSport. This new information shares the same > integrity protection and non-repudiation properties as the base > claims in the PASSporT. >=20 > Note, however, that this additional information affects the semantics > of the PASSporT itself. In particular the "attest" claim provides > additional information about the quality of the assertion the signer > makes about the requester's authorization to use a particular calling > identity. The consumer of the PASSporT object can factor that quality > into its processing decisions as long as it understands the > extensions defined in this document. Should a PASSporT using this > extension arrive at an implementation unaware of the extension, the > additional claims will be ignored. Thus it is important that signers > only provide PASSporTs using this extension when semantics of the > assertions made by the base PASSporT hold true. >=20 >=20 > My view is that the "attest" and "origid" are purely informational = claims from a protocol perspective and don't have security implications = - i.e., they're independent of any other fields in the SIP message. = The "attest" claim can be used by an application at the calling party = device to display something reflecting an originating service provider's = knowledge about (and thus level of trust in) the identity of the = calling party - e.g., a calling party when a call comes through a = gateway ("attest" =3D c) is likely to be less trusted than one coming = from a calling party known to the originating service provider (e.g., = one of their customers with an "attest"=3DA ), so what gets displayed = might be different - e.g., green check mark versus warning. And, the = "origid" claim could be used for traceback. We don't have any text = about potential uses for the information in this STIR document, but it = is described in ATIS-1000074 (and we will be adding a link to that = document in the references). But, we say absolutely nothing about the = semantics with regards to the consumer of the PASSporT. The claims = don't define anything prescriptive about how a call is handled in the = network or by the consumer. =20 >=20 > We need WG feedback on this in order to progress the draft. I'm okay = with Robert's suggested first 2 paragraphs, but I don't think the 3rd is = directly related to security considerations.=20 >=20 > Regards, > Mary.=20 >=20 > On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks > wrote: > While performing the shepherd writeup, I notice the following things: >=20 > 1) The document has no security considerations section. The document = is=20 > so straightforward, I can understand (but shake my head at) the group=20= > missing that so far. The document really needs to say something here.=20= > While I don't expect it to be long, "introduces no new considerations"=20= > is clearly not right. >=20 > 2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions=20= > registry" instead of "PASSporT Types registry" (to match what's at=20 > https://www.iana.org/assignments/passport/passport.xhtml = . >=20 > 3) Can (should?) we provide a stable link in the reference for = ATIS-1000074? >=20 > RjS >=20 --Apple-Mail=_B990D6F0-77BC-44AF-826A-304C0091DA80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = guess put another way, the addition of the new claims doesn=E2=80=99t = alter the security properties of the verification of the claims and = mechanisms defined in 8224/8225, which i think is what Robert=E2=80=99s = second paragraph is saying.  

The new claims provide additional = contextual information to the verifier, and we indeed want to make sure = the claims are not altered in transit or replayed, etc, etc. but none of = those security properties are changed based on the definition of the = passport extension, so i would also agree the third paragraph is not = necessary.  We are only stating what the extension mechanism is = defined to do, if you don=E2=80=99t know how to handle the new claims in = a passport extension, then you shouldn=E2=80=99t be looking at that = identity header in the first place.  This is common to all = extensions.


On Oct = 12, 2018, at 11:07 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi STIR WG,

We've had some off list discussion between the authors and = Robert.  

Chris and I had proposed text something like the following = for the security section:
This document = defines a new PASSporT [RFC 8225] extension. &n= bsp;In general the considerations related to the security of the = PASSporT are the same as those described in RFC 8225.  &n= bsp;Along with the =E2=80=9Cdest=E2=80=9D, =E2=80=9Corig=E2=80=9D = and =E2=80=9Ciat=E2=80=9D claims, this document includes defines two new = claims in the SHAKEN PASSport: =E2=80=98attest=E2=80=99 and = =E2=80=98origid=E2=80=99. &n= bsp;These are informational elements that are not dependent on or = impact the original security properties of the core PASSporT claims = therefore no new security considerations are = introduced.
=
Robert has proposed text something like the = following:

This document defines a new PASSporT [RFC 8225] = extension.  The
considerations = related to the security of the PASSporT object = itself
are the same as those = described in RFC 8225.

RFC 8224 = defines how to compare the values of the "dest", "orig" = and
"iat" claims = against fields in a SIP containing a PASSporT as part = of
validating that = request. The values of the new "attest" and = "origid"
claims added by = this extension are not used in such a = validation
step. They are = not compared to fields in the SIP message. = Instead,
they simply = carry additional information from the signer to = the
consumer of the = PASSport. This new information shares the = same
integrity = protection and non-repudiation properties as the = base
claims in the = PASSporT.

Note, however, = that this additional information affects the = semantics
of the PASSporT = itself. In particular the "attest" claim = provides
additional = information about the quality of the assertion the = signer
makes about the = requester's authorization to use a particular = calling
identity. The = consumer of the PASSporT object can factor that = quality
into its = processing decisions as long as it understands = the
extensions = defined in this document. Should a PASSporT using = this
extension = arrive at an implementation unaware of the extension, = the
additional = claims will be ignored. Thus it is important that = signers
only provide = PASSporTs using this extension when semantics of = the
assertions made = by the base PASSporT hold true.


My view is that the "attest" and "origid" are purely = informational claims from a protocol perspective and don't have security = implications - i.e., they're independent of any other fields in the SIP = message.   The "attest" claim can be used by an application at = the calling party device to display something reflecting an originating = service provider's knowledge about (and thus level of trust in) the = identity of  the calling party  - e.g., a calling party when a = call comes through a gateway ("attest" =3D c) is likely to be less = trusted than one coming from a calling party known to the originating = service provider (e.g., one of their customers with an "attest"=3DA ), = so what gets displayed might be different - e.g., green check mark = versus warning.  And, the "origid" claim could be used for = traceback.   We don't have any text about potential uses for = the information in this STIR document, but it is described in = ATIS-1000074 (and we will be adding a link to that document in the = references).   But, we say absolutely nothing about the = semantics with regards to the consumer of the PASSporT.   The = claims don't define anything prescriptive about how a call is handled in = the network or by the consumer.  

We need WG feedback on this in order to = progress the draft.  I'm okay with Robert's suggested first 2 = paragraphs, but I don't think the 3rd is directly related to security = considerations. 

Regards,
Mary. 

On = Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <rjsparks@nostrum.com> wrote:
While performing the = shepherd writeup, I notice the following things:

1) The document has no security considerations section. The document is =
so straightforward, I can understand (but shake my head at) the group =
missing that so far. The document really needs to say something here. =
While I don't expect it to be long, "introduces no new considerations" =
is clearly not right.

2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions =
registry" instead of "PASSporT Types registry" (to match what's at
https://www.iana.org/assignments/passport/passport.xhtml = .

3) Can (should?) we provide a stable link in the reference for = ATIS-1000074?

RjS


= --Apple-Mail=_B990D6F0-77BC-44AF-826A-304C0091DA80-- From nobody Fri Oct 12 09:21:15 2018 Return-Path: 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 10648130DEB for ; Fri, 12 Oct 2018 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 VN9_grvZs-Gv for ; Fri, 12 Oct 2018 09:21:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58EB130E3C for ; Fri, 12 Oct 2018 09:21:10 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9CGL9Hv018294 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 12 Oct 2018 11:21:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: stir@ietf.org References: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> From: Robert Sparks Message-ID: Date: Fri, 12 Oct 2018 11:21:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A0D91726A10E13A21DAECC9E" Content-Language: en-US Archived-At: Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:21:14 -0000 This is a multi-part message in MIME format. --------------A0D91726A10E13A21DAECC9E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/12/18 10:21 AM, Chris Wendt wrote: > I guess put another way, the addition of the new claims doesn’t alter > the security properties of the verification of the claims and > mechanisms defined in 8224/8225, which i think is what Robert’s second > paragraph is saying. > > The new claims provide additional contextual information to the > verifier, and we indeed want to make sure the claims are not altered > in transit or replayed, etc, etc. but none of those security > properties are changed based on the definition of the passport > extension, so i would also agree the third paragraph is not necessary. >  We are only stating what the extension mechanism is defined to do, if > you don’t know how to handle the new claims in a passport extension, > then you shouldn’t be looking at that identity header in the first > place.  This is common to all extensions. I'm not sure the last two sentences are correct. Can you point at text in 8224 or 8225 that supports "shouldn't be looking at that identity header in the first place"? If so, I think _this_ security considerations section should point to that. But I'm not finding any such text on a quick skim. So unless I'm mis-remembering something, I believe I see things that say the opposite. Look at section 8.3 in RFC8225 and the end of section 9 of RFC8224. Specifically "Understanding an extension or new claims defined by the extension on the destination verification of the PASSporT is optional." Thus I think this sentence in the third paragraph is factually correct: "Should a PASSporT using this extension arrive at an implementation unaware of the extension, the additional claims will be ignored. " And the ramifications of that should be highlighted. What I tried to reinforce with the rest of that paragraph is that the additional claims are not allowed to change (specifically, weaken) the semantic of the base claims. Reminding future signers of that seems prudent. > > >> On Oct 12, 2018, at 11:07 AM, Mary Barnes > > wrote: >> >> Hi STIR WG, >> >> We've had some off list discussion between the authors and Robert. >> >> Chris and I had proposed text something like the following for the >> security section: >>>> >>>> This document defines a new PASSporT [RFC 8225] extension.In >>>> general the considerations related to the security of the >>>> PASSporT are the same as those described in RFC 8225. Along >>>> with the “dest”, “orig” and “iat” claims, this document >>>> includes defines two new claims in the SHAKEN PASSport: >>>> ‘attest’ and ‘origid’.These are informational elements that are >>>> not dependent on or impact the original security properties of >>>> the core PASSporT claims therefore no new security >>>> considerations are introduced. >>>> >> Robert has proposed text something like the following: >> >> This document defines a new PASSporT [RFC 8225] extension.  The >> >> considerations related to the security of the PASSporT object >> itself >> >> are the same as those described in RFC 8225. >> >> >> RFC 8224 defines how to compare the values of the "dest", >> "orig" and >> >> "iat" claims against fields in a SIP containing a PASSporT as >> part of >> >> validating that request. The values of the new "attest" and >> "origid" >> >> claims added by this extension are not used in such a validation >> >> step. They are not compared to fields in the SIP message. >> Instead, >> >> they simply carry additional information from the signer to the >> >> consumer of the PASSport. This new information shares the same >> >> integrity protection and non-repudiation properties as the base >> >> claims in the PASSporT. >> >> >> Note, however, that this additional information affects the >> semantics >> >> of the PASSporT itself. In particular the "attest" claim provides >> >> additional information about the quality of the assertion the >> signer >> >> makes about the requester's authorization to use a particular >> calling >> >> identity. The consumer of the PASSporT object can factor that >> quality >> >> into its processing decisions as long as it understands the >> >> extensions defined in this document. Should a PASSporT using this >> >> extension arrive at an implementation unaware of the >> extension, the >> >> additional claims will be ignored. Thus it is important that >> signers >> >> only provide PASSporTs using this extension when semantics of the >> >> assertions made by the base PASSporT hold true. >> >> >> >> My view is that the "attest" and "origid" are purely informational >> claims from a protocol perspective and don't have security >> implications - i.e., they're independent of any other fields in the >> SIP message.   The "attest" claim can be used by an application at >> the calling party device to display something reflecting an >> originating service provider's knowledge about (and thus level of >> trust in) the identity of  the calling party  - e.g., a calling party >> when a call comes through a gateway ("attest" = c) is likely to be >> less trusted than one coming from a calling party known to the >> originating service provider (e.g., one of their customers with an >> "attest"=A ), so what gets displayed might be different - e.g., green >> check mark versus warning.  And, the "origid" claim could be used for >> traceback.   We don't have any text about potential uses for the >> information in this STIR document, but it is described in >> ATIS-1000074 (and we will be adding a link to that document in the >> references).   But, we say absolutely nothing about the semantics >> with regards to the consumer of the PASSporT.   The claims don't >> define anything prescriptive about how a call is handled in the >> network or by the consumer. >> >> We need WG feedback on this in order to progress the draft.  I'm okay >> with Robert's suggested first 2 paragraphs, but I don't think the 3rd >> is directly related to security considerations. >> >> Regards, >> Mary. >> >> On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks > > wrote: >> >> While performing the shepherd writeup, I notice the following things: >> >> 1) The document has no security considerations section. The >> document is >> so straightforward, I can understand (but shake my head at) the >> group >> missing that so far. The document really needs to say something >> here. >> While I don't expect it to be long, "introduces no new >> considerations" >> is clearly not right. >> >> 2) In section 9.2, say "Personal Assertion Token (PASSporT) >> Extensions >> registry" instead of "PASSporT Types registry" (to match what's at >> https://www.iana.org/assignments/passport/passport.xhtml .. >> >> 3) Can (should?) we provide a stable link in the reference for >> ATIS-1000074? >> >> RjS >> > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --------------A0D91726A10E13A21DAECC9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/12/18 10:21 AM, Chris Wendt wrote:
I guess put another way, the addition of the new claims doesn’t alter the security properties of the verification of the claims and mechanisms defined in 8224/8225, which i think is what Robert’s second paragraph is saying.  

The new claims provide additional contextual information to the verifier, and we indeed want to make sure the claims are not altered in transit or replayed, etc, etc. but none of those security properties are changed based on the definition of the passport extension, so i would also agree the third paragraph is not necessary.  We are only stating what the extension mechanism is defined to do, if you don’t know how to handle the new claims in a passport extension, then you shouldn’t be looking at that identity header in the first place.  This is common to all extensions.
I'm not sure the last two sentences are correct. Can you point at text in 8224 or 8225 that supports "shouldn't be looking at that identity header in the first place"? If so, I think _this_ security considerations section should point to that. But I'm not finding any such text on a quick skim.

So unless I'm mis-remembering something, I believe I see things that say the opposite. Look at section 8.3 in RFC8225 and the end of section 9 of RFC8224. Specifically "Understanding an extension or new claims defined by the extension on the destination verification of the PASSporT is optional."

Thus I think this sentence in the third paragraph is factually correct: "Should a PASSporT using this extension arrive at an implementation unaware of the extension, the additional claims will be ignored. " And the ramifications of that should be highlighted. What I tried to reinforce with the rest of that paragraph is that the additional claims are not allowed to change (specifically, weaken) the semantic of the base claims. Reminding future signers of that seems prudent.



On Oct 12, 2018, at 11:07 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi STIR WG,

We've had some off list discussion between the authors and Robert.  

Chris and I had proposed text something like the following for the security section:
This document defines a new PASSporT [RFC 8225] extension.  In general the considerations related to the security of the PASSporT are the same as those described in RFC 8225.   Along with the “dest”, “orig” and “iat” claims, this document includes defines two new claims in the SHAKEN PASSport: ‘attest’ and ‘origid’.  These are informational elements that are not dependent on or impact the original security properties of the core PASSporT claims therefore no new security considerations are introduced.
Robert has proposed text something like the following:

This document defines a new PASSporT [RFC 8225] extension.  The
considerations related to the security of the PASSporT object itself
are the same as those described in RFC 8225.

RFC 8224 defines how to compare the values of the "dest", "orig" and
"iat" claims against fields in a SIP containing a PASSporT as part of
validating that request. The values of the new "attest" and "origid"
claims added by this extension are not used in such a validation
step. They are not compared to fields in the SIP message. Instead,
they simply carry additional information from the signer to the
consumer of the PASSport. This new information shares the same
integrity protection and non-repudiation properties as the base
claims in the PASSporT.

Note, however, that this additional information affects the semantics
of the PASSporT itself. In particular the "attest" claim provides
additional information about the quality of the assertion the signer
makes about the requester's authorization to use a particular calling
identity. The consumer of the PASSporT object can factor that quality
into its processing decisions as long as it understands the
extensions defined in this document. Should a PASSporT using this
extension arrive at an implementation unaware of the extension, the
additional claims will be ignored. Thus it is important that signers
only provide PASSporTs using this extension when semantics of the
assertions made by the base PASSporT hold true.


My view is that the "attest" and "origid" are purely informational claims from a protocol perspective and don't have security implications - i.e., they're independent of any other fields in the SIP message.   The "attest" claim can be used by an application at the calling party device to display something reflecting an originating service provider's knowledge about (and thus level of trust in) the identity of  the calling party  - e.g., a calling party when a call comes through a gateway ("attest" = c) is likely to be less trusted than one coming from a calling party known to the originating service provider (e.g., one of their customers with an "attest"=A ), so what gets displayed might be different - e.g., green check mark versus warning.  And, the "origid" claim could be used for traceback.   We don't have any text about potential uses for the information in this STIR document, but it is described in ATIS-1000074 (and we will be adding a link to that document in the references).   But, we say absolutely nothing about the semantics with regards to the consumer of the PASSporT.   The claims don't define anything prescriptive about how a call is handled in the network or by the consumer.  

We need WG feedback on this in order to progress the draft.  I'm okay with Robert's suggested first 2 paragraphs, but I don't think the 3rd is directly related to security considerations. 

Regards,
Mary. 

On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <rjsparks@nostrum.com> wrote:
While performing the shepherd writeup, I notice the following things:

1) The document has no security considerations section. The document is
so straightforward, I can understand (but shake my head at) the group
missing that so far. The document really needs to say something here.
While I don't expect it to be long, "introduces no new considerations"
is clearly not right.

2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions
registry" instead of "PASSporT Types registry" (to match what's at
https://www.iana.org/assignments/passport/passport.xhtml ..

3) Can (should?) we provide a stable link in the reference for ATIS-1000074?

RjS




_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--------------A0D91726A10E13A21DAECC9E-- From nobody Fri Oct 12 12:01:38 2018 Return-Path: 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 AEE7E130EA7 for ; Fri, 12 Oct 2018 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 Qru7Qp2X-28g for ; Fri, 12 Oct 2018 12:01:19 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A574130EF1 for ; Fri, 12 Oct 2018 12:00:49 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id 84-v6so8314335qkf.0 for ; Fri, 12 Oct 2018 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6Q7YDUG4T5KQAlmtvpniHAfhib0wpOgJu/nn5cqz4Kc=; b=Qjt1vfee/ETZ48MRUhJYZFNZHdN3IPUeZVS6OzwNZ3ZrTnhG2CWsB+aEIIKToP/JS8 Xr6hJwvpPe9R0Zs4pUHDN9Q0Lgm0u2KKsgFRW/b4/SSdx012TS4DUTgWCnEivvSSFjsB 7LQSp+KqWfSYMjIzIsFzgCDGik32NiwMNbkD+d+HsytLmCpGzSIgnPDdlSvl9OEuv9Yo dI2qv0gi8QAcsDzJEhaaUPY6f/eJh0/rWoesT2uHNRXQa1Nk0JUSOmnNynU1i0ZRJZzR cfmkSADc/Q5Yy3IJZxJCaqqj+dbo8Ckl62FVCqLYnulkOZHhpIr633+wjpXjI6eAQG/4 plAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6Q7YDUG4T5KQAlmtvpniHAfhib0wpOgJu/nn5cqz4Kc=; b=uhzdzlYYqpbfLrwO9hBo6YBjfzcvZZZRrES/dwApxAjxmJ4mL8h7d1srxjoeU7vtU6 NfGc1vg/dDheM9lDTbSe4/1KxKJnklebbvsCd5aVkKb45WTnvPZhT7OofkRUYTz0q0Ol et8xbO4Oxuhukw6/DMmmB3QNCvcUOpsqODHUu2a9NQIodSEFRv7Jrc+zDWJSK+fjOIpN BKeCGJiaPVGDakn5PcU+zbecc6fN4Cn8oKvx2sSJMEsM9f5+2vjOm/FEbjkwgO8TkQKJ DLuqbCPLBuzY1eU0q57L6/IaRr+/TIpR4Pks5VRaRRisL8JwvxfMVgoDlDc8QbQz3iN4 EYCw== X-Gm-Message-State: ABuFfojmvk2Lwm2S9N9isBRTjieJPx3zS7AfzSneoQid/ml1Ta26awHh KvxMLOSIq+uzAh8vqMB6egYtOeeVDBo= X-Google-Smtp-Source: ACcGV6289ztdPo+cXUlUv+Ke9i7SZaWdng9bRHARcQHK+zm39H7Hy66aU0Tj/J78LExCpIrs6i8a4Q== X-Received: by 2002:a37:a9cd:: with SMTP id s196-v6mr6956973qke.342.1539370848595; Fri, 12 Oct 2018 12:00:48 -0700 (PDT) Received: from ?IPv6:2601:41:c100:3b00:1952:9bc2:acc6:8faf? ([2601:41:c100:3b00:1952:9bc2:acc6:8faf]) by smtp.gmail.com with ESMTPSA id q21-v6sm1448002qta.77.2018.10.12.12.00.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 12:00:47 -0700 (PDT) From: Chris Wendt Message-Id: <2B0D1A98-3F27-4CF0-AA87-D800070AC222@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD66A679-3D76-4B54-8479-BBC2284F7C3E" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Fri, 12 Oct 2018 15:00:46 -0400 In-Reply-To: Cc: stir@ietf.org To: Robert Sparks References: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:01:36 -0000 --Apple-Mail=_CD66A679-3D76-4B54-8479-BBC2284F7C3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is described in Section 8.3 of RFC8225. The thing i don=E2=80=99t agree with is the idea that you should pay = attention to the base PASSporT claims and ignore the extension claims. = The base PASSporT claims are for supporting the security of the PASSporT = object and claims to be associated with a particular call (replay = attack, etc) and the extension is the real meaning of what information = you are trying to portray in an extended PASSporT. If you only intend = the receiver to validate the calling identity, you should only send a = base PASSporT, a PASSporT with only base claims. It=E2=80=99s all or = nothing, you either know how to interpret the PASSporT extension or not = was the original intent. > On Oct 12, 2018, at 12:21 PM, Robert Sparks = wrote: >=20 >=20 >=20 > On 10/12/18 10:21 AM, Chris Wendt wrote: >> I guess put another way, the addition of the new claims doesn=E2=80=99t= alter the security properties of the verification of the claims and = mechanisms defined in 8224/8225, which i think is what Robert=E2=80=99s = second paragraph is saying. =20 >>=20 >> The new claims provide additional contextual information to the = verifier, and we indeed want to make sure the claims are not altered in = transit or replayed, etc, etc. but none of those security properties are = changed based on the definition of the passport extension, so i would = also agree the third paragraph is not necessary. We are only stating = what the extension mechanism is defined to do, if you don=E2=80=99t know = how to handle the new claims in a passport extension, then you = shouldn=E2=80=99t be looking at that identity header in the first place. = This is common to all extensions. > I'm not sure the last two sentences are correct. Can you point at text = in 8224 or 8225 that supports "shouldn't be looking at that identity = header in the first place"? If so, I think _this_ security = considerations section should point to that. But I'm not finding any = such text on a quick skim. >=20 > So unless I'm mis-remembering something, I believe I see things that = say the opposite. Look at section 8.3 in RFC8225 and the end of section = 9 of RFC8224. Specifically "Understanding an extension or new claims = defined by the extension on the destination verification of the PASSporT = is optional." >=20 > Thus I think this sentence in the third paragraph is factually = correct: "Should a PASSporT using this extension arrive at an = implementation unaware of the extension, the additional claims will be = ignored. " And the ramifications of that should be highlighted. What I = tried to reinforce with the rest of that paragraph is that the = additional claims are not allowed to change (specifically, weaken) the = semantic of the base claims. Reminding future signers of that seems = prudent. >=20 >>=20 >>=20 >>> On Oct 12, 2018, at 11:07 AM, Mary Barnes = > wrote: >>>=20 >>> Hi STIR WG, >>>=20 >>> We've had some off list discussion between the authors and Robert. =20= >>>=20 >>> Chris and I had proposed text something like the following for the = security section: >>>>> This document defines a new PASSporT [RFC 8225] extension. In = general the considerations related to the security of the PASSporT are = the same as those described in RFC 8225. Along with the =E2=80=9Cdest=E2= =80=9D, =E2=80=9Corig=E2=80=9D and =E2=80=9Ciat=E2=80=9D claims, this = document includes defines two new claims in the SHAKEN PASSport: = =E2=80=98attest=E2=80=99 and =E2=80=98origid=E2=80=99. These are = informational elements that are not dependent on or impact the original = security properties of the core PASSporT claims therefore no new = security considerations are introduced. >>>=20 >>> Robert has proposed text something like the following: >>>=20 >>> This document defines a new PASSporT [RFC 8225] extension. The >>> considerations related to the security of the PASSporT object itself >>> are the same as those described in RFC 8225. >>>=20 >>> RFC 8224 defines how to compare the values of the "dest", "orig" and >>> "iat" claims against fields in a SIP containing a PASSporT as part = of >>> validating that request. The values of the new "attest" and "origid" >>> claims added by this extension are not used in such a validation >>> step. They are not compared to fields in the SIP message. Instead, >>> they simply carry additional information from the signer to the >>> consumer of the PASSport. This new information shares the same >>> integrity protection and non-repudiation properties as the base >>> claims in the PASSporT. >>>=20 >>> Note, however, that this additional information affects the = semantics >>> of the PASSporT itself. In particular the "attest" claim provides >>> additional information about the quality of the assertion the signer >>> makes about the requester's authorization to use a particular = calling >>> identity. The consumer of the PASSporT object can factor that = quality >>> into its processing decisions as long as it understands the >>> extensions defined in this document. Should a PASSporT using this >>> extension arrive at an implementation unaware of the extension, the >>> additional claims will be ignored. Thus it is important that signers >>> only provide PASSporTs using this extension when semantics of the >>> assertions made by the base PASSporT hold true. >>>=20 >>>=20 >>> My view is that the "attest" and "origid" are purely informational = claims from a protocol perspective and don't have security implications = - i.e., they're independent of any other fields in the SIP message. = The "attest" claim can be used by an application at the calling party = device to display something reflecting an originating service provider's = knowledge about (and thus level of trust in) the identity of the = calling party - e.g., a calling party when a call comes through a = gateway ("attest" =3D c) is likely to be less trusted than one coming = from a calling party known to the originating service provider (e.g., = one of their customers with an "attest"=3DA ), so what gets displayed = might be different - e.g., green check mark versus warning. And, the = "origid" claim could be used for traceback. We don't have any text = about potential uses for the information in this STIR document, but it = is described in ATIS-1000074 (and we will be adding a link to that = document in the references). But, we say absolutely nothing about the = semantics with regards to the consumer of the PASSporT. The claims = don't define anything prescriptive about how a call is handled in the = network or by the consumer. =20 >>>=20 >>> We need WG feedback on this in order to progress the draft. I'm = okay with Robert's suggested first 2 paragraphs, but I don't think the = 3rd is directly related to security considerations.=20 >>>=20 >>> Regards, >>> Mary.=20 >>>=20 >>> On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks > wrote: >>> While performing the shepherd writeup, I notice the following = things: >>>=20 >>> 1) The document has no security considerations section. The document = is=20 >>> so straightforward, I can understand (but shake my head at) the = group=20 >>> missing that so far. The document really needs to say something = here.=20 >>> While I don't expect it to be long, "introduces no new = considerations"=20 >>> is clearly not right. >>>=20 >>> 2) In section 9.2, say "Personal Assertion Token (PASSporT) = Extensions=20 >>> registry" instead of "PASSporT Types registry" (to match what's at=20= >>> https://www.iana.org/assignments/passport/passport.xhtml = .. >>>=20 >>> 3) Can (should?) we provide a stable link in the reference for = ATIS-1000074? >>>=20 >>> RjS >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_CD66A679-3D76-4B54-8479-BBC2284F7C3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is described in Section 8.3 of RFC8225.

The thing i don=E2=80=99t agree with is = the idea that you should pay attention to the base PASSporT claims and = ignore the extension claims.  The base PASSporT claims are for = supporting the security of the PASSporT object and claims to be = associated with a particular call (replay attack, etc) and the extension = is the real meaning of what information you are trying to portray in an = extended PASSporT.  If you only intend the receiver to validate the = calling identity, you should only send a base PASSporT, a PASSporT with = only base claims.  It=E2=80=99s all or nothing, you either know how = to interpret the PASSporT extension or not was the original intent.

On Oct 12, 2018, at 12:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:



On = 10/12/18 10:21 AM, Chris Wendt wrote:
I= guess put another way, the addition of the new claims doesn=E2=80=99t = alter the security properties of the verification of the claims and = mechanisms defined in 8224/8225, which i think is what Robert=E2=80=99s = second paragraph is saying.  

The new claims provide additional = contextual information to the verifier, and we indeed want to make sure = the claims are not altered in transit or replayed, etc, etc. but none of = those security properties are changed based on the definition of the = passport extension, so i would also agree the third paragraph is not = necessary.  We are only stating what the extension mechanism is = defined to do, if you don=E2=80=99t know how to handle the new claims in = a passport extension, then you shouldn=E2=80=99t be looking at that = identity header in the first place.  This is common to all = extensions.
I'm not sure the last two = sentences are correct. Can you point at text in 8224 or 8225 that = supports "shouldn't be looking at that identity header in the first = place"? If so, I think _this_ security considerations section should = point to that. But I'm not finding any such text on a quick = skim.

So unless I'm = mis-remembering something, I believe I see things that say the opposite. = Look at section 8.3 in RFC8225 and the end of section 9 of RFC8224. = Specifically "Understanding an extension or new claims defined by the = extension on the destination verification of the PASSporT is = optional."

Thus I think this sentence = in the third paragraph is factually correct: "Should a PASSporT using = this extension arrive at an implementation unaware of the extension, the = additional claims will be ignored. " And the ramifications of that = should be highlighted. What I tried to reinforce with the rest of that = paragraph is that the additional claims are not allowed to change = (specifically, weaken) the semantic of the base claims. Reminding future = signers of that seems prudent.



On Oct 12, 2018, at 11:07 AM, Mary Barnes = <mary.ietf.barnes@gmail.com> = wrote:

Hi STIR WG,

We've had some off list discussion = between the authors and Robert.  

Chris and I had proposed text something = like the following for the security section:
This document defines a new PASSporT [RFC 8225] extension. &n= bsp;In general the considerations related to the security of the = PASSporT are the same as those described in RFC 8225.  &n= bsp;Along with the =E2=80=9Cdest=E2=80=9D, =E2=80=9Corig=E2=80=9D = and =E2=80=9Ciat=E2=80=9D claims, this document includes defines two new = claims in the SHAKEN PASSport: =E2=80=98attest=E2=80=99 and = =E2=80=98origid=E2=80=99. &n= bsp;These are informational elements that are not dependent on or = impact the original security properties of the core PASSporT claims = therefore no new security considerations are = introduced.
=
Robert has proposed text something like the = following:

This document defines a new = PASSporT [RFC 8225] extension.  The
considerations related to the security of the = PASSporT object itself
are = the same as those described in RFC = 8225.

RFC 8224 defines how to compare the values of the "dest", = "orig" and
"iat" claims = against fields in a SIP containing a PASSporT as part = of
validating that = request. The values of the new "attest" and = "origid"
claims added = by this extension are not used in such a = validation
step. They = are not compared to fields in the SIP message. = Instead,
they simply = carry additional information from the signer to = the
consumer of the = PASSport. This new information shares the = same
integrity = protection and non-repudiation properties as the = base
claims in the = PASSporT.

Note, = however, that this additional information affects the = semantics
of the = PASSporT itself. In particular the "attest" claim = provides
additional = information about the quality of the assertion the = signer
makes about the = requester's authorization to use a particular = calling
identity. The = consumer of the PASSporT object can factor that = quality
into its = processing decisions as long as it understands = the
extensions = defined in this document. Should a PASSporT using = this
extension arrive = at an implementation unaware of the extension, = the
additional claims = will be ignored. Thus it is important that = signers
only provide = PASSporTs using this extension when semantics of = the
assertions made = by the base PASSporT hold true.


My view is that the "attest" and "origid" are purely = informational claims from a protocol perspective and don't have security = implications - i.e., they're independent of any other fields in the SIP = message.   The "attest" claim can be used by an application at = the calling party device to display something reflecting an originating = service provider's knowledge about (and thus level of trust in) the = identity of  the calling party  - e.g., a calling party when a = call comes through a gateway ("attest" =3D c) is likely to be less = trusted than one coming from a calling party known to the originating = service provider (e.g., one of their customers with an "attest"=3DA ), = so what gets displayed might be different - e.g., green check mark = versus warning.  And, the "origid" claim could be used for = traceback.   We don't have any text about potential uses for = the information in this STIR document, but it is described in = ATIS-1000074 (and we will be adding a link to that document in the = references).   But, we say absolutely nothing about the = semantics with regards to the consumer of the PASSporT.   The = claims don't define anything prescriptive about how a call is handled in = the network or by the consumer.  

We need WG feedback on this in order to = progress the draft.  I'm okay with Robert's suggested first 2 = paragraphs, but I don't think the 3rd is directly related to security = considerations. 

Regards,
Mary. 

On = Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <rjsparks@nostrum.com> wrote:
While = performing the shepherd writeup, I notice the following things:

1) The document has no security considerations = section. The document is 
so = straightforward, I can understand (but shake my head at) the group 
missing that = so far. The document really needs to say something here. 
While I = don't expect it to be long, "introduces no new considerations" 
is clearly = not right.

2) In section 9.2, say "Personal = Assertion Token (PASSporT) Extensions 
registry" = instead of "PASSporT Types registry" (to match what's at 
https://www.iana.org/assignments/passport/passpor= t.xhtml ..

3) Can (should?) we provide a stable link in = the reference for ATIS-1000074?

RjS




_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m=
ailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_CD66A679-3D76-4B54-8479-BBC2284F7C3E-- From nobody Fri Oct 12 12:35:24 2018 Return-Path: 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 0EA83130E89 for ; Fri, 12 Oct 2018 12:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 oa5s7luwJ7oJ for ; Fri, 12 Oct 2018 12:35:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AC8130E84 for ; Fri, 12 Oct 2018 12:35:19 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9CJZGNx050032 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Oct 2018 14:35:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Chris Wendt Cc: stir@ietf.org References: <096223ec-b43c-73c9-d851-b51930fcc422@nostrum.com> <2B0D1A98-3F27-4CF0-AA87-D800070AC222@chriswendt.net> From: Robert Sparks Message-ID: <3deae8a7-0c47-427b-ae71-e018c91e99de@nostrum.com> Date: Fri, 12 Oct 2018 14:35:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2B0D1A98-3F27-4CF0-AA87-D800070AC222@chriswendt.net> Content-Type: multipart/alternative; boundary="------------31C5E7E5A356AFCAD7823376" Content-Language: en-US Archived-At: Subject: Re: [stir] Shepherd comments: draft-ietf-stir-passport-shaken-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:35:23 -0000 This is a multi-part message in MIME format. --------------31C5E7E5A356AFCAD7823376 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Actually, I think the thing where I may be off-base is discussed in section 8.1, where it says "Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt"." Having found that again, I'm ok dropping the 3rd paragraph. RjS On 10/12/18 2:00 PM, Chris Wendt wrote: > This is described in Section 8.3 of RFC8225. > > The thing i don’t agree with is the idea that you should pay attention > to the base PASSporT claims and ignore the extension claims.  The base > PASSporT claims are for supporting the security of the PASSporT object > and claims to be associated with a particular call (replay attack, > etc) and the extension is the real meaning of what information you are > trying to portray in an extended PASSporT.  If you only intend the > receiver to validate the calling identity, you should only send a base > PASSporT, a PASSporT with only base claims.  It’s all or nothing, you > either know how to interpret the PASSporT extension or not was the > original intent. > >> On Oct 12, 2018, at 12:21 PM, Robert Sparks > > wrote: >> >> >> >> On 10/12/18 10:21 AM, Chris Wendt wrote: >>> I guess put another way, the addition of the new claims doesn’t >>> alter the security properties of the verification of the claims and >>> mechanisms defined in 8224/8225, which i think is what Robert’s >>> second paragraph is saying. >>> >>> The new claims provide additional contextual information to the >>> verifier, and we indeed want to make sure the claims are not altered >>> in transit or replayed, etc, etc. but none of those security >>> properties are changed based on the definition of the passport >>> extension, so i would also agree the third paragraph is not >>> necessary.  We are only stating what the extension mechanism is >>> defined to do, if you don’t know how to handle the new claims in a >>> passport extension, then you shouldn’t be looking at that identity >>> header in the first place.  This is common to all extensions. >> I'm not sure the last two sentences are correct. Can you point at >> text in 8224 or 8225 that supports "shouldn't be looking at that >> identity header in the first place"? If so, I think _this_ security >> considerations section should point to that. But I'm not finding any >> such text on a quick skim. >> >> So unless I'm mis-remembering something, I believe I see things that >> say the opposite. Look at section 8.3 in RFC8225 and the end of >> section 9 of RFC8224. Specifically "Understanding an extension or new >> claims defined by the extension on the destination verification of >> the PASSporT is optional." >> >> Thus I think this sentence in the third paragraph is factually >> correct: "Should a PASSporT using this extension arrive at an >> implementation unaware of the extension, the additional claims will >> be ignored. " And the ramifications of that should be highlighted. >> What I tried to reinforce with the rest of that paragraph is that the >> additional claims are not allowed to change (specifically, weaken) >> the semantic of the base claims. Reminding future signers of that >> seems prudent. >> >>> >>> >>>> On Oct 12, 2018, at 11:07 AM, Mary Barnes >>>> > wrote: >>>> >>>> Hi STIR WG, >>>> >>>> We've had some off list discussion between the authors and Robert. >>>> >>>> Chris and I had proposed text something like the following for the >>>> security section: >>>>>> >>>>>> This document defines a new PASSporT [RFC 8225] extension.In >>>>>> general the considerations related to the security of the >>>>>> PASSporT are the same as those described in RFC 8225. Along >>>>>> with the “dest”, “orig” and “iat” claims, this document >>>>>> includes defines two new claims in the SHAKEN PASSport: >>>>>> ‘attest’ and ‘origid’.These are informational elements that >>>>>> are not dependent on or impact the original security >>>>>> properties of the core PASSporT claims therefore no new >>>>>> security considerations are introduced. >>>>>> >>>> Robert has proposed text something like the following: >>>> >>>> This document defines a new PASSporT [RFC 8225] extension. The >>>> >>>> considerations related to the security of the PASSporT >>>> object itself >>>> >>>> are the same as those described in RFC 8225. >>>> >>>> >>>> RFC 8224 defines how to compare the values of the "dest", >>>> "orig" and >>>> >>>> "iat" claims against fields in a SIP containing a PASSporT >>>> as part of >>>> >>>> validating that request. The values of the new "attest" and >>>> "origid" >>>> >>>> claims added by this extension are not used in such a >>>> validation >>>> >>>> step. They are not compared to fields in the SIP message. >>>> Instead, >>>> >>>> they simply carry additional information from the signer to the >>>> >>>> consumer of the PASSport. This new information shares the same >>>> >>>> integrity protection and non-repudiation properties as the base >>>> >>>> claims in the PASSporT. >>>> >>>> >>>> Note, however, that this additional information affects the >>>> semantics >>>> >>>> of the PASSporT itself. In particular the "attest" claim >>>> provides >>>> >>>> additional information about the quality of the assertion >>>> the signer >>>> >>>> makes about the requester's authorization to use a >>>> particular calling >>>> >>>> identity. The consumer of the PASSporT object can factor >>>> that quality >>>> >>>> into its processing decisions as long as it understands the >>>> >>>> extensions defined in this document. Should a PASSporT >>>> using this >>>> >>>> extension arrive at an implementation unaware of the >>>> extension, the >>>> >>>> additional claims will be ignored. Thus it is important >>>> that signers >>>> >>>> only provide PASSporTs using this extension when semantics >>>> of the >>>> >>>> assertions made by the base PASSporT hold true. >>>> >>>> >>>> >>>> My view is that the "attest" and "origid" are purely informational >>>> claims from a protocol perspective and don't have security >>>> implications - i.e., they're independent of any other fields in the >>>> SIP message.   The "attest" claim can be used by an application at >>>> the calling party device to display something reflecting an >>>> originating service provider's knowledge about (and thus level of >>>> trust in) the identity of  the calling party  - e.g., a calling >>>> party when a call comes through a gateway ("attest" = c) is likely >>>> to be less trusted than one coming from a calling party known to >>>> the originating service provider (e.g., one of their customers with >>>> an "attest"=A ), so what gets displayed might be different - e.g., >>>> green check mark versus warning. And, the "origid" claim could be >>>> used for traceback.   We don't have any text about potential uses >>>> for the information in this STIR document, but it is described in >>>> ATIS-1000074 (and we will be adding a link to that document in the >>>> references).  But, we say absolutely nothing about the semantics >>>> with regards to the consumer of the PASSporT.   The claims don't >>>> define anything prescriptive about how a call is handled in the >>>> network or by the consumer. >>>> >>>> We need WG feedback on this in order to progress the draft.  I'm >>>> okay with Robert's suggested first 2 paragraphs, but I don't think >>>> the 3rd is directly related to security considerations. >>>> >>>> Regards, >>>> Mary. >>>> >>>> On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks >>> > wrote: >>>> >>>> While performing the shepherd writeup, I notice the following >>>> things: >>>> >>>> 1) The document has no security considerations section. The >>>> document is >>>> so straightforward, I can understand (but shake my head at) the >>>> group >>>> missing that so far. The document really needs to say something >>>> here. >>>> While I don't expect it to be long, "introduces no new >>>> considerations" >>>> is clearly not right. >>>> >>>> 2) In section 9.2, say "Personal Assertion Token (PASSporT) >>>> Extensions >>>> registry" instead of "PASSporT Types registry" (to match what's at >>>> https://www.iana.org/assignments/passport/passport.xhtml.. >>>> >>>> 3) Can (should?) we provide a stable link in the reference for >>>> ATIS-1000074? >>>> >>>> RjS >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 > --------------31C5E7E5A356AFCAD7823376 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Actually, I think the thing where I may be off-base is discussed in section 8.1, where it says

"Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt"."

Having found that again, I'm ok dropping the 3rd paragraph.

RjS


On 10/12/18 2:00 PM, Chris Wendt wrote:
This is described in Section 8.3 of RFC8225.

The thing i don’t agree with is the idea that you should pay attention to the base PASSporT claims and ignore the extension claims.  The base PASSporT claims are for supporting the security of the PASSporT object and claims to be associated with a particular call (replay attack, etc) and the extension is the real meaning of what information you are trying to portray in an extended PASSporT.  If you only intend the receiver to validate the calling identity, you should only send a base PASSporT, a PASSporT with only base claims.  It’s all or nothing, you either know how to interpret the PASSporT extension or not was the original intent.

On Oct 12, 2018, at 12:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:



On 10/12/18 10:21 AM, Chris Wendt wrote:
I guess put another way, the addition of the new claims doesn’t alter the security properties of the verification of the claims and mechanisms defined in 8224/8225, which i think is what Robert’s second paragraph is saying.  

The new claims provide additional contextual information to the verifier, and we indeed want to make sure the claims are not altered in transit or replayed, etc, etc. but none of those security properties are changed based on the definition of the passport extension, so i would also agree the third paragraph is not necessary.  We are only stating what the extension mechanism is defined to do, if you don’t know how to handle the new claims in a passport extension, then you shouldn’t be looking at that identity header in the first place.  This is common to all extensions.
I'm not sure the last two sentences are correct. Can you point at text in 8224 or 8225 that supports "shouldn't be looking at that identity header in the first place"? If so, I think _this_ security considerations section should point to that. But I'm not finding any such text on a quick skim.

So unless I'm mis-remembering something, I believe I see things that say the opposite. Look at section 8.3 in RFC8225 and the end of section 9 of RFC8224. Specifically "Understanding an extension or new claims defined by the extension on the destination verification of the PASSporT is optional."

Thus I think this sentence in the third paragraph is factually correct: "Should a PASSporT using this extension arrive at an implementation unaware of the extension, the additional claims will be ignored. " And the ramifications of that should be highlighted. What I tried to reinforce with the rest of that paragraph is that the additional claims are not allowed to change (specifically, weaken) the semantic of the base claims. Reminding future signers of that seems prudent.



On Oct 12, 2018, at 11:07 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi STIR WG,

We've had some off list discussion between the authors and Robert.  

Chris and I had proposed text something like the following for the security section:
This document defines a new PASSporT [RFC 8225] extension.  In general the considerations related to the security of the PASSporT are the same as those described in RFC 8225.   Along with the “dest”, “orig” and “iat” claims, this document includes defines two new claims in the SHAKEN PASSport: ‘attest’ and ‘origid’.  These are informational elements that are not dependent on or impact the original security properties of the core PASSporT claims therefore no new security considerations are introduced.
Robert has proposed text something like the following:

This document defines a new PASSporT [RFC 8225] extension.  The
considerations related to the security of the PASSporT object itself
are the same as those described in RFC 8225.

RFC 8224 defines how to compare the values of the "dest", "orig" and
"iat" claims against fields in a SIP containing a PASSporT as part of
validating that request. The values of the new "attest" and "origid"
claims added by this extension are not used in such a validation
step. They are not compared to fields in the SIP message. Instead,
they simply carry additional information from the signer to the
consumer of the PASSport. This new information shares the same
integrity protection and non-repudiation properties as the base
claims in the PASSporT.

Note, however, that this additional information affects the semantics
of the PASSporT itself. In particular the "attest" claim provides
additional information about the quality of the assertion the signer
makes about the requester's authorization to use a particular calling
identity. The consumer of the PASSporT object can factor that quality
into its processing decisions as long as it understands the
extensions defined in this document. Should a PASSporT using this
extension arrive at an implementation unaware of the extension, the
additional claims will be ignored. Thus it is important that signers
only provide PASSporTs using this extension when semantics of the
assertions made by the base PASSporT hold true.


My view is that the "attest" and "origid" are purely informational claims from a protocol perspective and don't have security implications - i.e., they're independent of any other fields in the SIP message.   The "attest" claim can be used by an application at the calling party device to display something reflecting an originating service provider's knowledge about (and thus level of trust in) the identity of  the calling party  - e.g., a calling party when a call comes through a gateway ("attest" = c) is likely to be less trusted than one coming from a calling party known to the originating service provider (e.g., one of their customers with an "attest"=A ), so what gets displayed might be different - e.g., green check mark versus warning.  And, the "origid" claim could be used for traceback.   We don't have any text about potential uses for the information in this STIR document, but it is described in ATIS-1000074 (and we will be adding a link to that document in the references).   But, we say absolutely nothing about the semantics with regards to the consumer of the PASSporT.   The claims don't define anything prescriptive about how a call is handled in the network or by the consumer.  

We need WG feedback on this in order to progress the draft.  I'm okay with Robert's suggested first 2 paragraphs, but I don't think the 3rd is directly related to security considerations. 

Regards,
Mary. 

On Mon, Sep 24, 2018 at 1:51 PM Robert Sparks <rjsparks@nostrum.com> wrote:
While performing the shepherd writeup, I notice the following things:

1) The document has no security considerations section. The document is 
so straightforward, I can understand (but shake my head at) the group 
missing that so far. The document really needs to say something here. 
While I don't expect it to be long, "introduces no new considerations" 
is clearly not right.

2) In section 9.2, say "Personal Assertion Token (PASSporT) Extensions 
registry" instead of "PASSporT Types registry" (to match what's at 
https://www.iana.org/assignments/passport/passport.xhtml ..

3) Can (should?) we provide a stable link in the reference for ATIS-1000074?

RjS




_______________________________________________
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


--------------31C5E7E5A356AFCAD7823376-- From nobody Mon Oct 15 12:28:32 2018 Return-Path: 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 4B84B130EE8 for ; Mon, 15 Oct 2018 12:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 mIDZr0Ee4_jh for ; Mon, 15 Oct 2018 12:28:24 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 5635A130EFF for ; Mon, 15 Oct 2018 12:28:24 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id BBE791E0871 for ; Mon, 15 Oct 2018 13:28:23 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmsmtp with ESMTP id C8X7gYAhqQOgxC8XGgDli1; Mon, 15 Oct 2018 13:28:21 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4o8t+zhjH7bD+yyVF9Yc0H++TW6eDA29ySYpVdIYJeI=; b=XkwBt0s5xXwZjcU2iJsUpuGWVx FXKJlX8VPXjzx9BN4HpSC/gAfIW7Nz9oAnM6J8Tj7Di4HygS6PjZ4jZRB/IqQ+R2OzQxIvY6pIAW6 0qaaLQ3Ra6ddUQ6ic/rWsMI/8; Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:55069 helo=[192.168.1.156]) by box462.bluehost.com with esmtpa (Exim 4.91) (envelope-from ) id 1gC8X6-002l3X-0c; Mon, 15 Oct 2018 13:28:04 -0600 User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Mon, 15 Oct 2018 15:28:01 -0400 From: Richard Shockey To: Brian Rosen , James Winterbottom CC: , "stir@ietf.org" Message-ID: <8DEDCA11-4DA1-48A4-810F-63BF5EE68B70@shockey.us> Thread-Topic: [sipcore] sipcore-rejected open issue: vCard *VS XCARD* References: <8BB74098-F137-4091-8541-C0DB196DAACE@standardstrack.com> <4C813BDF-CFB4-463C-B993-D9610A94F28E@standardstrack.com> <781559A0-DA8F-47C7-993D-B27801374D4B@gmail.com> <2F263A16-8CF7-41F0-8669-DC7C4928963F@standardstrack.com> <51D80BB8-431F-4EE4-ADE3-AD55D962F6E3@gmail.com> <9BEFF26C-8BBF-440E-8342-B921B3D4BC06@brianrosen.net> In-Reply-To: <9BEFF26C-8BBF-440E-8342-B921B3D4BC06@brianrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.47.17 X-Source-L: No X-Exim-ID: 1gC8X6-002l3X-0c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:55069 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [stir] [sipcore] sipcore-rejected open issue: vCard *VS XCARD* X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 19:28:31 -0000 To echo what Eric mentioned some of us have looked at V/X/J card representa= tion of calling name presentation data aka Advanced CNAM as one of many tech= niques that could be used as part of a suite of tools to combat robocalls an= d caller ID spoofing. Not specifically STIR related but potentially useful = especially if it could be signed as another PASSPORT. I've got lots of pret= ty pictures on how this could show up on the UA. There is interest in this.= =20 There is some resistance to this for obvious reasons. The size of the INVI= TE is already out of control and there is a reluctance on the part of some c= arriers to dip a URI at the terminating end. =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 10/15/18, 2:59 PM, "sipcore on behalf of Brian Rosen" wrote: We=E2=80=99re heavily using xCards in NG9-1-1, and converting to jCards as so= on as we can for anything NENA controls. We=E2=80=99ve not had interoperability i= ssues requiring profiles. We just ignore fields we don=E2=80=99t need and no one = has tried sending an xCard without name, address and phone number. OTOH, al= l we ever use them for are humans contacting other humans. =20 =20 We sign objects we need protection for, but never had to sign just an x= Card. No one wants to deal with vCards if they don=E2=80=99t have to. =20 I=E2=80=99d have no objection to a signed jCard.=20 =20 Brian =20 > On Oct 15, 2018, at 2:59 AM, James Winterbottom wrote: >=20 > Ah okay. >=20 > Heavy profile of xCard may work then. I profiled it very heavily in T= S 103 478 but still had interoperability issues. > xCard is used a lot in the Additional Data side of the NG9-1-1 specs,= but my experience there has not been good with it. Not sure how well used o= utside that area it is. >=20 >=20 > Cheers > James >=20 >> On 15 Oct 2018, at 12:54 pm, Eric Burger wrote: >>=20 >> Not really a civic address but a point of contact, like an email add= ress, telephone (SIP) number, or Web site. I=E2=80=99m sure if someone wanted to b= e obstructive, a postal mail address would do. >>=20 >>> On Oct 14, 2018, at 8:38 PM, James Winterbottom wrote: >>>=20 >>> If you are only after address data why not look at geopriv civic re= presentation? From experience profiling XCard will be almost as bad doing it= for vCard >>>=20 >>> Sent from my iPhone >>>=20 >>>> On 15 Oct 2018, at 11:10 am, Eric Burger wrote: >>>>=20 >>>> Any thoughts on vCard vs xCard as a marshaling format for address = card information? >>>>=20 >>>> The benefit of vCard is it has been around for ages and there are = lots of implementations and it is ubiquitous in the enterprise computing wor= ld. The drawback of vCard is writing a canonicalization standard will litera= lly be over a hundred pages. >>>>=20 >>>> The benefit of xCard is we can use XML Signatures which has standa= rds already available for canonicalizing XML documents, like xCards. >>>>=20 >>>> My question: WHAT IS THE UBIQUITY OF xCard? >>>>=20 >>>> I have recently seen some SIP-related work (VRS/ITRS) that favors = xCard over vCard. Is this a new trend or an outlier? >>>>=20 >>>> Thanks, >>>> Eric >>>>=20 >>>>> On Sep 6, 2018, at 5:12 PM, Eric Burger wrote: >>>>>=20 >>>>> I realized that vCards have no integrity protection whatsoever, m= aking them a questionable vehicle for something that has a potential for abu= se. >>>>>=20 >>>>> I checked with the RAI ADs and calext chairs, and one option is t= o build secure vCards. There is some independent work already begun in that = space that we can piggy-back on. >>>>>=20 >>>>> Another alternative is to add new headers to SIP to convey whom t= o contact to remediate blocked calls. >>>>>=20 >>>>> My inclination is to fix vCards, as that would be generally usefu= l and there is already some modest demand for it. It would broaden the imple= mentation base which should be a good thing for us. >>>>>=20 >>>>> Does anyone on the list *NOT* want to go the vCard route and inst= ead create new SIP headers? Does anyone have a better idea? Note if we go th= e SIP header route, these new headers would need corresponding JWT=E2=80=99s as th= ey have to be secured with a traceable signature authority chain. >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 From nobody Wed Oct 17 15:59:07 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E9130E2A; Wed, 17 Oct 2018 15:58:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <153981713975.27568.7825870800614189169@ietfa.amsl.com> Date: Wed, 17 Oct 2018 15:58:59 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-shaken-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 22:59:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT SHAKEN Extension (SHAKEN) Authors : Chris Wendt Mary Barnes Filename : draft-ietf-stir-passport-shaken-04.txt Pages : 8 Date : 2018-10-17 Abstract: This document extends PASSporT, which is a token object that conveys cryptographically-signed information about the participants involved in communications, to include information defined as part of the SHAKEN specification from ATIS (Alliance for Telecommunications Industry Solutions) and the SIP Forum IP-NNI Joint Task Force. These extensions provide a level of confidence in the correctness of the originating identity for a telephone network that has communications coming from both STIR participating originating communications as well as communications that does not include STIR information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-04 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-shaken-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-shaken-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 17 16:24:38 2018 Return-Path: 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 BAAB0130E2F for ; Wed, 17 Oct 2018 16:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZNxEqR6GtLu7 for ; Wed, 17 Oct 2018 16:24:35 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909AD130E03 for ; Wed, 17 Oct 2018 16:24:35 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id m18-v6so21147248lfl.11 for ; Wed, 17 Oct 2018 16:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DN2rJlvlTWQYH4j0ulizSZHXGllUCmL0CdkVHiosLfs=; b=PCZ6xOHMtr5KOYvsYS1+O2PUK2kvPnUhS/9AezVZJ8JEG8LWj3fuOlGdXUhJ3cq1fY GQ7IrjHiCqgMQmdQrZsHPhuAq3KqMcSOajUlbgV/ch9j/pgsCYNi2Zt8OgjFi23wBeSK E84E0sYkOovRKdYtyWnWKM00TdhuK4ekZGXsDGYeC6+gxBtVzzCAd9AJkDKG3q60C1jj FHNMIivwFTSG2R5FhiLA6T4+ZEtQq2Xndt+JLSyd7B0zgn0s+xrhhGWxHH+bFKjOYnuG hJ7fN05qTUYwyPIds3v/63eFGx0SB8o6z4z0rG/2ldg7fgjZC9LEdDea+n8plGLpl/5y BFpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DN2rJlvlTWQYH4j0ulizSZHXGllUCmL0CdkVHiosLfs=; b=bx9rIOoVsbMK56T3o7fJ0HnY5bOHU4pgWdoDbfAEEO6XshUzqbfg2xORFSLIYasdp2 9O5dYl7STd17oQTRX4Wxh9di+FpNA5hehA9paszbborRn1MCLiYvyqweV7l/aq+1kRXK 012OZWoH1g6sZzZ+TnP23mtqlQrONaQZXMALrBjl+K2NCVYMHhCpWYlMZ8viT3a3utKO Ga//YdzMZq6m3z+0kALupUYPNoPeirntL7tGIkVnGQMOqF2v7i5G/zNiKzZeMMpl4ugJ BjHGc4tlY1/JxDMg7spzy7ovK47fsKR5o0+AjqSFh7Gn0q38WGTocRh4f/PdVylXYr0e ix6Q== X-Gm-Message-State: ABuFfohDzfuGofHcXvJGiN2714uiSXKHsmBG8EtqJ901/4sSnHI5Bx9f 8/Cm6fa81cT8DCFFpIi1TdzQVqi1H1T386zE6dTqKExs X-Google-Smtp-Source: ACcGV620d8UfUkZoGOQPM7vqBZPOgvLQYi/bMMyQkcQhPowxFwA6zm0nu0GGyNTkY01YO4EBrxro2par4gaUSkbbdd4= X-Received: by 2002:a19:a085:: with SMTP id j127-v6mr16306551lfe.106.1539818673392; Wed, 17 Oct 2018 16:24:33 -0700 (PDT) MIME-Version: 1.0 References: <153981713975.27568.7825870800614189169@ietfa.amsl.com> In-Reply-To: <153981713975.27568.7825870800614189169@ietfa.amsl.com> From: Mary Barnes Date: Wed, 17 Oct 2018 18:24:27 -0500 Message-ID: To: "stir@ietf.org Mail List" Content-Type: multipart/alternative; boundary="0000000000000bd07c057874f9ba" Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-shaken-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 23:24:38 -0000 --0000000000000bd07c057874f9ba Content-Type: text/plain; charset="UTF-8" This version addresses Robert's shepherd review comments: https://www.ietf.org/mail-archive/web/stir/current/msg03550.html Regards, Mary On Wed, Oct 17, 2018 at 5:59 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Telephone Identity Revisited WG of > the IETF. > > Title : PASSporT SHAKEN Extension (SHAKEN) > Authors : Chris Wendt > Mary Barnes > Filename : draft-ietf-stir-passport-shaken-04.txt > Pages : 8 > Date : 2018-10-17 > > Abstract: > This document extends PASSporT, which is a token object that conveys > cryptographically-signed information about the participants involved > in communications, to include information defined as part of the > SHAKEN specification from ATIS (Alliance for Telecommunications > Industry Solutions) and the SIP Forum IP-NNI Joint Task Force. These > extensions provide a level of confidence in the correctness of the > originating identity for a telephone network that has communications > coming from both STIR participating originating communications as > well as communications that does not include STIR information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-04 > https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-shaken-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-shaken-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --0000000000000bd07c057874f9ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This version addresses Robert's sheph= erd review comments:

Regards,
Mary

On Wed, Oct 17, 2= 018 at 5:59 PM <internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Secure Telephone Identity Revisited WG of = the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= PASSporT SHAKEN Extension (SHAKEN)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Chri= s Wendt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mary Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-stir-passport-shaken-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-17

Abstract:
=C2=A0 =C2=A0This document extends PASSporT, which is a token object that c= onveys
=C2=A0 =C2=A0cryptographically-signed information about the participants in= volved
=C2=A0 =C2=A0in communications, to include information defined as part of t= he
=C2=A0 =C2=A0SHAKEN specification from ATIS (Alliance for Telecommunication= s
=C2=A0 =C2=A0Industry Solutions) and the SIP Forum IP-NNI Joint Task Force.= =C2=A0 These
=C2=A0 =C2=A0extensions provide a level of confidence in the correctness of= the
=C2=A0 =C2=A0originating identity for a telephone network that has communic= ations
=C2=A0 =C2=A0coming from both STIR participating originating communications= as
=C2=A0 =C2=A0well as communications that does not include STIR information.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-stir-passport-shaken/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -stir-passport-shaken-04
https://datatracker.ietf.org= /doc/html/draft-ietf-stir-passport-shaken-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-stir-passport-shaken-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--0000000000000bd07c057874f9ba-- From nobody Thu Oct 18 11:58:46 2018 Return-Path: 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 7235912F1AC for ; Thu, 18 Oct 2018 11:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.com 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 fy0S6G3Ql0B6 for ; Thu, 18 Oct 2018 11:58:40 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFB61286D9 for ; Thu, 18 Oct 2018 11:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1539889118; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xmJkqn7bABCUdLxh41l/LQOQ9ChzLCbIGo3SPtvN9T4=; b=amgQL4Eoou3YwVe/84eX4INZwzIErVvyzJ50BVVnmm3vuc1jwaaUI+GcKvUn8rY8BxuEOjoY+lWIQDTe/xIm/c1TRPgW457/lRzrGgu2BSuzMzENm2WKdxyBa/Eq85+7Klv2Nt5+ShvwwedghQoE23X3vIkJLet5gxctR3iLPaI= Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp0084.outbound.protection.outlook.com [216.32.181.84]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-94-f7Qxtn5aP4ODXHCRt3afgg-1; Thu, 18 Oct 2018 14:58:34 -0400 Received: from BN6PR03MB2802.namprd03.prod.outlook.com (10.175.125.8) by BN6PR03MB3395.namprd03.prod.outlook.com (10.174.94.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Thu, 18 Oct 2018 18:58:32 +0000 Received: from BN6PR03MB2802.namprd03.prod.outlook.com ([fe80::c8b7:7134:81ce:f214]) by BN6PR03MB2802.namprd03.prod.outlook.com ([fe80::c8b7:7134:81ce:f214%4]) with mapi id 15.20.1250.022; Thu, 18 Oct 2018 18:58:32 +0000 From: "Asveren, Tolga" To: Mary Barnes , "stir@ietf.org Mail List" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-shaken-04.txt Thread-Index: AQHUZm0lcYmIzD+c+UCLs45VtR8YpaUkFD2AgAFHDsA= Date: Thu, 18 Oct 2018 18:58:32 +0000 Message-ID: References: <153981713975.27568.7825870800614189169@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB3395; 20:y6uXlIFfpwKlLpsa7c/8ll1Gq8RBGXTKg+rrahnVmOI+6b1gpWkhW7GwCX/jlhngFB4BA4JmXyeokNN/rrC4TwvOnwf9yfRz2XaSQ2hzB1HVVxWN7PSVcM3AThyndvlqXlf3cC3jLG1D/bPKdOhk9fJ+MmWNHYxjRGsvRq7ten4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8bf1e719-a6a4-41b2-e310-08d6352bb32a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR03MB3395; x-ms-traffictypediagnostic: BN6PR03MB3395: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(120809045254105)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(159968658992688); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(4982022)(52105095)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN6PR03MB3395; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB3395; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(376002)(136003)(189003)(199004)(14971765001)(5250100002)(8676002)(2906002)(5660300001)(7736002)(4001150100001)(55016002)(19609705001)(25786009)(39060400002)(68736007)(97736004)(54896002)(14444005)(86362001)(6436002)(790700001)(6116002)(3846002)(74316002)(71190400001)(71200400001)(229853002)(81166006)(81156014)(8936002)(106356001)(6246003)(99286004)(446003)(11346002)(606006)(256004)(76176011)(105586002)(2900100001)(53936002)(110136005)(6506007)(236005)(53546011)(9686003)(26005)(6306002)(186003)(966005)(14454004)(478600001)(486006)(7696005)(66066001)(33656002)(476003)(102836004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB3395; H:BN6PR03MB2802.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-microsoft-antispam-message-info: pWFeCgcgPoHsB565w4/83h7sOMSrjtiYhDzfRyb9c1YB0JvTIiDXxSxv/sIqmJ/EHNu8WchDp3aLVgh2tNLivqIDeMMc1v9CsoMZqU6E0YAS5JsdY6XqIPmQGOAHrB47IMzdze29Hs3K73Rfl5ap016//0qGiVUN/YRyfQxk/Gqxup3Rb8o+BBXft+hNdAUv3AEf6DeuoFCd0YBeruXABiq8WMPaGdYTKvl65T5Bwajyyfh6ZlYeDbEfCnwr3zqrbkfwbZRds20veuvnrXxrf9LyVL+hXmxWFJK+mXciH+z/ePEehoDjonKHZ71+JMfmfoRiPlJ24zho/UmUrrI3nPg+qMI2eLdseK4fN2jTK/8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bf1e719-a6a4-41b2-e310-08d6352bb32a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 18:58:32.3460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB3395 X-MC-Unique: f7Qxtn5aP4ODXHCRt3afgg-1 Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2802B52AD041511C0BBF06A2A5F80BN6PR03MB2802namp_" Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-shaken-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:58:45 -0000 --_000_BN6PR03MB2802B52AD041511C0BBF06A2A5F80BN6PR03MB2802namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U2VjdXJpdHkgc2VjdGlvbiBsb29rcyBnb29kIHRvIG1lLiBJdCByZWFsbHkgaXMganVzdCBob3cg dGhpbmdzIHNob3VsZCBiZSBJTUhPIGlmIGEga2V5IGluIGEgY2xhaW0gaXMgbm90IHVzZWQgb3V0 c2lkZSBvZiB0aGUgY29udGV4dCBvZiBTVElSLiBWZXJpZmljYXRpb24gYWdhaW5zdCBhIFNJUCBo ZWFkZXIgaXMgbmVlZGVkIG9ubHkgaWYgdGhlIGNvbnRlbnQgb2YgdGhhdCBoZWFkZXIgaXMgdXNl ZCBmb3Igc29tZSBvdGhlciBwdXJwb3NlLCBlLmcuIGRpc3BsYXlpbmcgY2FsbGVyIGluZm9ybWF0 aW9uLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBzdGlyIDxzdGlyLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBNYXJ5IEJhcm5lcw0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE3 LCAyMDE4IDc6MjQgUE0NClRvOiBzdGlyQGlldGYub3JnIE1haWwgTGlzdCA8c3RpckBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zdGlyLXBhc3Nw b3J0LXNoYWtlbi0wNC50eHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5P VElDRTogVGhpcyBlbWFpbCB3YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXINCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMg Um9iZXJ0J3Mgc2hlcGhlcmQgcmV2aWV3IGNvbW1lbnRzOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zdGlyL2N1cnJlbnQvbXNnMDM1NTAuaHRtbDxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N0aXIvY3VycmVudC9tc2cwMzU1MC5odG1sPg0KDQpS ZWdhcmRzLA0KTWFyeQ0KDQpPbiBXZWQsIE9jdCAxNywgMjAxOCBhdCA1OjU5IFBNIDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3Rl Og0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBTZWN1cmUgVGVsZXBob25lIElkZW50aXR5IFJldmlzaXRlZCBXRyBvZiB0aGUgSUVURi4N Cg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQQVNTcG9yVCBTSEFLRU4gRXh0ZW5zaW9uIChT SEFLRU4pDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENocmlzIFdlbmR0DQogICAgICAgICAg ICAgICAgICAgICAgICAgIE1hcnkgQmFybmVzDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1zaGFrZW4tMDQudHh0DQogICAgICAgIFBhZ2VzICAgICAg ICAgICA6IDgNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxOC0xMC0xNw0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgZXh0ZW5kcyBQQVNTcG9yVCwgd2hpY2ggaXMgYSB0b2tlbiBv YmplY3QgdGhhdCBjb252ZXlzDQogICBjcnlwdG9ncmFwaGljYWxseS1zaWduZWQgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHBhcnRpY2lwYW50cyBpbnZvbHZlZA0KICAgaW4gY29tbXVuaWNhdGlvbnMs IHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZQ0KICAgU0hBS0VO IHNwZWNpZmljYXRpb24gZnJvbSBBVElTIChBbGxpYW5jZSBmb3IgVGVsZWNvbW11bmljYXRpb25z DQogICBJbmR1c3RyeSBTb2x1dGlvbnMpIGFuZCB0aGUgU0lQIEZvcnVtIElQLU5OSSBKb2ludCBU YXNrIEZvcmNlLiAgVGhlc2UNCiAgIGV4dGVuc2lvbnMgcHJvdmlkZSBhIGxldmVsIG9mIGNvbmZp ZGVuY2UgaW4gdGhlIGNvcnJlY3RuZXNzIG9mIHRoZQ0KICAgb3JpZ2luYXRpbmcgaWRlbnRpdHkg Zm9yIGEgdGVsZXBob25lIG5ldHdvcmsgdGhhdCBoYXMgY29tbXVuaWNhdGlvbnMNCiAgIGNvbWlu ZyBmcm9tIGJvdGggU1RJUiBwYXJ0aWNpcGF0aW5nIG9yaWdpbmF0aW5nIGNvbW11bmljYXRpb25z IGFzDQogICB3ZWxsIGFzIGNvbW11bmljYXRpb25zIHRoYXQgZG9lcyBub3QgaW5jbHVkZSBTVElS IGluZm9ybWF0aW9uLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zdGlyLXBhc3Nwb3J0LXNoYWtlbi88aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXNoYWtlbi8+DQoNClRoZXJlIGFyZSBhbHNvIGh0bWxp emVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtc2hha2VuLTA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtc2hha2VuLTA0Pg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtc2hha2VuLTA0 PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zdGlyLXBh c3Nwb3J0LXNoYWtlbi0wND4NCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc3Rpci1wYXNzcG9ydC1zaGFrZW4tMDQ8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1zaGFrZW4tMDQ+DQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86 SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2U8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p LWQtYW5ub3VuY2U+DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbDxodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPg0Kb3IgZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8ZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQ+DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk5vdGljZTogVGhpcyBlLW1haWwg dG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gb2Yg UmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdA0KaXMgY29uZmlkZW50aWFsIGFuZC9vciBw cm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuICBB bnkgcmV2aWV3LCBkaXNjbG9zdXJlLCByZWxpYW5jZSBvcg0KZGlzdHJpYnV0aW9uIGJ5IG90aGVy cyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwgY29waWVz LCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_BN6PR03MB2802B52AD041511C0BBF06A2A5F80BN6PR03MB2802namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+PHN0 eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5z aGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48 c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN1cml0eSBzZWN0aW9uIGxvb2tzIGdvb2QgdG8gbWUu IEl0IHJlYWxseSBpcyBqdXN0IGhvdyB0aGluZ3Mgc2hvdWxkIGJlIElNSE8gaWYgYSBrZXkgaW4g YSBjbGFpbSBpcyBub3QgdXNlZCBvdXRzaWRlIG9mIHRoZSBjb250ZXh0IG9mIFNUSVIuIFZlcmlm aWNhdGlvbiBhZ2FpbnN0IGEgU0lQIGhlYWRlciBpcyBuZWVkZWQgb25seSBpZiB0aGUgY29udGVu dCBvZiB0aGF0IGhlYWRlciBpcyB1c2VkIGZvciBzb21lDQogb3RoZXIgcHVycG9zZSwgZS5nLiBk aXNwbGF5aW5nIGNhbGxlciBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9sZ2E8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gc3RpciAmbHQ7c3Rpci1ib3VuY2VzQGlldGYu b3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWFyeSBCYXJuZXM8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAyMDE4IDc6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IHN0 aXJAaWV0Zi5vcmcgTWFpbCBMaXN0ICZsdDtzdGlyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3N0aXJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1z aGFrZW4tMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lk dGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O T1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2VuZGVyPG86 cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB2ZXJzaW9uIGFkZHJl c3NlcyBSb2JlcnQncyBzaGVwaGVyZCByZXZpZXcgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zdGlyL2N1cnJlbnQvbXNnMDM1NTAuaHRtbCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zdGlyL2N1cnJlbnQvbXNnMDM1NTAuaHRtbDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1hcnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBPY3QgMTcsIDIwMTggYXQgNTo1OSBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgU2VjdXJlIFRlbGVwaG9uZSBJZGVudGl0eSBSZXZpc2l0ZWQgV0cg b2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxl Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFBBU1Nwb3JUIFNIQUtF TiBFeHRlbnNpb24gKFNIQUtFTik8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0 aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IENocmlzIFdlbmR0PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1hcnkgQmFybmVzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXNoYWtlbi0wNC50eHQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzogODxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE4LTEwLTE3PGJyPg0KPGJyPg0K QWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZXh0ZW5kcyBQQVNTcG9y VCwgd2hpY2ggaXMgYSB0b2tlbiBvYmplY3QgdGhhdCBjb252ZXlzPGJyPg0KJm5ic3A7ICZuYnNw O2NyeXB0b2dyYXBoaWNhbGx5LXNpZ25lZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcGFydGljaXBh bnRzIGludm9sdmVkPGJyPg0KJm5ic3A7ICZuYnNwO2luIGNvbW11bmljYXRpb25zLCB0byBpbmNs dWRlIGluZm9ybWF0aW9uIGRlZmluZWQgYXMgcGFydCBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7 U0hBS0VOIHNwZWNpZmljYXRpb24gZnJvbSBBVElTIChBbGxpYW5jZSBmb3IgVGVsZWNvbW11bmlj YXRpb25zPGJyPg0KJm5ic3A7ICZuYnNwO0luZHVzdHJ5IFNvbHV0aW9ucykgYW5kIHRoZSBTSVAg Rm9ydW0gSVAtTk5JIEpvaW50IFRhc2sgRm9yY2UuJm5ic3A7IFRoZXNlPGJyPg0KJm5ic3A7ICZu YnNwO2V4dGVuc2lvbnMgcHJvdmlkZSBhIGxldmVsIG9mIGNvbmZpZGVuY2UgaW4gdGhlIGNvcnJl Y3RuZXNzIG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtvcmlnaW5hdGluZyBpZGVudGl0eSBmb3Ig YSB0ZWxlcGhvbmUgbmV0d29yayB0aGF0IGhhcyBjb21tdW5pY2F0aW9uczxicj4NCiZuYnNwOyAm bmJzcDtjb21pbmcgZnJvbSBib3RoIFNUSVIgcGFydGljaXBhdGluZyBvcmlnaW5hdGluZyBjb21t dW5pY2F0aW9ucyBhczxicj4NCiZuYnNwOyAmbmJzcDt3ZWxsIGFzIGNvbW11bmljYXRpb25zIHRo YXQgZG9lcyBub3QgaW5jbHVkZSBTVElSIGluZm9ybWF0aW9uLjxicj4NCjxicj4NCjxicj4NClRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3Rpci1w YXNzcG9ydC1zaGFrZW4vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXNoYWtlbi88L2E+PGJyPg0KPGJyPg0K VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQt c2hha2VuLTA0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1zaGFrZW4tMDQ8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQt c2hha2VuLTA0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtc2hha2VuLTA0PC9hPjxicj4NCjxicj4N CkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zdGly LXBhc3Nwb3J0LXNoYWtlbi0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtc2hha2VuLTA0PC9hPjxicj4N Cjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4N CkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0 PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K SS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3Vu Y2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5u b3VuY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ktZC1hbm5vdW5jZTwvYT48YnI+DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT48YnI+DQpvciA8YSBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0K ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCg0KDQo8 YnIgLz48YnIgLz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7IEZvbnQtc2l6ZTo4LjBw dCI+IDxociAvPiBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMu IHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuICBBbnkgcmV2aWV3LCBkaXNjbG9zdXJlLCByZWxp YW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dCBleHBy ZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgdGhlbiBkZWxldGUgYWxsIGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48 aHIgLz4gPC9zcGFuPjwvYm9keT48L2h0bWw+DQo= --_000_BN6PR03MB2802B52AD041511C0BBF06A2A5F80BN6PR03MB2802namp_-- From nobody Thu Oct 18 12:53:51 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6361286E3; Thu, 18 Oct 2018 12:53:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Cc: stir@ietf.org, rjsparks@nostrum.com, iesg-secretary@ietf.org, stir-chairs@ietf.org, Robert Sparks Message-ID: <153989243024.22290.3505347354198028377.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2018 12:53:50 -0700 Archived-At: Subject: [stir] Publication has been requested for draft-ietf-stir-passport-shaken-04 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 19:53:50 -0000 Robert Sparks has requested publication of draft-ietf-stir-passport-shaken-04 as Proposed Standard on behalf of the STIR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ From nobody Fri Oct 19 09:16:29 2018 Return-Path: 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 F23AB130E81 for ; Fri, 19 Oct 2018 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 n2eJ1ptnoVjx for ; Fri, 19 Oct 2018 09:16:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B57112D4EB for ; Fri, 19 Oct 2018 09:16:27 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9JGGQ7A061165 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 19 Oct 2018 11:16:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <49509feb-4d9c-301d-c964-bbe67c785a04@nostrum.com> Date: Fri, 19 Oct 2018 11:16:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] Things to do before Bangkok X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 16:16:29 -0000 Stir participants: At IETF 102, we had some volunteers to provide reviews for draft-ietf-stir-passport-divert. Could we get those reviews in before we get to Bangkok? I'm expecting a revision for that document that says to always nest in that timeframe as well, but the reviews don't need to wait for that. We can do a WGLC on that revision right after IETF 103. We also noted that OOB was ready for last call as is (see ). I'm going to initiate a WGLC on that now, and we can hopefully pubreq it shortly after IETF 103. Let me know if you disagree with any of the above. RjS From nobody Fri Oct 19 09:19:16 2018 Return-Path: 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 08530130F6C for ; Fri, 19 Oct 2018 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xwv14aKB0Sf9 for ; Fri, 19 Oct 2018 09:19:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E71D130FD1 for ; Fri, 19 Oct 2018 09:19:11 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9JGJABl061624 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 19 Oct 2018 11:19:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: Date: Fri, 19 Oct 2018 11:19:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] WGLC: draft-ietf-stir-oob-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 16:19:15 -0000 Please review and provide comments on by 2 Nov, 2018. I realize this is in the crunch period before IETF 103. If you expect to have substantive comments, but need more time, just ask. However, please make a best effort to have any major comments to the list before we meet in Bangkok. RjS From nobody Fri Oct 19 12:03:47 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06A1310F0; Fri, 19 Oct 2018 11:56:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: stir@ietf.org, adam@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540036.6592.9842626037955093000.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:40 -0700 Archived-At: Subject: [stir] stir - Requested session has been scheduled for IETF 103 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:49 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. stir Session 1 (1:00 requested) Monday, 5 November 2018, Morning Session II 1120-1220 Room Name: Meeting 1 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/stir.ics Request Information: --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: First Priority: curdle sipbrandy ipwave modern ice secdispatch sipcore mmusic rtcweb avtcore ecrit tls acme lamps suit saag Second Priority: perc slim clue ace oauth dispatch People who must be present: Russell Housley Sean Turner Adam Roach Robert Sparks Jon Peterson Chris Wendt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 19 16:54:12 2018 Return-Path: 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 3CC2C130E17; Fri, 19 Oct 2018 16:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fdaWCJBbVRjh; Fri, 19 Oct 2018 16:54:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3A41310AF; Fri, 19 Oct 2018 16:54:07 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9JNs5Qn033994 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Oct 2018 18:54:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: draft-ietf-stir-passport-shaken@ietf.org, "stir@ietf.org" From: Adam Roach Message-ID: <9237bcc9-9124-24a2-1e95-77715d309daa@nostrum.com> Date: Fri, 19 Oct 2018 18:54:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [stir] AD Review: draft-ietf-stir-passport-shaken-04 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 23:54:10 -0000 This is my AD review for draft-ietf-stir-passport-shaken-04.  I have a handful of comments below that I'd like to see addressed prior to asking the IESG to consider the document. Please treat them as you would any other last-call comments. I have no blocking comments, and will be placing the document in IETF last call shortly. Thanks to everyone who worked on this document. /a --------------------------------------------------------------------------- Abstract: >  Industry Solutions) and the SIP Forum IP-NNI Joint Task Force.  These Please expand "IP-NNI". >  coming from both STIR participating originating communications as Please expand "STIR" on first use. Also, as "STIR-participating" is a compound adjective, it needs to be hyphenated. With the expansion, this would look like:    coming from both SIP Telephony Identity Revisited (STIR)-participating    originating communications as... --------------------------------------------------------------------------- §1: >  The SHAKEN [ATIS-1000074] specification defines a framework for using >  STIR protocols including PASSporT [RFC8225], SIP Authenticated ... >  current telephone network contains both VoIP and TDM/SS7 originated For the purposes of acronym expansion, the Abstract is not treated as part of the document. Please expand SHAKEN, STIR, PASSporT, VoIP, TDM, and SS7 on first use.  See https://www.rfc-editor.org/materials/abbrev.expansion.txt for more details. --------------------------------------------------------------------------- §2: >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >  document are to be interpreted as described in [RFC2119]. Please update to the boilerplate in RFC 8174. --------------------------------------------------------------------------- §3: >  and represents the service provider receiving a call from a non >  PASSporT or STI supporting telephone gateway. Nit: "...from a non-PASSporT- and non-STI-supporting telephone gateway." --------------------------------------------------------------------------- §4: >  can be one of the following three values, 'A', 'B', or 'C' as defined >  in [ATIS-1000074]. Nit: "...one of the following three values: 'A', 'B',..." --------------------------------------------------------------------------- §5: >  opaque identifier corresponding to the service provider-initiated >  calls themselves, Nit: "...service-provider-initiated calls..." >  documents that more precisely guide it's usage in real deployments. Nit: "...its usage..." --------------------------------------------------------------------------- §6: >     "orig":{"tn":"12155551212"}, The NANPA has reserved the range "555-0100" through "555-0199" in all area codes for fictitious use. The number used in this example is a valid number allocated for directory assistance use. Consider using "12155550121" (or some similarly reserved number for this example. See https://www.nationalnanpa.com/number_resource_info/555_numbers.html for more information. --------------------------------------------------------------------------- §7: >  [RFC3261] aligned with the use of the identity header defined in Nit: "...identity header field..." From nobody Fri Oct 19 17:02:10 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D41310AF; Fri, 19 Oct 2018 17:00:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, draft-ietf-stir-passport-shaken@ietf.org, stir@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153999365671.20226.2069042508744108781.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 17:00:56 -0700 Archived-At: Subject: [stir] Last Call: (PASSporT SHAKEN Extension (SHAKEN)) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 00:00:57 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'PASSporT SHAKEN Extension (SHAKEN)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends PASSporT, which is a token object that conveys cryptographically-signed information about the participants involved in communications, to include information defined as part of the SHAKEN specification from ATIS (Alliance for Telecommunications Industry Solutions) and the SIP Forum IP-NNI Joint Task Force. These extensions provide a level of confidence in the correctness of the originating identity for a telephone network that has communications coming from both STIR participating originating communications as well as communications that does not include STIR information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 22 15:52:51 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27788130DD8; Mon, 22 Oct 2018 15:52:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <154024875511.13787.15346454505464433908@ietfa.amsl.com> Date: Mon, 22 Oct 2018 15:52:35 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-rcd-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 22:52:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT Extension for Rich Call Data Authors : Jon Peterson Chris Wendt Filename : draft-ietf-stir-passport-rcd-01.txt Pages : 12 Date : 2018-10-22 Abstract: This document extends PASSporT, a token for conveying cryptographically-signed information about personal communications, to include rich data that can be rendered to users, such as a human- readable display name comparable to the "Caller ID" function common on the telephone network. The element defined for this purpose is extensible to include related information about calls that helps people decide whether to pick up the phone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-rcd-01 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-rcd-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 17:08:35 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0F126BED; Mon, 22 Oct 2018 17:08:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <154025330720.13787.14022156083126853868@ietfa.amsl.com> Date: Mon, 22 Oct 2018 17:08:27 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 00:08:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT Extension for Diverted Calls Author : Jon Peterson Filename : draft-ietf-stir-passport-divert-04.txt Pages : 12 Date : 2018-10-22 Abstract: This document extends PASSporT, which conveys cryptographically- signed information about the people involved in personal communications, to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-divert-04 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-divert-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 11:58:23 2018 Return-Path: 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 D6852130EEC for ; Tue, 23 Oct 2018 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MZE562GiEL4g for ; Tue, 23 Oct 2018 11:58:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D053130F06 for ; Tue, 23 Oct 2018 11:58:19 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9NIwIMO013239 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 23 Oct 2018 13:58:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: stir@ietf.org References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> From: Robert Sparks Message-ID: <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> Date: Tue, 23 Oct 2018 13:58:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154025330720.13787.14022156083126853868@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 18:58:22 -0000 We plan to WGLC this document shortly after the Bangkok meeting, but if anyone has any major issues with it, please bring them up now so we can work them out during that meeting. RjS On 10/22/18 7:08 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. > > Title : PASSporT Extension for Diverted Calls > Author : Jon Peterson > Filename : draft-ietf-stir-passport-divert-04.txt > Pages : 12 > Date : 2018-10-22 > > Abstract: > This document extends PASSporT, which conveys cryptographically- > signed information about the people involved in personal > communications, to include an indication that a call has been > diverted from its original destination to a new one. This > information can greatly improve the decisions made by verification > services in call forwarding scenarios. Also specified here is an > encapsulation mechanism for nesting a PASSporT within another > PASSporT that assists relying parties in some diversion scenarios. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-divert-04 > https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-divert-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Oct 24 06:57:13 2018 Return-Path: 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 9AAA5130ECA for ; Wed, 24 Oct 2018 06:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x1KJm9pqtIzS for ; Wed, 24 Oct 2018 06:57:06 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84DA130EBA for ; Wed, 24 Oct 2018 06:57:05 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id s15-v6so4875050lji.3 for ; Wed, 24 Oct 2018 06:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AJVw6aaj9exiBB6BRypWDgWgPFTcYIZ88MTez5fbhz8=; b=q282sGbYPqZSqHI5Da5ZXmIO2FNnAqH5vmP/KHo/wkV1bjgbjzZ9ISIP372AYTLZ2j c5kSP+ZHu+rP/u4YySmeY/7k5BnOK6XBud0avLJCDapB/74K+Zq7vNZ3i0G4m9nY8vFT qEy85uBAScgbr3mai0MoqFXMnwoDLDHooCtZCOC6MlG7APlQUg6igY71FlDKNKEm5DIt EdbxvNCNtP27qBquU2ikET/H6XiUAcYl9903stBBtPy45SplhyCltiaTz1RzKmvAaXYY s7spu8ROw5jFBpXEzdliZwl14D+uC69SXxixen4tLGJjT5rpZ5FbAKIl23SmKVWjHLqf hDKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AJVw6aaj9exiBB6BRypWDgWgPFTcYIZ88MTez5fbhz8=; b=rY0/UvNpHrAj7hnCQjYarpkuOWLBAc625emWEghSP8jME8ramEKKxowsxSoo3PrgCY DzWdBUayQvHNvCE6pMaKLTtKPIvyMECzKxIRGFnefbyfqlhzfh8q1xIMp4yU1gym0mOV VoLr4NugYFBgTBFKtdNso5gPXMmC06nbUMzz7ERZcdYZTLnIEW5UzeZ2GH6HNngWyKPM opPL5sJncjM2he5iNL7h07eCPD0r8nTJkuHVCgbLJTzrQEX7T1qWCZw96YUuZQvDMERr 0hFnizGK1+VtRisC0r515VesdrW9s4W6BKt2PJwiZGZ3cBy9OUKQilldUVisn7h6cBWd k4CQ== X-Gm-Message-State: AGRZ1gIjfKdMJQ9o8hhb4LAWYm+p2j/kgWmCEbsMtiAyvWZCwOrbvG31 iQhHWI3hNU6gXbDdd7cWPAYka/MI2advC4FDn4FaMQ== X-Google-Smtp-Source: AJdET5cx9c6nH8wyGKDLS28Wa0rA/lBdXBndmSn3VKzco+edcxZuWhvS/aWW7abf/UJGURtgh847ZkfpRvKpAQdalYM= X-Received: by 2002:a2e:8945:: with SMTP id b5-v6mr1811086ljk.20.1540389423330; Wed, 24 Oct 2018 06:57:03 -0700 (PDT) MIME-Version: 1.0 References: <154033551420.31269.7954935189169025965@ietfa.amsl.com> In-Reply-To: <154033551420.31269.7954935189169025965@ietfa.amsl.com> From: Mary Barnes Date: Wed, 24 Oct 2018 08:56:50 -0500 Message-ID: To: "stir@ietf.org Mail List" Content-Type: multipart/alternative; boundary="00000000000064b7cc0578f9dc4a" Archived-At: Subject: [stir] Fwd: I-D Action: draft-barnes-stir-passport-div-hi-callflows-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:57:11 -0000 --00000000000064b7cc0578f9dc4a Content-Type: text/plain; charset="UTF-8" Hi all, I updated the 2nd use case in this document. However, unless I can get someone else to work on it with me, I don't plan on progressing this document as it is very time consuming to do these. And, clearly, I've not had the cycles to work on it as I had planned after IETF-102 (people still need those SS7 point codes, IMSIs and Revenue Accounting office codes). Regards, Mary. --------- Forwarded message --------- From: Date: Tue, Oct 23, 2018 at 5:58 PM Subject: I-D Action: draft-barnes-stir-passport-div-hi-callflows-02.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversion and History-Info Author : Mary Barnes Filename : draft-barnes-stir-passport-div-hi-callflows-02.txt Pages : 17 Date : 2018-10-23 Abstract: This document focuses on use cases and call flows which include the History-Info header field and a SIP Identity header field with a PASSport with a "div" claim in cases of retargeting. These use cases are derived from those provided in the SIP History-Info call flows document. The objective is to describe the optimal way to correlate the History-Info header fields with a PASSporT with diversion information to increase the level of confidence in the History-Info header field by the terminating entity making use of the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-barnes-stir-passport-div-hi-callflows/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-barnes-stir-passport-div-hi-callflows-02 https://datatracker.ietf.org/doc/html/draft-barnes-stir-passport-div-hi-callflows-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-barnes-stir-passport-div-hi-callflows-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --00000000000064b7cc0578f9dc4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I updated the 2nd use case in this document.=C2=A0 However, unless= I can get someone else to work on it with me, I don't plan on progress= ing this document as it is very time consuming to do these.=C2=A0 And, clea= rly, I've not had the cycles to work on it as I had planned after IETF-= 102 (people still need those SS7 point codes, IMSIs and Revenue Accounting = office codes).

Regards,
Mary= .=C2=A0

--------- Forwarde= d message ---------
From: <internet-drafts@ietf.org>
Date: Tue, O= ct 23, 2018 at 5:58 PM
Subject: I-D Action: draft-barnes-stir-passport-d= iv-hi-callflows-02.txt
To: <i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversi= on and History-Info
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mary= Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bar= nes-stir-passport-div-hi-callflows-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-23

Abstract:
=C2=A0 =C2=A0This document focuses on use cases and call flows which includ= e the
=C2=A0 =C2=A0History-Info header field and a SIP Identity header field with= a
=C2=A0 =C2=A0PASSport with a "div" claim in cases of retargeting.= =C2=A0 These use cases
=C2=A0 =C2=A0are derived from those provided in the SIP History-Info call f= lows
=C2=A0 =C2=A0document.=C2=A0 The objective is to describe the optimal way t= o correlate
=C2=A0 =C2=A0the History-Info header fields with a PASSporT with diversion<= br> =C2=A0 =C2=A0information to increase the level of confidence in the History= -Info
=C2=A0 =C2=A0header field by the terminating entity making use of the infor= mation.


The IETF datatracker status page for this draft is:
https://datatracker.iet= f.org/doc/draft-barnes-stir-passport-div-hi-callflows/

There are also htmlized versions available at:
https://tools.ietf.org/htm= l/draft-barnes-stir-passport-div-hi-callflows-02
https://datatrac= ker.ietf.org/doc/html/draft-barnes-stir-passport-div-hi-callflows-02
A diff from the previous version is available at:
https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-barnes-stir-passport-div-hi-callflows-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--00000000000064b7cc0578f9dc4a--