Network Working Group Jonathan Trostle INTERNET-DRAFT Cisco Systems Mike Swift University of WA The Secure Lightweight Authentication Mechanism (SLAM) 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 March 30th, 2002. Please send comments to the authors. 1. Abstract We specify a new authentication and key establishment protocol. The Secure Lightweight Authentication Mechanism (SLAM) allows network entities to mutually authenticate and establish shared secret keys for protection of application data. We specify confidential and integrity protected messages for application level security (e.g. GSS-API protected messages). This proposal is based on an earlier version of lightweight Kerberos. 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 with fewer and smaller messages than the Kerberos protocol. The protocol only requires two messages to be sent and received from the client, to support lightweight clients. The protocol described does not use ASN.1 and has a reduced set of Trostle, Swift [Page 1] INTERNET DRAFT October 2001 Expires April 2002 options. 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]. 3. Protocol Overview We specify a new mutual authentication and key establishment protocol: SLAM. The design goals of the SLAM protocol include simplicity and minimizing the number of messages that are exchanged between two peers. Secondary goals include reduced processing load on the server and minimizing the number of bytes that must be exchanged prior to key establishment. The base protocol uses symmetric key cryptography; this protocol is based on an earlier version of lightweight Kerberos. We reuse the ticket and authenticator concepts from Kerberos [3]. We define a new exchange that does not have a Kerberos analog: the passthrough exchange. By using this option, the client does not have to contact the SLAM-KDC at all (subsequent to obtaining its initial TGT). The passthrough option is valuable in environments where the client must minimize the messages it sends. To initiate it, the client sends an AP request to the application server, but the ticket in the AP request is either an initial ticket or a crossrealm KDC ticket. The application server creates the passthrough message (PA- MSG) by including the received AP request message and its own TGT and sending it to its local KDC. The local KDC, in case it cannot decrypt the AP request, 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 AP request, 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 passthrough message back to the previous KDC. The current proposal can be integrated with an existing Kerberos infrastructure: the client may obtain tickets using conventional Kerberos exchanges with a KDC that also hosts the SLAM-KDC component. The client indicates its desire to obtain a ticket, in addition to a conventional Kerberos ticket, by including a padata type in the KDC request message. The KDC returns the ticket in a padata field of the KDC reply message. The specification of these padata types will be in a separate document. Subsequent exchanges between the client and application server can use the SLAM AP request and SLAM AP reply messages in place of the Kerberos AP exchange. The advantage here is reduced processing and much smaller messages in the client server exchange. Trostle, Swift [Page 2] INTERNET DRAFT October 2001 Expires April 2002 We define the SLAM ticket, SLAM authenticator, and message constructs. We use the notation of TLS [5]. For the purposes of this document, ticket means SLAM ticket, and authenticator means SLAM authenticator. 4. Protocol Constructs We define ap-req and ap-rep messages that are sent by the initiator and responder, respectively. The ap-rep is only sent by the target if the initiator has set the MUTUAL-AUTH flag. All fields are encoded in network or big endian order. ap-req = { // version number will match tkt vno. uint16 message type // equals 10 ticket ap-ticket authenticator ap-authenticator // authenticator is unencrypted mic hmac-sha1 hash using session key // consider other hash functions } ap-reply = { uint16 version number // equals 6 uint16 message type // equals 11 uint16 extensions field length extfield extensions field ap-replypart replypart // replypart is unencrypted. mic hmac-sha1 hash using session key } ap-replypart = { uint64 sequence number // is the length correct? nonce key-nonce uint40 time0 // UNIX GMT time: seconds since // Jan. 1 1970, midnight: 40 bits // to accomodate dates past 2037. // NEED TO fix the time fields: see TLS spec. uint32 nonce } ticket = { uint16 version number // equals 6 namestring server name // not present in srv ticket // see below namestring server realm // not present in srv ticket // other fields will be added here uint16 extensions field length extfield extensions field encryptedpart encticket Trostle, Swift [Page 3] INTERNET DRAFT October 2001 Expires April 2002 } encticket = { namestring client name namestring client realm key session key uint40 logon time // not present in srv ticket uint40 expiration time uint40 renew time // not present in srv ticket } namestring = { uint16 name length // including length and type fields uint16 name type // see below string name // encoding depends on name type } // Mike Swift's comment goes here extfield = { uint16 type0 uint16 length0 uchar[length0] data0 uint16 type1 uint16 length1 uchar[length1] data1 ... } The least significant bit of the type field indicates the criticality of the extension type. If the least significant bit equals 1, then the type is critical (a recipient must reject a message with a critical type - using an error message with code UNRECOGNIZED_CRITICAL_TYPE). If the least significant bit equals 0, then the extension type is not critical, and a recipient that does not understand such a type may ignore it and continue processing the received message. authenticator = { // version number matches ticket vno uint64 sequence number // is the length correct? nonce key-nonce uint40 time0 uint32 nonce uint16 extensions field length extfield extensions field } The authenticator is encrypted using the session key from the ticket. Extension types 1-31 are reserved. We define the following extension field types for an authenticator: Trostle, Swift [Page 4] INTERNET DRAFT October 2001 Expires April 2002 // This type is likely to be placed into a separate document: extension field type: 33 extension field type 33 length: 4 (bytes) extension field type 33 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. 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 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 passthrough message is returned through multiple KDC's. In the passthrough option, the following ticket extension is placed into the ticket in the ap-req by the user's KDC (the home KDC): extension field type: 37 extension field data: the following servicetkt-skey structure The servicetkt-skey structure is: servicetkt-skey = { encryptedpart encsrvtktskey // encrypted in the TGT skey } encsrvtktskey = { key local realm session key } The structure is removed from the ap-req and placed into the the ap- reply by the responder. The responder then sends the ap-reply to the initiator. The following extension is placed into the ap-req ticket extensions field by the responder's KDC (the local KDC): extension field type: 39 extension field data: the following enckdcreppart structure Trostle, Swift [Page 5] INTERNET DRAFT October 2001 Expires April 2002 enckdcreppart = { encryptedpart local-kdc-rep-body // encrypted in // local realm skey } 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 key service tkt session key } This extension is removed from the ap-req message and then placed in the ap-reply extensions field by the responder. The responder then sends the ap-reply to the 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 } We also define the following message that does not have a Kerberos analog; this message is used for the passthrough option: pass-req = { client-ap-req ap-req // using client TGT or client // xrealm TGT srv-ticket ticket // server or KDC ptkt // NOTE: the srv-ticket may be replaced with a server ap-req. The // advantage of including the ap-req is that it allows replay // detection and an additional means of detecting loss of // synchronization. No final decision on this yet. } Upon receiving such a message, a 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 ticket. The ticket is also decrypted, and the expiration is checked. The KDC MAY NOT validate the time fields in the authenticator to check for replays. Trostle, Swift [Page 6] INTERNET DRAFT October 2001 Expires April 2002 NOTE: it is not wrong to validate the time fields - this validation allows for improved replay detection. Need to decide whether any replay detection is required here. If all goes well, the KDC will re-encrypt the ticket using the session key from the ticket in the passthrough message and send the passthrough message back to the entity it received it from. If the ap-req is not targetted at the current KDC, then the KDC forwards it to the next KDC after replacing the ticket with its own primary ticket targetted at the next KDC. The old ticket is cached and used when the KDC receives the passthrough message back from the next KDC. ErrorMessage = { uint16 error code uint16 extensions field length extfield extensions field } The following error codes are defined: apreq-err-bad-integrity 1 apreq-err-tkt-expired 2 apreq-err-repeat 3 apreq-err-not-us 4 apreq-err-clockskew 5 Further error codes will also be defined. // see 39-50, and 60. 3.1 Initial Exchange The initial exchange is comprised of an init-req message and an init-rep message. The goal of this exchange is to obtain a primary ticket (pticket) or other ticket. It is possible to use another authentication/key management protocol to obtain a shared secret session key that can be used to encrypt the body of the init-rep message in which case the init-req message would not be needed. init-req = { uint16 version number // equals 6 uint16 message type // equals 14 namestring client name namestring client realm namestring server name uint40 time0 uint32 nonce uint64 nonce uint16 extensions field length extfield extensions field // other fields will be added here } Trostle, Swift [Page 7] INTERNET DRAFT October 2001 Expires April 2002 init-rep = { uint16 version number // equals 6 uint16 message type // equals 14 namestring client name namestring client realm namestring server name encryptedpart encreplypart uint16 extensions field length extfield extensions field // other fields to be added here } encreplypart = { key session key namestring server name uint40 server time uint64 nonce // copy of request nonce uint40 expiration time uint16 extensions field length extfield extensions field } 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 8] INTERNET DRAFT October 2001 Expires April 2002 8. Expiration Date This draft expires on April 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 9]