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

Slides:



Advertisements
Similar presentations
1 © 2001, Cisco Systems, Inc. All rights reserved. © 2004, Cisco Systems, Inc. All rights reserved. Location Conveyance in SIP draft-ietf-sipping-location-requirements-02.
Advertisements

Presence, Security and Privacy. VON The Current Environment Many Faces of Security Authentication Verify someone is who they.
8/26/98IPP IETF1 IPP Scheme –Help users distinguish IPP objects from other web objects. –Users will always see ipp:// as URL format for IPP Printers and.
Authentication Applications. will consider authentication functions will consider authentication functions developed to support application-level authentication.
Hypertext Transfer PROTOCOL ----HTTP Sen Wang CSE5232 Network Programming.
Wireless LAN  Setup & Optimizing Wireless Client in Linux  Hacking and Cracking Wireless LAN  Setup Host Based AP ( hostap ) in Linux & freeBSD  Securing.
IETF Trade Working Group January 2000 XML Messaging Overview January 2000.
Jabber and Extensible Messaging and Presence Protocol (XMPP) Presenter: Michael Smith Cisc 856 Dec. 6, 2005.
SIP issues with S/MIME and CMS Rohan Mahy SIP, SIPPING co-chair.
Presented by Fengmei Zou Date: Feb. 10, 2000 The Secure Sockets Layer (SSL) Protocol.
SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
Unifying the conceptual levels of network security through use of patterns Ph.D Dissertation Proposal Candidate: Ajoy Kumar, Advisor: Dr Eduardo B. Fernandez.
Socket Layer Security. In this Presentation: need for web security SSL/TLS transport layer security protocols HTTPS secure shell (SSH)
BASIC CRYPTOGRAPHY CONCEPT. Secure Socket Layer (SSL)  SSL was first used by Netscape.  To ensure security of data sent through HTTP, LDAP or POP3.
Web basics HTTP – – URI/L/Ns – HTML –
HTTP By: Becky Fultz, Joe Flager, Katie Huston, Tom Packard, Allison Wilsey.
Hypertext Transfer Protocol Kyle Roth Mark Hoover.
Chapter 8 Web Security.
Hypertext Transport Protocol CS Dick Steflik.
SIP Greg Nelson Duc Pham. SIP Introduction Application-layer (signaling) control protocol for initiating a session among users Application-layer (signaling)
Session Policy Framework using EAP draft-mccann-session-policy-framework-using-eap-00.doc IETF 76 – Hiroshima Stephen McCann, Mike Montemurro.
SIMPLE MAIL TRANSFER PROTOCOL SECURITY Guided By Prof : Richard Sinn Bhavesh Jadav Mayur Mulani.
NEA Working Group IETF meeting Nov 17, 2011 IETF 82 - NEA Meeting1.
CP476 Internet Computing Lecture 5 : HTTP, WWW and URL 1 Lecture 5. WWW, HTTP and URL Objective: to review the concepts of WWW to understand how HTTP works.
Secure Socket Layer (SSL)
SIP OAuth Rifaat Shekh-Yusef IETF 90, SIPCore WG, Toronto, Canada July 21,
Sistem Jaringan dan Komunikasi Data #9. DNS The Internet Directory Service  the Domain Name Service (DNS) provides mapping between host name & IP address.
Behzad Akbari Spring 2012 (These slides are based on lecture slides by Lawrie Brown)
Web HTTP Hypertext Transfer Protocol. Web Terminology ◘Message: The basic unit of HTTP communication, consisting of structured sequence of octets matching.
Cosc 4765 SSL/TLS and VPN. SSL and TLS We can apply this generally, but also from a prospective of web services. Multi-layered: –S-http (secure http),
Shambhu Upadhyaya Security –Upper Layer Authentication Shambhu Upadhyaya Wireless Network Security CSE 566 (Lecture 10)
XMPP Concrete Implementation Updates: 1. Why XMPP 2 »XMPP protocol provides capabilities that allows realization of the NHIN Direct. Simple – Built on.
IETF 60 – San Diegodraft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Real-Time Streaming Protocol draft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Aravind.
1 Security Protocols in the Internet Source: Chapter 31 Data Communications & Networking Forouzan Third Edition.
Department of Computer Science & Engineering San Jose State University
Doc.: IEEE /495r1 Submission July 2001 Jon Edney, NokiaSlide 1 Ad-Hoc Group Requirements Report Group met twice - total 5 hours Group size ranged.
PAWS: Security Considerations Yizhuang WU, Yang CUI PAWS WG
All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Alec Brusilovsky, Zhibi Wang Alcatel-Lucent, July 24, 2007.
Security, NATs and Firewalls Ingate Systems. Basics of SIP Security.
Web Technologies Interactive Responsiveness Function Hypertext Web E-Publishing Simple Response Web Fill-in Forms Object Web « Full-Blown » Client/Server.
SIP working group IETF#70 Essential corrections Keith Drage.
©Stephen Kingham SIP Protocol overview SIP Workshop APAN Taipei Taiwan 23rd Aug 2005 By Stephen Kingham
November 2005IETF 64, Vancouver, Canada1 EAP-POTP The Protected One-Time Password EAP Method Magnus Nystrom, David Mitton RSA Security, Inc.
All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Zhibi Wang January, 2007.
9-10 March 2005IETF 62 - Minneapolis, MN, USA1 Lemonade IETF 62 Eric Burger Glenn Parsons
Real-Time Streaming Protocol draft-ietf-mmusic-rfc2326bis-01.txt Magnus Westerlund.
A Framework for Session Initiation Protocol User Agent Profile Delivery (draft-ietf-sipping-config-framework-11) SIPPING – IETF 68 Mar 19, 2007 Sumanth.
TLS Renegotiation Vulnerability IETF-76 Joe Salowey Eric Rescorla
RFC 2716bis Wednesday, July 12, 2006 Draft-simon-emu-rfc2716bis-02.txt Dan Simon Bernard Aboba IETF 66, Montreal, Canada.
NEA Working Group IETF meeting July 27, 2011 Jul 27, 2011IETF 81 - NEA Meeting1.
December 14, 2000Securely Available Credentails (SACRED) - Framework Draft 1 Securely Available Credentials (SACRED) Protocol Framework, Draft Specification.
Doc.: IEEE /403r0 Submission July 2001 Albert Young, 3Com, et alSlide 1 Supplementary Functional Requirements for Tgi ESS Networks Submitted to.
Draft-lemonade-imap-submit-00.txt “Forward without Download” Allow IMAP client to include previously- received message (or parts) in or as new message.
Cryptography CSS 329 Lecture 13:SSL.
1 Cryptography CSS 329 Lecture 12: Kerberos. 2 Lecture Outline Kerberos - Overview - V4 - V5.
The Secure Sockets Layer (SSL) Protocol
MQTT-255 Support alternate authenticaion mechanisms
How HTTP Works Made by Manish Kushwaha.
Open issues with PANA Protocol
Hypertext Transfer Protocol
draft-ietf-simple-message-sessions-00 Ben Campbell
Hypertext Transfer Protocol
Hypertext Transport Protocol
Originally by Yu Yang and Lilly Wang Modified by T. A. Yang
The Secure Sockets Layer (SSL) Protocol
OAuth Design Team Call 11th February 2013.
Web Server Design Week 13 Old Dominion University
IEEE MEDIA INDEPENDENT HANDOVER
Web Server Design Week 13 Old Dominion University
Limiting GAS State-1 Query Response Length
Presentation transcript:

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

