doc/protocol/draft-keromytis-tls-authz-keynote-00.txt

   1 Internet-Draft                                           A. D. Keromytis
   2 March 2008                                           Columbia University
   3 Expires: October 2008
   4 Creation Date: 2008-03-28
   5 Intended Status: Proposed
   6
   7
   8         Transport Layer Security (TLS) Authorization Using KeyNote
   9                  <draft-keromytis-tls-authz-keynote-00.txt>
  10
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six
  25    months and may be updated, replaced, or obsoleted by other
  26    documents at any time.  It is inappropriate to use Internet-Drafts
  27    as reference material or to cite them other than as "work in
  28    progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The IETF Trust (2008).
  39
  40 Abstract
  41
  42    This document specifies the use of the KeyNote trust-management
  43    system as an authorization extension in the Transport Layer
  44    Security (TLS) Handshake Protocol, according to [AUTHZ].
  45    Extensions carried in the client and server hello messages
  46    confirm that both parties support the desired authorization
  47    data types. Then, if supported by both the client and the
  48    server, KeyNote credentials are exchanged during the
  49    supplemental data handshake message.
  50
  51
  52 1. Introduction
  53
  54    This document describes the identifiers necessary to exchange
  55    KeyNote [KEYNOTE] credential assertions inside a TLS [TLS1.0]
  56    [TLS1.1] exchange.  Such credential assertions can authorize
  57    the client and/or the server to perform certain actions. In
  58    most usage scenarios, the KeyNote credential assertions will
  59    be signed by a cryptographic public key [RFC2792].  By using the
  60    X.509 key and signature encoding [X509KEY], it is possible to
  61    add KeyNote-based authorization and policy compliance support to
  62    the existing, unmodified X.509 authentication exchange in TLS.
  63
  64    A list of KeyNote credentials (e.g., forming a delegation chain)
  65    may be sent as part of the same payload.
  66
  67    In most scenarios, at least one of these credentials will be
  68    issued to the public key of the transmitter of the credentials,
  69    i.e., said public key will appear in the ``Licensees'' field of
  70    at least one KeyNote credential assertion.  The same public key
  71    will generally be used by the transmitter of the same credentials
  72    to authenticate as part of the TLS exchange.  The
  73    authentication material (e.g., cryptographic public key) that was
  74    used by the transmitter to authenticate in the TLS exchange will
  75    be provided to the KeyNote evaluation engine as an ``Action
  76    Authorizer''.
  77
  78
  79 2. KeyNote Credential Assertion Lists
  80
  81   The KeyNote Assertion List type definition in the TLS Authorization
  82   Data Formats registry is:
  83
  84       keynote_assertion_list(TBA)
  85
  86    When the keynote_assertion_list value is present, the authorization
  87    data is a list of KeyNote credential assertions that conforms to
  88    the profile in RFC 2704 [KEYNOTE].
  89
  90    A KeyNote assertion list is transmitted inside an AuthorizationData
  91    structure as an opaque sequence of 1 - 2^16-1 bytes:
  92
  93       opaque KeyNoteAssertionList<1..2^16-1>;
  94
  95    When KeyNoteAssertion List is used, the field contains an ASCII-
  96    encoded list of signed KeyNote assertions, as described in RFC 2704
  97    [KEYNOTE].  The assertions are separated by two '\n' (newline)
  98    characters.  A KeyNote assertion is a structure similar to a public
  99    key certificate; the main difference is that instead of a binding
 100    between a name and a public key, KeyNote assertions bind public keys
 101    to authorization rules that are evaluated by the peer when the sender
 102    later issues specific requests.
 103
 104    When making an authorization decision based on a list of KeyNote
 105    assertions, proper linkage between the KeyNote assertions and the
 106    public key certificate that is transferred in the TLS Certificate
 107    message is needed.  Receivers of a KeyNote assertion list should
 108    initialize the ACTION_AUTHORIZER variable to be the sender's public
 109    key, which was used to authenticate the TLS exchange.  If a
 110    different authentication mechanism is used, it is the responsibility
 111    of the credential issuer to issue the appropriate credentials.
 112
 113
 114 3. IANA Considerations
 115
 116    This document requires a new entry in the IANA-maintained TLS
 117    Authorization Data Formats registry, keynote_assertion_list(TBD).
 118    This registry is defined in [AUTHZ].
 119
 120
 121 4. Security Considerations
 122
 123    There are no security considerations beyond those discussed in
 124    [KEYNOTE], [RFC2792], and [AUTHZ].
 125
 126
 127 5. Normative References
 128
 129    [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
 130                 an IANA Considerations Section in RFCs", RFC 3434,
 131                 October 1998.
 132
 133    [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version
 134                 1.0", RFC 2246, January 1999.
 135
 136    [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer
 137                 Security (TLS) Protocol, Version 1.1", RFC 4346,
 138                 February 2006.
 139
 140
 141 6. Informative References
 142
 143    [KEYNOTE]    Blaze, M., Feigenbaum, J., Ioannidis, J., and
 144                 A. Keromytis, "The KeyNote Trust-Management System,
 145                 Version 2", RFC 2704, September 1999.
 146
 147    [RFC2792]    Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA
 148                 Key and Signature Encoding for the KeyNote Trust
 149                 Management System", RFC 2792, March 2000.
 150
 151    [AUTHZ]      Brown, M., and R. Housley, "Transport Layer Security
 152                 (TLS) Authorization Extensions", June 2006
 153                 <draft-housley-tls-authz-extns-07.txt>
 154
 155    [X509KEY]    A. D. Keromytis, "X.509 Key and Signature Encoding for
 156                 the KeyNote Trust Management System", March 2008
 157                 <draft-keromytis-keynote-x509-00.txt>
 158
 159
 160 Author's Address
 161
 162    Angelos D. Keromytis
 163    Department of Computer Science
 164    Columbia University
 165    Mail Code 0401
 166    1214 Amsterdam Avenue
 167    New York, New York 1007
 168    USA
 169    angelos <at> cs <dot> columbia <dot> edu
 170
 171
 172 Full Copyright Statement
 173
 174    Copyright (C) The IETF Trust (2008).
 175
 176    This document is subject to the rights, licenses and restrictions
 177    contained in BCP 78, and except as set forth therein, the authors
 178    retain all their rights.
 179
 180    This document and the information contained herein are provided on an
 181    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 182    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 183    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 184    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 185    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 186    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 187
 188 Intellectual Property
 189
 190    The IETF takes no position regarding the validity or scope of any
 191    Intellectual Property Rights or other rights that might be claimed to
 192    pertain to the implementation or use of the technology described in
 193    this document or the extent to which any license under such rights
 194    might or might not be available; nor does it represent that it has
 195    made any independent effort to identify any such rights.  Information
 196    on the procedures with respect to rights in RFC documents can be
 197    found in BCP 78 and BCP 79.
 198
 199    Copies of IPR disclosures made to the IETF Secretariat and any
 200    assurances of licenses to be made available, or the result of an
 201    attempt made to obtain a general license or permission for the use of
 202    such proprietary rights by implementers or users of this
 203    specification can be obtained from the IETF on-line IPR repository at
 204    http://www.ietf.org/ipr.
 205
 206    The IETF invites any interested party to bring to its attention any
 207    copyrights, patents or patent applications, or other proprietary
 208    rights that may cover technology that may be required to implement
 209    this standard.  Please address the information to the IETF at
 210    ietf-ipr@ietf.org.