Security Extensions for the Web
1996 RSA Data Security Conference
Rohit Khare
Security Extensions for the Web
l	Introduction to W3 Consortium
l	W3C Working Groups
»	Web Transaction Security
»	Payment System Interfaces
l	W3C Extension Technology
»	HTTP Extension Protocol [PEP]
»	Security Extension Architecture [SEA]
Presentation Overview (1/2)
l	Web Security
»	Current products and proposals
»	W3C’s goals for Web Security
»	Introduction to the PEP/SEA proposal
Presentation Overview (2/2)
l	E-Payment Integration
»	Standard interface to payment systems
»	W3C/CommerceNet JEPI effort
»	Extensions to support payments
l	W3C Development Directions
State of Web Security
l	Security Models of HTTP
l	Taxonomy of current proposals
»	Channel Security Approaches
»	Message Security Approaches
»	HTTP Security Approaches
l	W3C Security Goals
l	Introdction to SEA
Security Models of HTTP
l	HTTP has a dual nature as an access protocol and as a message syntax
l	As an “information access protocol”:
»	Akin to SMTP, Telnet, RPC, etc
»	Needs Session-oriented, channel protection
l	As a “message exchange syntax”:
»	Akin to MIME or WAIS/Z39.50
»	Needs Message-oriented protection
Layers of the “Web Stack”
l	Security features have been proposed at each layer of the “Web Stack”
l	Presentation
»	Documents, Programs, Databases
l	Application 
»	HTTP servers, proxies, caches
l	Network
»	Reliable stream connections
Security Approaches at Each Layer
l	Above HTTP: “Secure Content”
»	Protect the documents, databases, etc
l	At HTTP: “Secure Message”
»	Protect the HTTP message units
l	Below HTTP: “Secure Channel”
»	Protect the network connections
“Secure Content”:
Introduction
l	Theme: Use HTTP as an oblivious transport. E.g.:
l	Send protected messages
»	PGP output
»	PKCS-7 (S/MIME, S-HTTP)
»	Other crypto-enhanced data formats
“Secure Content”:
Products & Proposals
l	NCSA’s CCI-based PGP solution
l	PGP protected messages sent to helper application
l	Helper decrypts locally, then remotely controls browser to display result
l	Helper application handles security UI
“Secure Content”:
Evaluation (1/2)
l	Pro: Immediately deployable
»	Uses Helper application or plug-in support to view secure content as a MIME-type
l	Con: Can’t substitute for ‘application layer’ security
»	Can’t authenticate or challenge servers within HTTP
»	Can’t exploit HTTP session properties (session keys, nonces)
“Secure Content”:
Evaluation (2/2)
»	Can’t directly secure other HTTP operations:
–	user authentication
–	protecting URLs from traffic analysis
l	Bottom line: User provides the security features, not the infrastructure
“Secure Channel”:
Introduction
l	Theme: Use HTTP as an oblivious application
l	Protect and authenticate the connection. E.g.:
»	Kerberized Telnet
»	Encrypted TCP/IP tunnels
»	IPsec
“Secure Channel”:
Products & Proposals (1/2)
»	Secure Sockets Layer
–	First out of the blocks; now at v3
–	Initial key-establishment handshake, then an encrypted stream
–	Deployed under several applications: https, snews, etc.
–	Secure Courier development to store SSL sessions
“Secure Channel”:
Products & Proposals (2/2)
»	Private Communication Technology
–	PCT is an SSL-interoperable ‘upgrade’
–	Focuses on “cryptographic hygiene”
»	IPsec, IPv6
–	Next generation IPsec proposal includes support for end-to-end encryption
»	GSSAPI
–	GSS-HTTP proposal to IETF WTS group from TradeWave
–	Initial GSS handshake, then a protected stream
“Secure Channel”:
Evaluation (1/2)
l	Pro: Immediately deployable
»	Slots in below the stream interface of HTTP, and requires no new support from older tools
l	Pro: Widely applicable
»	Provides generic protection to any channel-oriented application
l	Pro: Cryptographically well-understood
»	Proposals have been easily verifiable combinations of algorithms.
“Secure Channel”:
Evaluation (2/2)
l	Con: Can’t distinugish enveloped messages
»	Generally, no way to extract a single message from a stream with authenticity claims intact
l	Con: Can’t change security policy per-message
»	Generally, these proposals do not jump between policies; often, every last byte has to be encrypted.
l	Bottom Line: Network provides the security features, not the user.
“Secure Message”:
Introduction
l	Theme: Upgrade HTTP to a security-aware protocol and syntax. 
l	Protect each protocol message as needed. E.g.:
»	Secure email: MOSS
»	Defense Messaging System
»	DNSsec proposals
“Secure Message”:
Products & Proposals
l	Secure HTTP
»	Proposed June 94, now developed by Terisa
»	Each message can be protected along three axes:
–	Encryption
–	Authentication
–	Signature
»	Replaces HTTP with an S-HTTP enveloping protocol
»	----
»	Based directly upon predecessor secure messaging systems
“Secure Message”:
Evaluation (1/3)
l	Pro: Complete Application Mapping
»	All HTTP properties can be protected: resource names, return status, etc.
l	Pro: Policy adapts to the resource
»	Policies are evaluated for each message
l	Pro: Cryptographically well-understood
»	S-HTTP recapitulates a small set of cryptographically compatible algorithms.
“Secure Message”:
Evaluation (2/3)
l	Pro: Protected messages are separable, archivable
»	Each message completely declares its security attributes for future reference
l	Pro: Security negotiation model
»	For global deployment, it is essential to adapt to available crypto facilities.
“Secure Message”:
Evaluation (3/3)
l	Con: Monolithic implementation
»	The HTTP agent code is impacted throughout
»	S-HTTP cannot be implemented piecemeal
l	Bottom Line: The user sets the security policy, and the infrastructure is empowered  to satisfy it.
W3C Security Goals
l	Integrate security into HTTP
»	Work within standard HTTP, not beside it.
l	Encourage future growth
»	Flexibility in specification and implementation
l	Secure the “Web”
»	More than just HTTP...
Goal:
Integrate Security in HTTP
l	Bind a solution to the HTTP/1.x standards process
l	Not to introduce a new scheme, port, or method set
l	Conversely, not to require crypto features within base HTTP.
Goal:
Encourage Future Growth
l	Make a system flexible in fact and in form instead of just in name
l	A shared software model for security components is one measure of success.
Goal:
Secure the “Web”
l	A complete security solution encompasses more tha HTTP
l	Adding security labels to links and anchors
l	Tying into outside certification and authorization facilities
l	Soon, designing security of the name resolution services
l	...
Introduction to SEA
l	All of this survey culminates in one point: why we are doing PEP/SEA
l	Why Extensions are the heart of our Goals instead of monoliths
l	The risks we aree taking in pioneering a new security vision
SEA Overview
l	First, a few words on PEP
l	Risks of PEP
l	Core SEA classes
l	Future SEA classes
PEP Primer
l	GET /home.html HTTP/1.1
Accept-Protocol: {http:/w3.org/SEA/Signature {str req} {scope origin} {params {key-id “home-server”}}}A protocol is an agreement on the interpretation of a message.
l	A protocol request is addressed at a certain audience with a certain urgency
l	Finally, there’s a syntax for sequencing the application of several protocols.
Using PEP for Security
l	PEP is designed for a wide variety of uses, few of them security-critical
l	There are several risks discussed in the PEP draft
»	If you use a pipeline to connect PEP modules, it must be secure
»	The initial PEP headers are in the clear
l	We believe these issues can all be solved
SEA
l	three modules begin here, one slide each
l	one more slide about how it fits together
PART II: Payments
l	E-Payment Integration
»	Standard interface to payment systems
»	W3C/CommerceNet JEPI effort
»	Extensions to support payments
l	
W3C Development Directions
l	PEP Deployment
l	SEA Module Design
l	Joint Electronic Payment Initiative (with CommerceNet)
l	other areas we may work in
Conclusions
l	The W3C has structure __
l	We are addressing where the Web (& thus, e-commerce) hits security
l	In both areas, we are looking to an extension slot.
l	Join W3C....
For More Information
l	Public Security Resources Page:
»	http:/www.w3.org/pub/WWW/Security
l	ember Working Group Page:
»	http:/www.w3.org/member/WWW/Security/Group
l	ontact the Security & Payments Staff:
»	Jim Miller, <jmiller@w3.org>
»	Rohit Khare, <khare@w3.org>
»	Phillip Hallam-Baker, <hallam@w3.org>