Security Extensions for the Web

Security Extensions for the Web

• Introduction to the W3 Consortium
• W3C Working Groups
  • Web Transaction Security
  • Payment System Interfaces
• W3C Extension Technology
  • HTTP Extension Protocol [PEP]
  • Security Extension Architecture [SEA]

State of Web Security

• Security Models for HTTP
• Taxonomy of current proposals
  • Channel Security Approaches
  • Message Security Approaches
  • HTTP Security Approaches
• W3C Security Goals
• Introdction to SEA

Security Models of HTTP

• HTTP has a dual nature as an access protocol and as a message syntax
• As an information access protocol:
  • Akin to SMTP, Telnet, RPC, etc
  • Needs Session-oriented, channel protection
• As a message exchange syntax:
  • Akin to MIME or WAIS/Z39.50
  • Needs Message-oriented protection

Security Approaches at Each Layer

• Above HTTP: Secure Content
  • Protect the documents, databases, etc
• At HTTP: Secure Message
  • Protect the HTTP message units
• Below HTTP: Secure Channel
  • Protect the network connections

Secure Content (1/3)

• Use HTTP as an oblivious transport
• Send protected objects in clear messages
• NCSA's CCI-based PGP solution
  • PGP protected messages sent to helper application
  • Helper handles decryption, security UI; controls browser to display result

Secure Content (2/3)

• Pro: Immediately deployable
  • Uses Helper application or plug-in support to view secure content as a MIME-type
• 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 (3/3)

• Con: Can't substitute for application layer security
  • Can't directly secure HTTP operations:
    • user authentication
    • protecting URLs from traffic analysis
• Bottom line: User provides the security features, not the infrastructure

Secure Channel (1/4)

• Use HTTP as an oblivious application
• Protect and authenticate the connection
• Secure Sockets Layer
  • Initial key-establishment handshake, then an encrypted stream
  • Secure Courier development to store SSL sessions

Secure Channel (2/4)

• Private Communication Technology
  • Adds cryptographic hygiene to SSL
• IPsec, IPv6
  • Next generation IPsec proposal includes support for end-to-end encryption
• GSSAPI
  • GSS-HTTP proposal to IETF WTS group
  • GSS token exch, then a secure stream

Secure Channel (3/4)

• Pro: Immediately deployable
  • Slots in below the stream interface of HTTP; requires no new support from older tools
• Pro: Widely applicable
  • Security for any channel-oriented app
• Pro: Cryptographically well-understood
  • Proposals have been easily verifiable combinations of algorithms

Secure Channel (4/4)

• Con: Can't distinguish messages
  • Can't extract a single message from a stream with authenticity claims intact
• Con: Can't update security policy
  • Usually set policy per-channel and can't switch it per-message instead
• Bottom Line: Network provides the security features, not the user.

Secure Message (1/4)

• Upgrade HTTP into a security-aware protocol and syntax
• Protect each protocol message
• Secure HTTP
  • Each message can be protected with any combination of three operations
    • Encryption, Authentication, Signature
  • Encapsulates HTTP within secure messages

Secure Message (2/4)

• Pro: Complete Application Mapping
  • All HTTP properties can be protected: resource names, return status, etc.
• Pro: Policy adapts to the resource
  • Policies are evaluated for each message
• Pro: Cryptographically well-understood
  • S-HTTP recapitulates a small set of cryptographically compatible algorithms.

Secure Message (3/4)

• Pro: Protected messages are separable, archivable
  • Each message completely declares its security attributes for future reference
• Pro: Security negotiation model
  • For global deployment, it is essential to adapt to available crypto facilities.

Secure Message (4/4)

• Con: Monolithic implementation
  • The HTTP agent code is impacted throughout
  • S-HTTP cannot be implemented piecemeal
• Bottom Line: The user sets the security policy, and the infrastructure is empowered to satisfy it.

W3C Security Goals

• Integrate security into HTTP
  • Work within HTTP, not beside it.
• Encourage modular growth
  • Flexibility in specification and implementation
• Secure the Web
  • More than just HTTP...

Integrate Security into HTTP

• Design a solution within HTTP/1.x
• Not to introduce a new scheme or port.
• Conversely, not to require crypto features within basic HTTP.

Encourage Modular Growth

• Make a system flexible in fact and in form instead of just in name
• A shared software model for security components will be one measure of success
• The same modular mechanism is used for more than security @@
• Scalable to install: no big-bang

Secure the Web

• A complete security solution encompasses more than HTTP
• Adding security labels to links and anchors and non-HTML resources
• Working with certification and authorization facilities
• Securing UR* name resolution services
• ...

Introduction to SEA

• SEA is a set of modules which extend HTTP/1.x to provide security.
• It has three core protocols:
  • Signature, Encryption, & Key-Exchange
• SEA only focuses on crypto:
  • Negotiation syntax provided by PEP
  • HTML Resource labelling

SEA Overview

• PEP Primer
• Core SEA Protocols
• Future SEA Protocols

PEP Primer

Core SEA Protocols

• Signature
  • nonrepudiable authentication
• Encryption
  • cryptographically secure privacy
• Key-Exchange
  • for secure reference to keys
• A particular protocol, like DES-CFB satisfies the generic Encryption protocol

SEA Recipes

• If every hacker puts a part in the system, there's no security
• Recipes control how pipelines are built
  • limit the order in which each is applied
  • limit the parameter settings
  • limit the number of applications
• Implementations can be much more restricted than the SEA set allows

Additional SEA Protocols

• Clearly, there are other challenges, e.g.:
• Authentication
  • repudiable identification mechanisms
• Key-Assign
  • easier and more efficient key mgmt
• Certificate
  • richer set of usable certificate types

Payment System Integration

• Another hot interface between security infrastructure and the Web
• Protocol Negotiation
  • Selection among payment systems
• Payments within HTTP
  • Standard extensions for embedding payments information within HTTP

W3C Development Directions

• PEP Deployment
• SEA Module Design
• Joint Electronic Payment Initiative (with CommerceNet)
• Ongoing Research
  • Micropayments
  • Web of Trust scaling

Conclusions

• W3C is actively involved in designing Internet security infrastructure
• Today, we are focused on secure messaging and payment systems
• In both areas, we are looking to an extension architecture
• If you are interested, and have the time to work on these issues, contact us...

For More Information

• Public Security Resources Page:
  • http:/www.w3.org/pub/WWW/Security
• Member Working Group Page:
  • http:/www.w3.org/member/WWW/Security/Group
• Contact the Security & Payments Staff:
  • Jim Miller, <jmiller@w3.org>
  • Rohit Khare, <khare@w3.org>
  • Phillip Hallam-Baker, <hallam@w3.org>