RFC 2716bis Wednesday, July 12, 2006 Draft-simon-emu-rfc2716bis-02.txt Dan Simon Bernard Aboba IETF 66, Montreal, Canada.

Slides:

Advertisements

Similar presentations

Doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 1 PEKM (Post-EAP Key Management Protocol) Bernard Aboba, Microsoft Dan Harkins,

Advertisements

Adding SASL to HTTP/1.1 draft-nystrom-http-sasl-07.txt Magnus Nyström, RSA Security Alexey Melnikov, Isode Limited

Version 1 of EAP-TTLS draft-ietf-pppext-eap-ttls-05.txt Paul Funk Funk Software.

Doc.: IEEE /275 Submission September 2000 David Halasz, Cisco Systems, Inc.Slide 1 IEEE 802.1X for IEEE David Halasz, Stuart Norman, Glen.

1 © NOKIA MitM.PPT/ 6/2/2015 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM) The Insecurity of Tunnelled Authentication Protocols N. ASOKAN, VALTTERI NIEMI,

1 © NOKIA MitM.PPT/ 6/2/2015 / Kaisa Nyberg (NRC/MNW), N.Asokan (NRC/COM) The Insecurity of Tunnelled Authentication Protocols N. ASOKAN, VALTTERI NIEMI,

Responder Anonymity and Anonymous Peer-to-Peer File Sharing. by Vincent Scarlata, Brian Levine and Clay Shields Presentation by Saravanan.

Ariel Eizenberg PPP Security Features Ariel Eizenberg

IEEE Wireless Local Area Networks (WLAN’s).

Chapter 8 Web Security.

July 16, 2003AAA WG, IETF 571 AAA WG Meeting IETF 57 Vienna, Austria Wednesday, July 16,

 It defines the format of the frame to be exchanged between devices.  It defines how two devices can negotiate the establishment of the link and the.

Network Security1 – Chapter 5 (B) – Using IEEE 802.1x Purpose: (a) port authentication (b) access control An IEEE standard

EMU BOF EAP Method Requirements Bernard Aboba Microsoft Thursday, November 10, 2005 IETF 64, Vancouver, CA.

1 © 2005 Cisco Systems, Inc. All rights reserved. 111 © 2004, Cisco Systems, Inc. All rights reserved.

1 EAP Usage Issues Feb 05 Jari Arkko. 2 Typical EAP Usage PPP authentication Wireless LAN authentication –802.1x and i IKEv2 EAP authentication.

EAP WG EAP Key Management Framework Draft-ietf-eap-keying-03.txt Bernard Aboba Microsoft.

1 /10 Pascal URIEN, IETF 66 h, Wednesday July 12 th,Montreal, Canada draft-urien-badra-eap-tls-identity-protection-00.txt

Shambhu Upadhyaya Security –Upper Layer Authentication Shambhu Upadhyaya Wireless Network Security CSE 566 (Lecture 10)

Hokey IETF 81 Quebec1 EAP Extensions for EAP Re- authentication Protocol draft-ietf-hokey-rfc5296bis-04 Qin Wu Zhen Cao Yang Shi Baohong He.

XMPP Concrete Implementation Updates: 1. Why XMPP 2 »XMPP protocol provides capabilities that allows realization of the NHIN Direct. Simple – Built on.

1 DHCP Authentication Discussion INTAREA meeting, 70th IETF Vancouver, Canada Jari Arkko and Ralph Droms.

IETF 60 – San Diegodraft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Real-Time Streaming Protocol draft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Aravind.

EAP Key Framework Draft-ietf-eap-keying-01.txt IETF 58 Minneapolis, MN Bernard Aboba Microsoft.

EAP Keying Problem Draft-aboba-pppext-key-problem-03.txt Bernard Aboba

Doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 1 PEKM (Post-EAP Key Management Protocol) Dan Harkins, Trapeze Networks

July 16, Diameter EAP Application (draft-ietf-aaa-eap-02.txt) on behalf of...

