Network Working Group Jonathan Trostle INTERNET-DRAFT Cisco Systems Mike Swift University of WA The Lightweight Kerberos Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [6]. 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. This draft expires on November 30th, 2001. Please send comments to the authors. 1. Abstract The Kerberos V5 protocol [3] allows network entities to authenticate and establish shared secret keys. Some network applications would benefit from a lightweight authentication mechanism with many of the benefits of Kerberos, but where the messages have fewer bytes than existing Kerberos messages. Also, we describe a protocol option that requires only two messages to be sent and received from the client, to support lightweight clients. This document describes a Kerberos- like protocol that does not use ASN.1 and is optimized for smaller messages. The protocol makes use of existing Kerberos infrastructure. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2]. Trostle, Swift [Page 1] INTERNET DRAFT May 2001 Expires November 2001 3. Protocol Overview We define lw-ticket, lw-authenticator, and message constructs. We use the notation of TLS [5]. The current proposal does not eliminate the RFC 1510 Kerberos libraries from the client. The client obtains lw-tickets using conventional Kerberos exchanges with a KDC that also hosts the lw-KDC component. The client indicates its desire to obtain a lw-ticket, in addition to a conventional Kerberos ticket, by including a padata type in the KDC request message. The KDC returns the lw-ticket in a padata field of the KDC reply message. Subsequent exchanges between the client and application server can use the lw-ap-req and lw-ap-rep messages in place of the Kerberos AP exchange. The advantage here is reduced processing and much smaller messages in the client server exchange. Our initial estimate is that there is approximately a 50% reduction in size of messages. In addition, we define a new message that does not have a Kerberos analog: the lw-passthrough message. By using this option, the client does not have to contact the KDC at all (subsequent to obtaining its initial TGT). The lw passthrough option is valuable in environments where the client must minimize the messages it sends. To initiate it, the client sends a lw-ap-req to the application server, but the ticket in the lw-ap-req is either a TGT or a crossrealm TGT. The application server creates the lw-passthrough message by including the received lw-ap-req message and its own TGT and sending it to its local KDC. The local KDC, in case it cannot decrypt the lw-ap-req, then forwards it on to the next KDC, after replacing the ticket with its own crossrealm ticket targetted at the next KDC. If the next KDC can decrypt the lw-ap-req, it validates it (except for authenticator time fields), and then re-encrypts the ticket with the session key from the accompanying ticket. It then sends the lw- passthrough message back to the previous KDC. 4. Protocol Constructs We define lw-ap-req and lw-ap-rep messages that are sent by the initiator and responder, respectively. The lw-ap-rep is only sent by the target if the initiator has set the MUTUAL-AUTH flag. lw-ap-req = { // version number will match tkt vno. uint16 message type lw-ticket ticket lw-authenticator authenticator } lw-ap-reply = { uint16 version number uint16 message type uint16 extensions field length extfield extensions field Trostle, Swift [Page 2] INTERNET DRAFT May 2001 Expires November 2001 encryptedpart lw-encreplypart } lw-encreplypart = { key subkey uint64 sequence number uint32 time0 uint32 time1 } lw-ticket = { uint16 version number namestring server name // not present in service ticket // UTF-8 encoding namestring server realm uint16 extensions field length extfield extensions field encryptedpart encticket } encticket = { namestring client name namestring client realm key session key uint32 logon time // not present in service ticket uint32 expiration time uint32 renew time // not present in service ticket } namestring = { uint16 name length string name // UTF-8 encoding } extfield = { uint16 type0 uint16 length0 uchar[length0] data0 uint16 type1 uint16 length1 uchar[length1] data1 ... } lw-authenticator = { // version number matches ticket vno uint32 time0 uint32 time1 key subkey uint64 sequence number uint16 extensions field length extfield extensions field } The lw-authenticator is encrypted using the session key from the Trostle, Swift [Page 3] INTERNET DRAFT May 2001 Expires November 2001 ticket. Extension types 1-31 are reserved. We define the following extension field types for an authenticator: extension field type: 32 extension field type 32 length: 4 (bytes) extension field type 32 data: context establishment flags bit vector (as in [4]): Delegation flag 1 Mutual flag 2 Replay flag 4 Sequence flag 8 Confidentiality flag 16 Integrity flag 32 The bit vector is encoded in little-endian form. If this extension type is not present, then it is the same as sending type 32 with all of the above six bits set (delegation, mutual, replay, sequence, confidentiality, and integrity). We define the following extension field types for a ticket: extension field type: 35 extension field length: 8 bytes extension field data: both time fields from the authenticator. This extension is used in the lw-passthrough message to allow an application server to quickly reject a message that is a replay or a clock skew error. Alternatively, the application server will learn about this problem after the lw-passthrough message is returned through multiple KDC's. In the lwkerb passthrough option, the following ticket extension is placed into the ticket in the lw-ap-req by the user's KDC (the home KDC): extension field type: 36 extension field data: the following servicetkt-skey structure The servicetkt-skey structure is: servicetkt-skey = { encryptedpart encsrvtktskey // encrypted in the TGT skey } encsrvtktskey = { key service tkt session key } The structure is removed from the lw-ap-req and placed into the the lw-ap-reply by the lwkerb responder. The responder then sends the lw-ap-reply to the lwkerb initiator. The following extension is placed into the lw-ap-req ticket Trostle, Swift [Page 4] INTERNET DRAFT May 2001 Expires November 2001 extensions field by the lwkerb responder's KDC (the local KDC): extension field type: 37 extension field data: the following enckdcreppart structure enckdcreppart = { encryptedpart local-kdc-rep-body // encrypted in srvtktskey } local-kdc-rep-body = { namestring server name // UTF-8 encoding namestring server realm // UTF-8 encoding uint32 expiration time // could add to servicetkt-skey too } This extension is removed from the lw-ap-req message and then placed in the lw-ap-reply extensions field by the lwkerb responder. The responder then sends the lw-ap-reply to the lwkerb initiator. Here we define the key and encryptedpart structures: key = { uint16 keytype uint16 length uchar[length] keyvalue } encryptedpart = { uint16 etype uint16 keyversion uint16 length uchar[length] ciphertext // define ciphertext for RC4, // AES etypes } The encryption type is derived from the Kerberos encryption type. We also define the following message that does not have a Kerberos analog; this message is used for the lwkerb passthrough option: lw-passthrough = { ap-req lw-ap-req // using client TGT or client // xrealm TGT ticket lw-ticket // server or KDC lw-tgt } Upon receiving such a message, a lw-KDC will check if the ap-req is targetted at itself. If so, it will validate that the authenticator in the ap-req decrypts successfully using the session key from the lw-ticket. The ticket is also decrypted, and the expiration is checked. The lw-KDC will NOT validate the time fields in the authenticator to check for replays. If all goes well, the lw-KDC will re-encrypt the ticket using the session key from the ticket in the lw-passthrough message and send the lw-passthrough message back to Trostle, Swift [Page 5] INTERNET DRAFT May 2001 Expires November 2001 the entity it received it from. If the ap-req is not targetted at the current lw-KDC, then the lw-KDC forwards it to the next lw-KDC after replacing the ticket with its own lw-tgt targetted at the next KDC. The old ticket is cached and used when the lw-KDC receives the lw-passthrough message back from the next KDC. ErrorMessage = { uint16 error code uint16 extensions field length extfield extensions field } The following error codes are reused from [3]: lwapreqerr-bad-integrity 31 lwapreqerr-tkt-expired 32 lwapreqerr-repeat 34 lwapreqerr-not-us 35 lwapreqerr-badmatch 36 lwapreqerr-skew 37 along with errors 39-50, and 60 from [3]. 5. Acknowledgements The authors thank Doug Engert and Hannes Tschofenig for their feedback on this document. 6. Security Considerations The entire draft discusses security. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5), Request for Comments 1510. [4] Linn, J., "The Kerberos V5 GSSAPI Mechanism", RFC 1964. [5] Dierks T., Allen C. "The TLS Protocol, Version 1.0", RFC 2246. Trostle, Swift [Page 6] INTERNET DRAFT May 2001 Expires November 2001 8. Expiration Date This draft expires on November 30th, 2001. 9. Authors' Addresses Jonathan Trostle Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: jtrostle@cisco.com Mike Swift University of Washington Seattle, WA Email: mikesw@cs.washington.edu 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Trostle, Swift [Page 7]