Benefits of using SASL in HTTP Adds a security framework to HTTP/1.1 with programmatic possibilities and “pluggable” security Not necessarily public key-based security like TLS Client always authenticates, mutual authentication is possible depending on chosen SASL mechanism –SASL allows for stronger authentication mechanisms than Basic and Digest Adds a possibility to establish a secure “End-to-End” channel between a HTTP client and server (not involving any TLS client or server)

Benefits of a SASL security layer The benefit of a SASL mechanism providing a security layer is that entire HTTP messages will be protected when transmitted rather than just the HTTP body. As with TLS, once the authentication exchange has completed, the HTTP protocol exchanges continue unaware that they are being protected –Requires the use of CONNECT to avoid confusing proxies… –Avoids potential MITM attacks which may exist with tunneled authentication (see e.g.

Technical details The document describes a “full” SASL profile, including: –Both client and server can request a security handshake –Support of SASL security layers (for persistent connections) –Client can query the server for the list of available SASL mechanisms –Possibility to optimize the SASL handshake when it is known that there is only a single applicable SASL mechanism when the SASL mechanism requires client to send data first (“initial response” message type) Can be used to authenticate to both the end-server and a proxy and vice versa.

Example C: GET HTTP/1.1 Host: classified.example.com S: HTTP/ Unauthorized Cache-Control: no-store WWW-Authenticate: SASL mechanisms="GSSAPI,KERBEROS_V4,DIGEST-MD5", id="0001" C: CONNECT classified.example.com:80 HTTP/1.1 Host: classified.example.com S: HTTP/ OK C: GET HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="KERBEROS_V4", id="0001" S: HTTP/ Unauthorized Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=AmFYig== C: GET HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001", credentials=Bac...OKi1Qh S: HTTP/ Unauthorized Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=or//EoAADZI= C: GET HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001", credentials=DiAF5A4gA+oOIALuBkAAmw== S: HTTP/ OK Cache-Control: no-store WWW-Authenticate: SASL id="0001" CP: GET HTTP/1.1 Host: classified.example.com SP: HTTP/ OK...Requested Document follows... CP:...Any subsequent request for a data on the same server, unless the server requests reauthentication...

Some design decisions Use 401 as return code during SASL handshake Allow interleaving of authentication exchanges Avoiding sending request body with every authentication step for POST/PUT methods –Currently suggest to use POST requests with no body Use of persistent connections –required if negotiating a security layer –not required if only doing authentication, but recommended New 2XX status codes to specify that "authentication is complete, please resubmit the original request” –Though adds additional round-trip Use of OPTIONS method for requesting the list of supported mechanisms

Persistent connection Use of persistent connection was a subject of many debates. HTTP experts insist that authentication should work even in absence of persistent connection –Proposed method now supports this, but: Any server implementing SASL in HTTP in absence of a persistent connection has to deal with the following difficulties: –session caching (need to keep a cache of SASL sessions) –session expiration (can’t free SASL session on disconnect anymore) –dealing with duplicated authentication requests (client retries or attacks can make life more difficult) –keeping track of authenticated clients using some state management technique

Some open issues Not dealing with how a SASL server shall track the client after authentication (in the absence of persistent connection) Usage of the SASL "realm" parameter is underspecified

Prior Art RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication" defines BASIC authentication (cleartext) and DIGEST (vulnerable to man-in-the-middle attacks, no security layer) draft-brezak-spnego-http-XX.txt by John Brezak –Works only with SPNEGO GSSAPI authentication mechanisms –Doesn’t support channel protection (authentication only). –Needs special indication from proxies that they don’t share authentication state ("Proxy-support: Session-Based-Authentication”) draft-burdis-http-sasl-XX by Keith Burdis (expired) used HTTP Upgrade. –CONNECT is required to establish the end-to-end tunnel, as the Upgrade header is hop-by-hop. –Comments and suggestions from Keith have been incorporated into our memo (and this presentation)

Next step Cleanup remaining minor outstanding issues –Comments and feedback solicited, send to authors or http- (subscribe using Last Call the document in July/August Need implementations! IESG to resist publishing documents based on HTTP Basic/Digest (e.g. Basic and Digest for SIP)?