diff options
author | Simon Josefsson <simon@josefsson.org> | 2008-04-03 09:40:01 +0200 |
---|---|---|
committer | Simon Josefsson <simon@josefsson.org> | 2008-04-03 09:40:01 +0200 |
commit | 117152d4c91e1c01055eedada1412ec763e5196b (patch) | |
tree | d61edcd1584f3a6c97383b80c9523da19a9d6dd9 | |
parent | c3049c362277d91e5dc8a475fc0d4973b790803c (diff) | |
download | gnutls-117152d4c91e1c01055eedada1412ec763e5196b.tar.gz |
Add.
-rw-r--r-- | doc/protocol/draft-keromytis-tls-authz-keynote-00.txt | 210 |
1 files changed, 210 insertions, 0 deletions
diff --git a/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt b/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt new file mode 100644 index 0000000000..14479ad944 --- /dev/null +++ b/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt @@ -0,0 +1,210 @@ +Internet-Draft A. D. Keromytis +March 2008 Columbia University +Expires: October 2008 +Creation Date: 2008-03-28 +Intended Status: Proposed + + + Transport Layer Security (TLS) Authorization Using KeyNote + <draft-keromytis-tls-authz-keynote-00.txt> + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + This document specifies the use of the KeyNote trust-management + system as an authorization extension in the Transport Layer + Security (TLS) Handshake Protocol, according to [AUTHZ]. + Extensions carried in the client and server hello messages + confirm that both parties support the desired authorization + data types. Then, if supported by both the client and the + server, KeyNote credentials are exchanged during the + supplemental data handshake message. + + +1. Introduction + + This document describes the identifiers necessary to exchange + KeyNote [KEYNOTE] credential assertions inside a TLS [TLS1.0] + [TLS1.1] exchange. Such credential assertions can authorize + the client and/or the server to perform certain actions. In + most usage scenarios, the KeyNote credential assertions will + be signed by a cryptographic public key [RFC2792]. By using the + X.509 key and signature encoding [X509KEY], it is possible to + add KeyNote-based authorization and policy compliance support to + the existing, unmodified X.509 authentication exchange in TLS. + + A list of KeyNote credentials (e.g., forming a delegation chain) + may be sent as part of the same payload. + + In most scenarios, at least one of these credentials will be + issued to the public key of the transmitter of the credentials, + i.e., said public key will appear in the ``Licensees'' field of + at least one KeyNote credential assertion. The same public key + will generally be used by the transmitter of the same credentials + to authenticate as part of the TLS exchange. The + authentication material (e.g., cryptographic public key) that was + used by the transmitter to authenticate in the TLS exchange will + be provided to the KeyNote evaluation engine as an ``Action + Authorizer''. + + +2. KeyNote Credential Assertion Lists + + The KeyNote Assertion List type definition in the TLS Authorization + Data Formats registry is: + + keynote_assertion_list(TBA) + + When the keynote_assertion_list value is present, the authorization + data is a list of KeyNote credential assertions that conforms to + the profile in RFC 2704 [KEYNOTE]. + + A KeyNote assertion list is transmitted inside an AuthorizationData + structure as an opaque sequence of 1 - 2^16-1 bytes: + + opaque KeyNoteAssertionList<1..2^16-1>; + + When KeyNoteAssertion List is used, the field contains an ASCII- + encoded list of signed KeyNote assertions, as described in RFC 2704 + [KEYNOTE]. The assertions are separated by two '\n' (newline) + characters. A KeyNote assertion is a structure similar to a public + key certificate; the main difference is that instead of a binding + between a name and a public key, KeyNote assertions bind public keys + to authorization rules that are evaluated by the peer when the sender + later issues specific requests. + + When making an authorization decision based on a list of KeyNote + assertions, proper linkage between the KeyNote assertions and the + public key certificate that is transferred in the TLS Certificate + message is needed. Receivers of a KeyNote assertion list should + initialize the ACTION_AUTHORIZER variable to be the sender's public + key, which was used to authenticate the TLS exchange. If a + different authentication mechanism is used, it is the responsibility + of the credential issuer to issue the appropriate credentials. + + +3. IANA Considerations + + This document requires a new entry in the IANA-maintained TLS + Authorization Data Formats registry, keynote_assertion_list(TBD). + This registry is defined in [AUTHZ]. + + +4. Security Considerations + + There are no security considerations beyond those discussed in + [KEYNOTE], [RFC2792], and [AUTHZ]. + + +5. Normative References + + [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", RFC 3434, + October 1998. + + [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version + 1.0", RFC 2246, January 1999. + + [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer + Security (TLS) Protocol, Version 1.1", RFC 4346, + February 2006. + + +6. Informative References + + [KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and + A. Keromytis, "The KeyNote Trust-Management System, + Version 2", RFC 2704, September 1999. + + [RFC2792] Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA + Key and Signature Encoding for the KeyNote Trust + Management System", RFC 2792, March 2000. + + [AUTHZ] Brown, M., and R. Housley, "Transport Layer Security + (TLS) Authorization Extensions", June 2006 + <draft-housley-tls-authz-extns-07.txt> + + [X509KEY] A. D. Keromytis, "X.509 Key and Signature Encoding for + the KeyNote Trust Management System", March 2008 + <draft-keromytis-keynote-x509-00.txt> + + +Author's Address + + Angelos D. Keromytis + Department of Computer Science + Columbia University + Mail Code 0401 + 1214 Amsterdam Avenue + New York, New York 1007 + USA + angelos <at> cs <dot> columbia <dot> edu + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. |