110 likes | 251 Vues
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
E N D
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) ClientServer ClientHello (with AuthorizationData) --------> ServerHello (with AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- 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; struct { 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 ClientServer ClientHello (no AuthorizationData) --------> ServerHello (no AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished (more on next slide)
The rest of the double handshake ClientServer ClientHello (with AuthorizationData) --------> ServerHello (with AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
More efficient with resumption ClientServer ClientHello (no AuthorizationData) --------> ServerHello (no AuthorizationData) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished ClientHello (with AuthorizationData) --------> ServerHello (with AuthorizationData [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> 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