RFC Verifier Behavior Step 4: Check the Freshness of Date

Slides:



Advertisements
Similar presentations
Communication Service Identifier Requirements on SIP draft-loreto-3gpp-ics-requirements.txt
Advertisements

Rfc4474bis-01 IETF 89 (London) STIR WG Jon & Cullen.
Extending ForeFront beyond the limit TMGUAG ISAIAG AG Security Suite.
IETF 91 DISPATCH draft-jesske-dispatch-forking- answer-correlation-02 Roland Jesske.
Identity in SIP (and in-band) STIR BoF Berlin, DE 7/30/2013.
Proxy Authentication of the Emergency Status of SIP Calls draft-barnes-ecrit-auth-00 Richard Barnes IETF 69, Chicago, IL, USA.
1 SIP WG meeting 73rd IETF - Minneapolis, MN, USA November, 2008 Return Routability Check draft-kuthan-sip-derive-00 Jiri
Request History – Solution Mary Barnes SIP WG Meeting IETF-57 draft-ietf-sip-history-info-00.txt.
STIR Charter (discussion) STIR BoF Berlin, DE 7/30/2013.
Secure Credential Manager Claes Nilsson - Sony Ericsson
Certificate Credentials STIR WG IETF 91 (Honolulu) Sean Jon.
All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Alec Brusilovsky, Zhibi Wang Alcatel-Lucent, July 24, 2007.
Use of the IPv6 Flow Label as a Transport-Layer Nonce draft-blake-ipv6-flow-nonce-02 Steven Blake IETF 76 November 2009.
Rfc4474bis-01 IETF 90 (Toronto) STIR WG Jon. First principles (yet again) Separating the work into two buckets: 1) Signaling – What fields are signed,
1 IETF 88 (Vancouver) November 6, 2013 Cullen Jennings V3.
Andrew Allen Communication Service Identifier.
All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Zhibi Wang January, 2007.
SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks Flemming Andreasen W. Marshall, K. K. Ramakrishnan,
1 Pascal URIEN, IETF 63th Paris, France, 2nd August 2005 “draft-urien-eap-smartcard-type-02.txt” EAP Smart Card Protocol (EAP-SC)
Stir-cnam STIR WG / IETF 95 Buenos Aires, Apr 2016 Jon.
Timeline – Standards & Requirements
Session-Independent Policies draft-ietf-sipping-session-indep-policy-02 Volker Hilt Jonathan Rosenberg Gonzalo.
Authenticated Identity
draft-rescorla-fallback-01
Public Key Infrastructure (PKI)
TN Proof-of-Possession and Number Portability
STIR WG / IETF 94 Yokohama, Nov 2015 Jon
Timeline - ATIS Involvement
Request History Capability – Requirements & Solution
Improving Security of Real-time Communications
SHAKEN Governance Authority Criteria
STIR WG / IETF 97 Seoul, Nov 2016 Jon
Donald E. Eastlake 3rd TSIG SHA etc. Donald E. Eastlake 3rd March.
Chris Wendt, David Hancock (Comcast)
Timeline - ATIS Involvement
Proposed ATIS Standard for Signing of SIP RPH
Verstat Related Best Practices
Reference Architecture and Call Flow Example for SIP RPH Signing
Analysis of Use of Separate Identity Header for SIP RPH Signing
NS/EP Service Provider Credential for SIP RPH Signing
RFC PASSporT Construction 6.2 Verifier Behavior
SHAKEN Jim McEachern Senior Technology Consultant ATIS December 2017.
Proposal for Change/Improvements in STIR/SHAKEN Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server.
RFC PASSporT Construction 6.2 Verifier Behavior
RFC PASSporT Construction 6.2 Verifier Behavior
IETF 101 (London) STIR WG Mar2018
SIP RPH and TN Signing Cross Relationship
STIR WG IETF-100 PASSPorT Extension for Resource-Priority Authorization (draft-ietf-stir-rph-01) November, 2017 Ray P. Singh, Martin Dolly, Subir Das,
Extending the SIP Reason Header with Warning Codes draft-hautakorpi-reason-header-for-warnings-00.txt
TN-PoP Scenarios Jim McEachern Principal Technologist ATIS August 2018.
STIR WG IETF-99 PASSPorT Extension for Resource-Priority Authorization (draft-ietf-stir-rph-00) July, 2017 Ray P. Singh, Martin Dolly, Subir Das, and An.
Change Proposals for SHAKEN Documents
SIP RPH Signing Use Cases
STIR WG IETF-102 PASSPorT Extension for Resource-Priority Authorization (draft-ietf-stir-rph-06) July 18, 2018 Ray P. Singh, Martin Dolly, Subir Das, and.
SHAKEN Jim McEachern Senior Technology Consultant ATIS December 2017.
Proposal for Change/Improvements in STIR/SHAKEN Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server.
Proposal for Change/Improvments in STIR/SHAKEN Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server.
IPNNI SHAKEN Enterprise Models: LEMON TWIST
Rifaat Shekh-Yusef IETF105, OAuth WG, Montreal, Canada 26 July 2019
SHAKEN for Presented to: Ericsson Contact:
Calling Party Identity
Enterprise Use Cases and A-Level Attestation
Enterprise Use Cases and A-Level Attestation
Proposed Changes to STI-VS "iat" freshness check
STIR / SHAKEN for 911 use of SHAKEN 8/7/2019
Calling Party Identity
Rich Call Data Integrity Mechanism
draft-ietf-stir-oob-02 Out of Band
IETF 103 (กรุงเทพฯ) STIR WG Nov 2018
IETF 102 (Montreal) STIR WG Jul 2018
Presentation transcript:

iat content based on PASSporT issuance time Conflict Analysis against RFC8224 / ATIS-1000074

RFC8224 6.2 Verifier Behavior Step 4: Check the Freshness of Date The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the attacks this prevents, see Section 12.1. If the full form of the PASSporT is present, the verifier SHOULD compare the "iat" value in the PASSporT to the Date header field value in the request. If the two are different, and the "iat" value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the "iat" value instead of the Date header field value. For full form, “iat”, Date header content being different is allowed That “iat” passes freshness check is sufficient

ATIS-1000074 5.3.1 PASSporT & Identity Header Verification The verifier validates that the PASSporT token provided in the Identity header of the INVITE includes all of the baseline claims, as well as the SHAKEN extension claims. The verifier shall also follow the draft-ietf-stirrfc4474bis-defined verification procedures to check the corresponding date, originating identity (i.e., the originating telephone number) and destination identities (i.e., the terminating telephone numbers). Follows RFC8224, no new mandates regarding date check 5.3.3 Use of the Full Form of PASSporT Draft-ietf-stir-rfc4474bis supports the use of both full and compact forms of the PASSporT token in the Identity header. The full form of the PASSporT token shall be used to avoid any potential SIP network element interaction with headers, in particular the Date header field, which could lead to large numbers of 438 (‘Invalid Identity Header’) errors being generated. Use of full form mandated