INTERNET-DRAFT Stuart Kwan Praerit Garg Ram Viswanathan Microsoft Corp. November 1997 Expires May 1998 GSS Algorithm for TSIG (GSS-TSIG) Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2078]. Expires May 1998 [Page 1] INTERNET-DRAFT GSS-TSIG November 1997 Table of Contents 1: Introduction......................................................2 2: Record Format for GSS-API Algorithm...............................3 3: Overall Protocol Comments.........................................3 4: Client Protocol Details...........................................4 4.1: Negotiate Security Context......................................4 4.1.1: Continue Negotiation..........................................4 4.1.2: Negotiation Complete..........................................5 4.2: Send Signed Request.............................................5 4.3: Verify Signed Response..........................................6 4.4: Fatal Context Error Response....................................6 5: Server Protocol Details...........................................7 5.1: Process Message.................................................7 5.2: Negotiate Security Context......................................8 5.2.1: Continue Negotiation..........................................8 5.2.2: Negotiation Complete..........................................8 5.3: Verify Signed Request...........................................9 5.4: Send Signed Response............................................9 5.5: Send Fatal Context Error Response..............................10 6: Security Considerations..........................................10 7: Acknowledgements.................................................11 8: References.......................................................11 9: Author's Addresses...............................................11 1. Introduction The Secret Key Transaction Signature for DNS [TSIG] protocol was developed to provide a lightweight alternative to full DNS security [RFC2065] and secure dynamic update [RFC2137], where full security is impractical due to implementation complexity, management overhead, or computation cost. The [TSIG] protocol is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2078]. GSS-API is a framework that provides an abstraction of security to the application protocol developer. The security services offered can include authentication, integrity, and confidentiality. The GSS-API framework has several benefits: * Mechanism and protocol independence. The underlying mechanisms that realize the security services can be negotiated on the fly and varied over time. For example, a client and server may use Kerberos for one transaction, whereas that same server may use TLS with a different client. Expires May 1998 [Page 2] INTERNET-DRAFT GSS-TSIG November 1997 * The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the developer does not need to create new key distribution or key management systems. Instead the developer relies on the security service mechanism to manage this on its behalf. GSS-API is not suitable as a comprehensive security mechanism for all DNS operations. Complete DNS security is addressed by [RFC2065]. The GSS-API algorithm is suitable for the scenarios outlined in [TSIG]. 2. Record Format for GSS-API Algorithm The format of the TSIG record is specified in [TSIG]. The algorithm name is TBD. When using this algorithm, the Signature field is divided up into several sub-fields: Sub-Field Name Data Type Description ---------------------------------------------------------------- Context ID u_int32_t Uniquely identifies context Control Flags u_int32_t Flags to control context GSS_Token Size u_int16_t Size of token if included GSS_Signature Size u_int16_t Size of signature if included GSS_Token octet stream Binary encoding of GSS token GSS_Signature octet stream Binary encoding of signature 3. Overall Protocol Comments Readers that are unfamiliar with the GSS-API concepts are encouraged to read the characteristics and concepts section of [RFC2078] before examining this protocol in detail. Client and server must be locally authenticated and have acquired default credentials per [RFC2078] before using this protocol. Not all flags used in GSS-API interfaces are specified in this document. Where omitted, clients and servers may select the default or use a value based on local system policy. Not all error return values from GSS-API interfaces are specified in this document. When errors are encountered, the client and server should act appropriately. Expires May 1998 [Page 3] INTERNET-DRAFT GSS-TSIG November 1997 4. Client Protocol Details 4.1 Negotiate Security Context To begin, the client establishes a security context with a target server. A security context is established by an exchange of tokens. To obtain the first token GSS_Init_sec_context is called, input_context_handle = 0 targ_name = output_name from GSS_Import_Name (called with SERVICE:dns@servername) input_token = NULL The following flags are required by this protocol: replay_det_req_flag = TRUE (require replay detection) mutual_req_flag = TRUE (require mutual authentication) GSS_Init_sec_context returns a token output_token, a return code major_status, and a set of flags that indicate the capabilities of the underlying security mechanism. The client must ensure that replay_det_req_flag and mutual_req_flag are supported before continuing. Success values of major_status are GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. 4.1.1 Continue Negotiation (major_status == GSS_S_CONTINUE_NEEDED) If major_status indicates GSS_S_CONTINUE_NEEDED, the client must send output_token to the server. The server will send a token in reply. The token is delivered to the server encapsulated in a TSIG record, where: Context ID = 0 (new context negotiation) Control Flags = 0 (no flags) GSS_Token = output_token from GSS_Init_sec_context Until the context negotiation is complete, GSS_Signature is empty. The Time Signed and Expire fields are ignored on unsigned messages during the negotiation. The output_token is itself signed and protected against replay attack. The server will send a token encapsulated in a TSIG RR to the client in a response message. The Context ID field will have been set by the server to uniquely identify the session being negotiated. The client must use this ID in all future messages associated with this security context. If the response from the server does not contain a TSIG RR with a token and matching TSIG algorithm name or if the message RCODE is REFUSED, the client must abandon this algorithm. Expires May 1998 [Page 4] INTERNET-DRAFT GSS-TSIG November 1997 The client extracts GSS_Token from the record and passes it as input_token to GSS_Init_sec_context. If GSS_Init_sec_context again returns GSS_S_CONTINUE_NEEDED, the process is repeated by sending another message to the server with a TSIG RR attached, where: Context ID = Context ID assigned by server in previous message GSS_Token = output_token from the last call to GSS_Init_sec_context Clients should place a limit on the number of continuations for a given Context ID to prevent endless looping. 4.1.2 Negotiation Complete (major_status == GSS_S_COMPLETE) If major_status indicates GSS_S_COMPLETE, the client is authenticated. The client can now exchange signed, secure messages with the server. GSS_Init_sec_context returns a non-NULL value in output_context_handle to be used in future GSS operations. The client may receive GSS_S_COMPLETE on the very first call to GSS_Init_sec_context, or after exchanging tokens one or more times with the server. If GSS_S_COMPLETE was received after exchanging tokens with the server, the message containing the last token may have been signed by the server, and the client must verify this signature per the procedure in section 4.3. 4.2 Send Signed Request To send a signed message to the server, the client creates the outgoing DNS request message and attaches a TSIG RR: Time Signed = as appropriate (see [TSIG]) Expire = as appropriate (see [TSIG]) Context ID = Context ID previously assigned by server If the client wishes to retain the current context for future messages, it must set the Control Flags field to 0. If the client is done with this security context it must set Control Flags to 1, informing the server that it is terminating the context. The context will be deleted after a response has arrived from the server. If this is the first message to the server after GSS_Init_sec_context returned GSS_S_COMPLETE, and if GSS_Init_sec_context returned a non-NULL output_token, then output_token must be placed in the GSS_Token field. Subsequent messages do not need to include output_token. Expires May 1998 [Page 5] INTERNET-DRAFT GSS-TSIG November 1997 Signatures are generated using GSS_GetMIC, context_handle = output_context_handle from GSS_Init_sec_context message = whole outgoing message in wire format including TSIG RR with GSS_Signature field set to zero If GSS_GetMIC returns GSS_S_COMPLETE, the message signature is returned in per_msg_token. The message signature is placed into GSS_Signature in the TSIG RR and the message is sent to the server. If the client cannot successfully generate a signature, it should log an appropriate error and terminate the security context. 4.3 Verify Signed Response When using this protocol, a client can only trust a response from a server if that response is signed. A signed message has a non-zero GSS_Signature Size field in the TSIG RR. Signatures are verified by calling GSS_VerifyMIC, context_handle = output_context_handle from GSS_Init_sec_context per_msg_token = GSS_Signature extracted from TSIG RR message = whole incoming message in wire format including TSIG RR with GSS_Signature field set to zero If GSS_VerifyMIC returns GSS_S_COMPLETE and the Time Signed and Expire fields are valid according to [TSIG], then the message is intact and the client can trust the response. If an error is returned, then the client should log this event appropriately. The client should resend the original message to the server at least once to see if a properly signed response can be obtained. If the server set Control Flags to 1 in the response, the context is terminated. The client must delete its context by passing output_context_handle to GSS_Delete_sec_context. 4.4 Fatal Context Error Response If the server encounters a fatal error in security context processing, then it will send to the client an unsigned response with RCODE REFUSED. The client should assume that the security context is no longer valid, and negotiate a new context for further transmissions. Expires May 1998 [Page 6] INTERNET-DRAFT GSS-TSIG November 1997 5. Server Protocol Details 5.1 Process Message When a server receives a message containing a TSIG RR with the defined algorithm, it examines the Context ID field of the record to determine the state of the security context negotiation. If Context ID == 0, then the sender is negotiating a new security context per section 5.2. If Context ID is non-zero and maps to a context negotiation that has not yet completed, the server continues the negotiation per section 5.2.1. If Context ID is non-zero and maps to a completed negotiation, the server can verify the signature on the message and send a signed response. If Context ID is non-zero and does not map to a currently active context, the server must send the client a fatal context error response. 5.2 Negotiate Security Context The client is establishing a new security context with the server. The server calls GSS_Accept_sec_context, input_context_handle = 0 input_token = GSS_Token extracted from TSIG RR The Time Signed and Expire fields must be ignored on unsigned messages during an unfinished negotiation. GSS_Accept_sec_context returns output_token and a return code major_status. Success values of major_status are GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. If the call is successful then the server associates a unique Context ID to this context. If a fatal context error is returned, the server must send a fatal context error message to the client. Expires May 1998 [Page 7] INTERNET-DRAFT GSS-TSIG November 1997 5.2.1 Continue Negotiation (major_status == GSS_S_CONTINUE_NEEDED) If major_status indicates GSS_S_CONTINUE_NEEDED then the context negotiation is not yet complete. The server must send output_token to the client and wait for the client to respond with another token. The token is delivered to the client encapsulated in a TSIG record, where: Context ID = value associated with this negotiation Control Flags = 0 (no flags) GSS_Token = output_token from GSS_Accept_sec_context After sending the response to the client, the server waits for the client to send a TSIG RR back with matching Context ID. When the message arrives, input_token is extracted from the GSS_Token field in the TSIG RR and passed to GSS_Accept_sec_context. If GSS_Accept_sec_context again returns GSS_S_CONTINUE_NEEDED, the process is repeated by sending another message to the client with a TSIG RR attached, where: Context ID = Context ID from previous message GSS_Token = output_token from the last call to GSS_Accept_sec_context If GSS_Accept_sec_context returns a fatal context error, the server must send a fatal context error message to the client. Servers should place a limit on the number of continuations for a given Context ID to prevent endless looping. Excessive continuations should be treated as a fatal context error, and an error message should be sent to the client. 5.2.2 Negotiation Complete (major_status == GSS_S_COMPLETE) If major_status indicates GSS_S_COMPLETE, the client is authenticated. GSS_Accept_sec_context returns a non-NULL value in output_context_handle. This handle is associated with the current Context ID and is used in future GSS operations. The context handle may also be used for other security operations, such as access control (where available). If the client set the deleg_req_flag to TRUE when it called GSS_Init_sec_context, then the server may also call out to other services under the context of the client. The last message from the client may be signed. If the message is signed, the signature must be verified using the procedure in section 5.3. Expires May 1998 [Page 8] INTERNET-DRAFT GSS-TSIG November 1997 If the message is not signed then the last call to GSS_Accept_sec_context must have returned a non-NULL output_token. This will occur if the server completes its half of the negotiation before the client. The token must be sent to the client in a signed response using the procedure in section 5.4. If the message is not signed and GSS_Accept_sec_context returned NULL for output_token, then the server was expecting a signed message from the client. An error message must be sent to the client using the procedure in section 5.5. 5.3 Verify Signed Request When using this protocol, the server must not act on any DNS request from a client if the signature is missing from the message, if the signature check fails, or if the signature cannot be verified. A signed message has a non-zero value in the GSS_Signature Size field of the TSIG RR. To verify a signature in a message the server calls GSS_VerifyMIC, context_handle = output_context_handle associated with current Context ID per_msg_token = GSS_Signature extracted from TSIG RR message = whole incoming message in wire format including TSIG RR with GSS_Signature field set to zero If GSS_VerifyMIC returns GSS_S_COMPLETE and the Time Signed and Expire fields are valid according to [TSIG], then the message is intact and the server can now act on the DNS request received from the client. If GSS_VerifyMIC returns a fatal context error, the server must send a fatal context error message to the client. 5.4 Send Signed Response After the server has verified an incoming message and performed the requested DNS operation, it can send a signed response to the client. To send a signed response to a client, the client must create the outgoing DNS request message and then attach a TSIG RR: Time Signed = as appropriate (see [TSIG]) Expire = as appropriate (see [TSIG]) Context ID = Context ID from request message Expires May 1998 [Page 9] INTERNET-DRAFT GSS-TSIG November 1997 If the server wishes to terminate the security context after this response, it must set Control Flags to 1. Otherwise, Control Flags must be set the same as the Control Flags in the client's request message. If this is the first message to the client after GSS_Accept_sec_context returned GSS_S_COMPLETE, and if GSS_Accept_sec_context returned a non-NULL output_token, then output_token must be placed in the GSS_Token field. Subsequent messages do not need to include output_token. The server creates the signature for the response message by calling GSS_GetMIC, context_handle = output_context_handle associated with Context ID from client message = whole outgoing message in wire format including TSIG RR with GSS_Signature field set to zero If GSS_GetMIC returns GSS_S_COMPLETE, the message signature is returned in per_msg_token. The message signature is placed into GSS_Signature and the message is sent to the client. If GSS_GetMIC returns a fatal context error, the server must send a fatal context error message to the client. If the client or server set Control Flags to 1, the server can terminate the security context by passing the output_context_handle associated with this Context ID to GSS_Delete_sec_context. The value of Context ID can now be reused. The server should not reuse this value in the near future if possible, to avoid possible conflict between valid clients and clients attempting to reuse a stale context. 5.5 Send Fatal Context Error Response To send a fatal context error response, the server sends a response message to the client with the RCODE set to REFUSED. 6. Security Considerations This document describes a protocol for DNS security using GSS-API. The security provided by this protocol is only as good as the security provided by the underlying GSS mechanisms. Expires May 1998 [Page 10] INTERNET-DRAFT GSS-TSIG November 1997 7. Acknowledgements The authors of this document would like to thank the following people for their contribution to this specification: Chuck Chan and James Gilroy. 8. References [RFC2078] J. Linn, "Generic Security Service Application Program Interface, Version 2," RFC 2078, OpenVision Technologies, January 1997. [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)," draft-ietf-dnsind-tsig-01.txt, ISC, TIS, Cybercash, November 1996, WORK IN PROGRESS: contact paul@vix.com [RFC2065] D. Eastlake 3rd, C. Kaufman, "Domain Name System Security Extensions," RFC 2065, Cybercash, Iris, January 1997. [RFC2137] D. Eastlate 3rd, "Secure Domain Name System Dynamic Update," RFC 2137, CyberCash, April 1997. 9. Author's Addresses Stuart Kwan Praerit Garg Microsoft Corporation Microsoft Corporation One Microsoft Way One Microsoft Way Redmond, WA 98052 Redmond, WA 98052 USA USA Ram Viswanathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Expires May 1998 [Page 11]