Session Peering Protocol over SOAP I-D ( draft-ietf-drinks-spp-over-soap-01) draft-ietf-drinks-spp-over-soap-01 0 Presenter: Vikas Bhatia (On behalf of.

March 15, 2005 IETF #62 Minneapolis1 EAP Discovery draft-adrangi-eap-network-discovery-10.txt Farid Adrangi ( )

July 16, 2003AAA WG, IETF 571 EAP Keying Framework Draft-aboba-pppext-key-problem-07.txt EAP WG IETF 57 Vienna,

PAWS: Security Considerations Yizhuang WU, Yang CUI PAWS WG

EAP Extensions for EAP Re- authentication Protocol (ERP) draft-wu-hokey-rfc5296bis-01 Yang Shi Qin Wu Zhen Cao

Doc.: IEEE /524r0 Submission November 2001 Bernard Aboba, MicrosoftSlide 1 Secure Remote Password (SRP) Bernard Aboba Dan Simon Tim Moore Microsoft.

EMU BOF EAP-TLS Experiment Report RFC 2716 Bernard Aboba Microsoft Thursday, November 10, 2005 IETF 64, Vancouver, CA.

Draft-ietf-dime-ikev2-psk-diameter-0draft-ietf-dime-ikev2-psk-diameter-08 draft-ietf-dime-ikev2-psk-diameter-09 in progress Diameter IKEv2 PSK: Pre-Shared.

RADEXT WG IETF 91 Rechartering. Why? Current charter doesn’t allow us to take on new work that is waiting in the queue Has an anachronistic Diameter entanglement.

IETF-81, Quebec City, July 25-29, 2011

November 2005IETF 64, Vancouver, Canada1 EAP-POTP The Protected One-Time Password EAP Method Magnus Nystrom, David Mitton RSA Security, Inc.

EAP-FAST Version 2 draft-zhou-emu-eap-fastv2-00.txt Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna March 2011.

EAP Keying Framework Draft-aboba-pppext-key-problem-06.txt EAP WG IETF 56 San Francisco, CA Bernard Aboba.

ICOS BOF EAP Applicability Bernard Aboba IETF 62, Minneapolis, MN.

March 17, 2003 IETF #56, SAN FRANCISCO1 Compound Authentication Binding Problem (EAP Binding Draft) Jose Puthenkulam Intel Corporation (

CSE 8343 State Machines for Extensible Authentication Protocol Peer and Authenticator.

1 Pascal URIEN, IETF 63th Paris, France, 2nd August 2005 “draft-urien-eap-smartcard-type-02.txt” EAP Smart Card Protocol (EAP-SC)

Real-Time Streaming Protocol draft-ietf-mmusic-rfc2326bis-01.txt Magnus Westerlund.

Emu wg, IETF 70 Steve Hanna, EAP-TTLS draft-funk-eap-ttls-v0-02.txt draft-hanna-eap-ttls-agility-00.txt emu wg, IETF 70 Steve Hanna,

RTCWEB STUN Usage for Consent Freshness and Session Liveness draft-muthu-behave-consent-freshness-01 Authors: D. Wing, Muthu A M. Perumal, R. Ram Mohan,

IETF68 DIME WG Open Issues for RFC3588bis Victor Fajardo (draft-ietf-dime-rfc3588bis-02.txt)

Design Guidelines Thursday July 26, 2007 Bernard Aboba IETF 69 Chicago, IL.

Requirements and Selection Process for RADIUS Crypto-Agility December 5, 2007 David B. Nelson IETF 70 Vancouver, BC.

N. Asokan, Kaisa Nyberg, Valtteri Niemi Nokia Research Center

ECC Design Team: Initial Report Brian Minard, Tolga Acar, Tim Polk November 8, 2006.

1 EAP-MAKE2: EAP method for Mutual Authentication and Key Establishment, v2 EMU BoF Michaela Vanderveen IETF 64 November 2005.

1 Extensible Authentication Protocol (EAP) Working Group IETF-57.

1 SECMECH BOF EAP Methods IETF-63 Jari Arkko. 2 Outline Existing EAP methods Technical requirements EAP WG process for new methods Need for new EAP methods.

IETF-84 EMU TEAP Updates Nancy Joseph Salowey Hao Zhou

8-1 CSE 4707/5850 Network Security (2) SSL/TLS. 8-2 Think about Google or YouTube  Desired properties  Indeed the other side is Google or YouTube server.

@Yuan Xue CS 285 Network Security Secure Socket Layer Yuan Xue Fall 2013.

Cryptography CSS 329 Lecture 13:SSL.

Introduction to Port-Based Network Access Control EAP, 802.1X, and RADIUS Anthony Critelli Introduction to Port-Based Network Access Control.

EAP WG EAP Key Management Framework Draft-ietf-eap-keying-05.txt Bernard Aboba Microsoft IETF 62, Minneapolis, MN.

EAP Applicability IETF-86 Joe Salowey. Open Issues Open Issues with Retransmission and re- authentication Remove text about lack of differentiation in.

November 18, 2002 IETF #55, ATLANTA1 Problem with Compound Authentication Methods Jesse Walker Intel Corporation (

Open issues with PANA Protocol

RADEXT WG RADIUS Attributes for WLAN Draft-aboba-radext-wlan-00.txt

for IP Mobility Protocols

IETF-70 EAP Method Update (EMU)

The Tunneled Extensible Authentication Method (TEAM)

Charles Clancy Katrin Hoeper IETF 73 Minneapolis, USA 17 November 2008

PEKM (Post-EAP Key Management Protocol)

Presentation transcript:

RFC 2716bis Wednesday, July 12, 2006 Draft-simon-emu-rfc2716bis-02.txt Dan Simon Bernard Aboba IETF 66, Montreal, Canada

Document Status Changes from RFC Section 2.5: Added EAP-TLS key hierarchy diagram, EMSK formula corrected (no longer broken into halves), added definition of Session- Id, clarified that PRF in [RFC4346] is used (e.g. not version specific). Section 2.6:Added mandatory-to-implement ciphersuites. Section 4.6: Added section on packet modification attacks. Changed TLS protocol references to [RFC4346] from [RFC2246], added reference to [RFC3280]. Section 2.5: Addition of key derivation formulas from Key Framework Appendix Section 4.1: Security claims Section 4.3: Certificate usage restrictions

Document Status (cont’d) Changes from RFC Broadening of PPP-specific focus Reference Update (Normative vs. Informative) Section 2.4: Update of Identity Verification based on RFC 3748 advice (e.g. EAP-Identity/Response used only for routing). Section 2.6: Removal of lower layer ciphersuite and compression negotiation via TLS

Open Issues From Joe What if the altSubjectName extension is empty? Should the subjectName be used instead? How is the ID represented? What if there is more than one altSubjectName? Does order matter? From Sam Does multiple layers of negotiation with EAP-TLS introduce a vulnerability? Can a peer or server negotiate a weaker authentication method via TLS than via EAP? From Vidya Clarification of client certificate auth requirement. Server authentication failure and EAP-Failure packet. Addition of difference list from RFC 2716.

Open Issues (cont’d) Mandatory-to-Implement ciphersuites – 3DES/HMAC-SHA1 failed interoperability tests.  Privacy

Thinking About Privacy Transition assumptions Server is upgraded to support privacy first. Clients are gradually upgraded, so they are mixed legacy/upgraded clients. Privacy support is a binary switch on the upgraded client. If configured for privacy, client sends an anonymous identity (e.g. or in the EAP-Response/Identity. Requirements for backward compatibility Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. Legacy client not configured for privacy must connect to an upgraded server without privacy being negotiated.

Recommended Approach Server always requests a client certificate Client not configured for privacy sends the client certificate. EAP-TLS conversation continues as normal. Client desiring privacy ignores the request. Server supporting privacy brings up the TLS channel, then asks requests a client certificate again. If client does not respond, server terminates the connection.

Evaluation Upgraded client not configured for privacy must connect successfully to a legacy server without privacy support. OK. Client answers the server certificate request, no change. Upgraded client requiring privacy must fail to connect to a legacy server without privacy support. OK. Client does not answer the initial server certificate request, legacy server will fail authentication. Legacy client not configured for privacy must connect to an upgraded server without privacy being negotiated. OK. Client answers the initial server certificate request, privacy not negotiated.

Next Steps Close the open issues, issue new version. Implementation survey Initial solicitation on the list garnered 4 responses Need info on interoperability issues, implemented features and ciphersuites. Potential for interoperability testing if needed.

Feedback?