Re: [stir] "iat" value to use during PASSPorT construction
"Asveren, Tolga" <tasveren@rbbn.com> Tue, 15 May 2018 17:32 UTC
Return-Path: <tasveren@rbbn.com>
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 87903126DCA for <stir@ietfa.amsl.com>; Tue, 15 May 2018 10:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 i6Fdlvihd3Yh for <stir@ietfa.amsl.com>; Tue, 15 May 2018 10:32:47 -0700 (PDT)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.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 1936E126C25 for <stir@ietf.org>; Tue, 15 May 2018 10:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PUuWnUjlgp49pHRBA/B19cmZAFuwexBecrpDjLTAf2U=; b=orGPrYu57YHN+9+SkkA80trQnUFDCAbY/8O+MYZl1avXct/bTMuzIrTMslQBQMUngLcAPdSXc/7WeJxAwMptSsrsmOXiVRRXEm3cmTQVQ78dDELLDR+F+ZGA+5dEQd03ZNc/Jy9WxbwnjkXeACzdErWNuG5cX6vWoEpCa148UD8=
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-151-dL8KzpkiN3-W-CUJ0JcM_A-1; Tue, 15 May 2018 13:32:45 -0400
Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB2565.namprd03.prod.outlook.com (10.173.42.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 17:32:42 +0000
Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::35a6:a73e:b07:b27c]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::35a6:a73e:b07:b27c%13]) with mapi id 15.20.0755.018; Tue, 15 May 2018 17:32:42 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Chris Wendt <chris-ietf@chriswendt.net>
CC: "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] "iat" value to use during PASSPorT construction
Thread-Index: AdPrT9q/oUbx39SISTyhzIa9uuwWlAAQE5EAADhxihA=
Date: Tue, 15 May 2018 17:32:42 +0000
Message-ID: <CY4PR03MB316056821A803CC7FF80505AA5930@CY4PR03MB3160.namprd03.prod.outlook.com>
References: <CY4PR03MB3160EE4F4502CCF974B070CFA59C0@CY4PR03MB3160.namprd03.prod.outlook.com> <05192EB8-97F5-4AF5-B415-1A9ECB6514B9@chriswendt.net>
In-Reply-To: <05192EB8-97F5-4AF5-B415-1A9ECB6514B9@chriswendt.net>
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; CY4PR03MB2565; 7:rY28mNVZw8XvsedTun9wt7YsIn6TN9ua/FpefxjRPHzkf6+nO3ZvjvQvqKlBq6teaUg9jgrcfBn9eeIBEzVOKEweepTEkxwegbBUAVqsrqYPyKnibHdH3hu27PpESOgFcQ+RhraHDLXog4XFRtaqe+zY9gc5aT85osEOhzQxv9aw32k3VqOOIg6zDpl1rSClUch42y20/TsMTgyCyg46A2XmYrsnkOjY8ZA1fYKNwMH1wsxSbgXjBbwCU+o8oZYE; 20:K/GicmzGyU/V33gcO354d3eyje8gClA6YAglCBzKw0gQAjvW6rZDu9L5pntwMQYAJtzg98pqcDscw5GgInBSGGJH9+g9xPX/7+10bhQbvV+wl+RMjoXxjidraPxA2fJM3iCdoTjHjxki/JLvTUyuWGuD0cdk3KnkgKs2bI0C8l0=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB2565;
x-ms-traffictypediagnostic: CY4PR03MB2565:
x-microsoft-antispam-prvs: <CY4PR03MB256561895CCDC3450D6C0DFCA5930@CY4PR03MB2565.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR03MB2565; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2565;
x-forefront-prvs: 0673F5BE31
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(39380400002)(189003)(199004)(3280700002)(2906002)(2900100001)(76176011)(97736004)(478600001)(102836004)(966005)(59450400001)(68736007)(25786009)(6506007)(33656002)(66066001)(7736002)(81166006)(81156014)(8676002)(8936002)(53546011)(229853002)(99286004)(7696005)(6436002)(606006)(3660700001)(6916009)(5660300001)(4326008)(6246003)(53936002)(55016002)(54896002)(236005)(9686003)(6306002)(14454004)(106356001)(19609705001)(74316002)(105586002)(26005)(186003)(11346002)(5250100002)(316002)(486006)(446003)(86362001)(6116002)(3846002)(790700001)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2565; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-microsoft-antispam-message-info: S3eVwgUZ6YWvspMyFaX4zpDG8xqeQ2NiwvvlEQs7rgc/nFRFModkgD2SUzKQ/Osh6oaoT5bIyyEbxo7ieJq8C3TUq7ddljTiiTu0zyFFcVVE8gjDA8qyToGolXVgPr3eXDYQAk3W3JFaUa0wwQrzLyUXaEj4pgt36od2BtOtRjQaAdbxfOe2CxRJLtRnqniP
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: ab0f2358-74f3-43aa-36b4-08d5ba89dd1a
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab0f2358-74f3-43aa-36b4-08d5ba89dd1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 17:32:42.4624 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2565
X-MC-Unique: dL8KzpkiN3-W-CUJ0JcM_A-1
Content-Type: multipart/alternative; boundary="_000_CY4PR03MB316056821A803CC7FF80505AA5930CY4PR03MB3160namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/nXK5K3J-Qeh9w1wZ0zOutfGsQLY>
Subject: Re: [stir] "iat" value to use during PASSPorT construction
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 17:32:51 -0000
Ideally specifications should have a firm stand on the scope of “iat” IMHO. Ambiguity is something to avoid even if the immediately envisioned use cases could function with both interpretations (and honestly I even doubt that let alone the impact on future extensions/new claim types). As I already indicated, what makes sense to me is that it for the “JSW”, not for the session therefore “current time” instead of Date needs to be used. And as a side question: Is there really a practical concern regarding full-form being longer than the compact form? Are the extra few hundreds of octets really something causing heartburn considering that media associated with a session usually would require several magnitudes more? Thanks, Tolga From: Chris Wendt <chris-ietf@chriswendt.net> Sent: Monday, May 14, 2018 10:31 AM To: Asveren, Tolga <tasveren@rbbn.com> Cc: stir@ietf.org Subject: Re: [stir] "iat" value to use during PASSPorT construction ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Tolga, I think the 60sec recommendation is a default, however, i think once we get more operational experience to see what the delta offsets of time typically are, we will have a better sense of what value to use and whether to move to a smaller time window or not. This should in general be considered local policy what you believe is an acceptable time window. You may also want to implement secondary TDOS/replay attack types of protection to help here as well and not solely depend on “iat” freshness within that short time window. In regards to the other part of your question, 8224 is saying to use the PASSporT “iat” to correspond to the DATE value of the SIP. The assumption is that the PASSporT is being created at/close to the initiation of the INVITE. I think whether you interpret that as taking the DATE and setting it exactly to the “iat” or if you are generating a PASSporT “iat” as a specifically 8225 compliant function in isolation, either will generally work if you are using full form of passport. From what i’m personally aware of, most implementations are following the former vs the latter. -Chris On May 14, 2018, at 5:17 AM, Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> wrote: RFC 8224 has the following in Section “4.1 PASSPorT Construction”: Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED). RFC 8225 has the following in Section “5.1.1 “iat” (Issued At) Claim”: The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519], Section 4.1.6). As defined, the "iat" claim should be set to the date and time of issuance of the JWT and MUST indicate the date and time of the origination of the personal communications. The time value should be of the NumericDate format as defined in [RFC7519], Section 2. This is included for securing the token against replay and cut-and-paste attacks, as explained further in Section 10 ("Security Considerations"). i- I see some conflict in RFC8225 text. It is mentioned that “iat” should be set based on issuance of JWT (which would be when PASSPorT is constructed). OTOH, it is also stated that it MUST indicate the date and time of the origination of the personal communication. The former seems to be the right approach as what we would like to protect against cut-and-paste attacks is the PASSPorT in the context of a particular communication session. Coupling of PASSPorT with the communication session is provided through “orig”/”dest”. “iat” should be set to the time of generation of PASSPorT IMHO. RFC8244 text seems to be O.K. if one accepts this interpretation as it has the notion of “local policy for freshness”. The recommended value is on the very high end (anything more than a few seconds is too much in practice IMHO) but it is at least not mandating use of 60s. ii- Aren’t there legitimate cases where a communication session continues for some period of time and then due to change in its nature requires addition of PASSPorT, e.g. first there is an announcement/interaction with an automated system (which may last several minutes) and then the called-party is contacted during which PASSPorT is added (because, for example, organizational boundaries are crossed and there is a need to validate calling-party identity). For such cases there could be a legitimate and major discrepancy between Date and “current time”. This is another argument in favor of considering “iat” as corresponding to PASSPorT generation rather than start of communication session IMHO. There could eb many other scenarios where similar discrepancy legitimately happens especially if one considers non-base claim types, e.g.. “div”. So, the bottom line is I would like to get people’s opinion about whether “iat” should pertain to the start of communication session or to the creation of PASSPorT. Thanks, Tolga _______________________________________________ stir mailing list stir@ietf.org<mailto:stir@ietf.org> https://www.ietf.org/mailman/listinfo/stir
- [stir] "iat" value to use during PASSPorT constru… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Chris Wendt
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Chris Wendt
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Peterson, Jon
- Re: [stir] "iat" value to use during PASSPorT con… williw
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Gorman, Pierce A [CTO]
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Gorman, Pierce A [CTO]
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga
- Re: [stir] "iat" value to use during PASSPorT con… Gorman, Pierce A [CTO]
- Re: [stir] "iat" value to use during PASSPorT con… Asveren, Tolga