Mark Brown RedPhone Security Transport Layer Security (TLS) Authorization Extensions <draft-housley-tls-authz-extns-01.txt> Mark Brown RedPhone Security Russ Housley Vigil Security
Overview (1 of 2) Authorization extensions for the Handshake Protocol in both TLS 1.0 and TLS 1.1 Allow client to provide authorization information to the server Allow server to provide authorization information to the client
Overview (2 of 2) Client Server ClientHello (with AuthorizationData) --------> ServerHello (with AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> <-------- Finished Application Data <-------> Application Data
Two Authorization Formats enum { x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), saml_assertion_url(3), (255) } AuthzDataFormat; X.509 Attribute Certificate SAML Assertion URL to fetch either of these, with a hash value to ensure that the correct object was obtained
AuthorizationData (1 of 2) struct { AuthorizationDataEntry authz_data_list<1..2^16-1>; } AuthorizationData; AuthzDataFormat authz_format; select (authz_format) { case x509_attr_cert: X509AttrCert; case saml_assertion: SAMLAssertion; case x509_attr_cert_url: URLandHash; case saml_assertion_url: URLandHash; } authz_data_entry; } AuthorizationDataEntry;
AuthorizationData (2 of 2) opaque X509AttrCert<1..2^16-1>; opaque SAMLAssertion<1..2^16-1>; struct { opaque url<1..2^16-1>; HashType hash_type; select (hash_type) { case sha1: SHA1Hash; case sha256: SHA256Hash; } hash; } URLandHash; enum { sha1(0), sha256(1), (255) } HashType;
Sensitive Authorization Information Solved by double handshake Client Server ClientHello (no AuthorizationData) --------> ServerHello (no AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> <-------- Finished (more on next slide)
The rest of the double handshake Client Server ClientHello (with AuthorizationData) --------> ServerHello (with AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> <-------- Finished Application Data <-------> Application Data
More efficient with resumption Client Server ClientHello (no AuthorizationData) --------> ServerHello (no AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> <-------- Finished (with AuthorizationData) --------> (with AuthorizationData Application Data <-------> Application Data
Open Issue Need to allow an empty AuthorizationData extension Client wants authorization information from the server, so it needs to include the extension in the client hello message Server wants to indicate that the authorization information provided by the client was accepted, but the server has none to provide
Way Forward Should this become a TLS WG document? If not, will proceed as standards-track individual submission