TLS Providing Supplemental Data to Applications

1
TLS ProvidingSupplemental Data toApplications

• Russ Housley
• 22 March 2006

2
Concern

• Several proposed TLS extensions are being defined
  that provide supplemental information to the
  application
• draft-santesson-tls-ume
• draft-housley-tls-authz-extns
• We must assume that other are coming

3
Proposal

• Independent extensions will be used to determine
  what data appears in the handshake protocol
  message
• Place all of the data that will be passed to the
  application in a single handshake protocol
  message
• Types will allow data associated with more than
  one extension to appear in the handshake message
  without confusion

4
Proposed Handshake Syntax

• enum
• hello_request(0), client_hello(1),
  server_hello(2), certificate(11),
• server_key_exchange (12),
  certificate_request(13), server_hello_done(14),
• certificate_verify(15),
  client_key_exchange(16), finished(20),
• certificate_url(21), certificate_status(
  22), supplemental_data(TBD), (255)
• HandshakeType
• struct
• HandshakeType msg_type / handshake
  type /
• uint24 length / octets in
  message /
• select (HandshakeType)
• case hello_request
  HelloRequest
• case client_hello
  ClientHello
• case server_hello
  ServerHello
• case certificate
  Certificate
• case server_key_exchange
  ServerKeyExchange
• case certificate_request
  CertificateRequest
• case server_hello_done
  ServerHelloDone
• case certificate_verify
  CertificateVerify

5
Supplemental Data Syntax

• enum
• authz_data(TBD),
• user_mapping_data(TBD), (65535)
• SupplementalDataType
• struct
• SupplementalDataType supp_data_type
• select(SupplementalDataType)
• case authz_data
  AuthorizationData
• case user_mapping_data UpnDomainHint
• SupplementalDataEntry
• struct
• SupplementalDataEntry supp_datalt1..224-1gt
  
• SupplementalData

6
Proposed IANA Considerations

• IANA needs to establish a registry for TLS
  Supplemental Data Formats. TLS Authorization
  Data Format identifiers with values in the
  inclusive range 0-16385 (decimal) are assigned
  via RFC 2434 IANA Standards Action. Values
  from the inclusive range 16385-65279 (decimal)
  are assigned via RFC 2434 Specification Required.
  Values from the inclusive range 65280-65535
  (decimal) are reserved for RFC 2434 Private Use.

7
Way Forward

• I believe that this proposal resolves the IETF
  Last Call comments from Eric Rescorla on
  draft-santesson-tls-ume
• If the TLS WG likes this approach, action is
  needed immediately
• Write full draft
• Extend IETF Last Call on draft-santesson-tls-ume
  plus the new document
• Assuming no issues, IESG two document ballot