diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-00.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-00.txt new file mode 100644 index 0000000000..975197d534 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-gss-tsig-00.txt @@ -0,0 +1,1158 @@ + + +INTERNET-DRAFT Stuart Kwan + Praerit Garg + James Gilroy + Levon Esibov + Microsoft Corp. + July 2000 + Expires January 2001 + + + GSS Algorithm for TSIG (GSS-TSIG) + + +Status of this Memo + +This document is an Internet-Draft and is in full conformance +with all provisions of Section 10 of RFC2026. + +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. + + +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) (RFC2743). + + + + + + + + + + + + + +Expires January 2001 [Page 1] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +Table of Contents + +1: Introduction......................................................2 +2: Algorithm Overview................................................3 + 2.1: GSS Details...................................................4 +3: Client Protocol Details...........................................4 + 3.1: Negotiating Context...........................................4 + 3.1.1: Call GSS_Init_sec_context.................................5 + 3.1.2: Send TKEY Query to Server.................................6 + 3.1.3: Receive TKEY Query-Response from Server...................7 + 3.2: Context Established...........................................9 +4: Server Protocol Details...........................................9 + 4.1: Negotiating Context...........................................9 + 4.1.1: Receive TKEY Query from Client...........................10 + 4.1.2: Call GSS_Accept_sec_context..............................10 + 4.1.3: Send TKEY Query-Response to Client.......................11 + 4.2: Context Established..........................................12 + 4.2.1: Terminating a Context....................................12 +5: Sending and Verifying Signed Messages............................12 + 5.1: Sending a Signed Message - Call GSS_GetMIC...................12 + 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............13 +6: Example usage of GSS-TSIG algorithm..............................14 +7: Security Considerations..........................................18 +8: IANA Considerations..............................................18 +9: Conformance......................................................18 +10:Acknowledgements.................................................18 +11:References.......................................................19 + + +1. Introduction + +The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol +was developed to provide a lightweight end to end authentication and +integrity off messages between two DNS entities, such as client and +server or server and server. TSIG can be used to protect dynamic update +messages, authenticate regular message or to off-load complicated +DNSSEC [RFC2535] processing from a client to a server and still allow +the client to be assured of the integrity off the answers. + +The TSIG protocol [RFC2845] is extensible through the definition of new +algorithms. This document specifies an algorithm based on the Generic +Security Service Application Program Interface (GSS-API) [RFC2743]. +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 [RFC1964] +for one transaction, whereas that same server may use SPKM [RFC2025] +with a different client. + +Expires January 2001 [Page 2] + +INTERNET-DRAFT GSS-TSIG July 2000 + +* 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. + +The scope of this document is limited to the description of an +authentication mechanism only. It does not discuss and/or propose an +authorization mechanism. Readers that are unfamiliar with GSS-API +concepts are encouraged to read the characteristics and concepts section +of [RFC2743] before examining this protocol in detail. It is also +assumed that the reader is familiar with [RFC2845], [TKEY], [RFC1034] +and [RFC1035]. + +The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and +"MAY" in this document are to be interpreted as described in RFC 2119 +[RFC2119]. + + +2. Algorithm Overview + +In GSS, client and server interact to create a "security context". +The security context can be used to create and verify transaction +signatures on messages between the two parties. A unique security +context is required for each unique connection between client and +server. + +Creating a security context involves a negotiation between client and +server. Once a context has been established, it has a finite lifetime +for which it can be used to secure messages. Thus there are three +states of a context associated with a connection: + + +----------+ + | | + V | + +---------------+ | + | Uninitialized | | + | | | + +---------------+ | + | | + V | + +---------------+ | + | Negotiating | | + | Context | | + +---------------+ | + | | + V | + +---------------+ | + | Context | | + | Established | | + +---------------+ | + | | + +----------+ + +Expires January 2001 [Page 3] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +Every connection begins in the uninitialized state. + + +2.1 GSS Details + +Client and server MUST be locally authenticated and have acquired +default credentials before using this protocol as specified in +Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. + +The GSS-TSIG algorithm consists of two stages: + +I. Establish security context. The Client and Server use the +GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the +tokens that they pass to each other using [TKEY] as a transport +mechanism. + +II. Once the security context is established it is used to generate and +verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These +signatures are exchanged by the Client and Server as a part of the TSIG +records exchanged in DNS messages sent between the Client and Server, +as described in [RFC2845]. + + +3. Client Protocol Details + +A unique context is required for each server to which the client sends +secure messages. A context is identified by a context handle. A +client maintains a mapping of servers to handles, + + (target_name, key_name, context_handle) + +The value key_name also identifies a context handle. The key_name is +the owner name of the TKEY and TSIG records sent between a client and a +server to indicate to each other which context MUST be used to process +the current request. + + +3.1 Negotiating Context + +In GSS, establishing a security context involves the passing of opaque +tokens between the client and the server. The client generates the +initial token and sends it to the server. The server processes the +token and if necessary, returns a subsequent token to the client. The +client processes this token, and so on, until the negotiation is +complete. The number of times the client and server exchange tokens +depends on the underlying security mechanism. A completed negotiation +results in a context handle. + +The TKEY resource record [TKEY] is used as the vehicle to transfer +tokens between client and server. The TKEY record is a general +mechanism for establishing secret keys for use with TSIG. For more +information, see [TKEY]. + +Expires January 2001 [Page 4] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +3.1.1 Call GSS_Init_sec_context + +To obtain the first token to be sent to a server, a client MUST call +GSS_Init_sec_context API. +The following input parameters MUST be used. The outcome of the call is +indicated with the output values below. Consult Sections 2.2.1 +"GSS_Init_sec_context call" of [RFC2743] for syntax definitions. + + INPUTS + CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use + default"). Client MAY instead specify some other valid handle + to its credentials. + CONTEXT HANDLE input_context_handle = 0 + INTERNAL NAME targ_name = "DNS/" + OBJECT IDENTIFIER mech_type = Underlying security + mechanism chosen by implementers. To guarantee + interoperability of the implementations of the GSS-TSIG + mechanism client MUST specify a valid underlying security + mechanism that enables use of Kerberos v5. + OCTET STRING input_token = NULL + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + BOOLEAN deleg_req_flag = TRUE + BOOLEAN sequence_req_flag = TRUE + BOOLEAN anon_req_flag = FALSE + BOOLEAN conf_req_flag = TRUE + BOOLEAN integ_req_flag = TRUE + INTEGER lifetime_req = 0 (0 requests a default + value). Client MAY instead specify another upper bound for the + lifetime of the context to be established in seconds. + OCTET STRING chan_bindings = Any valid channel bindings + as specified in Section 1.1.6 "Channel Bindings" in [RFC2734] + + OUTPUTS + INTEGER major_status + CONTEXT HANDLE output_context_handle + OCTET STRING output_token + BOOLEAN replay_det_state + BOOLEAN mutual_state + INTEGER minor_status + OBJECT IDENTIFIER mech_type + BOOLEAN deleg_state + BOOLEAN sequence_state + BOOLEAN anon_state + BOOLEAN trans_state + BOOLEAN prot_ready_state + BOOLEAN conf_avail + BOOLEAN integ_avail + INTEGER lifetime_rec + + + + +Expires January 2001 [Page 5] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +The client MUST abandon the algorithm if returned major_status is set to +one of the following errors: + + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_OLD_TOKEN + GSS_S_DUPLICATE_TOKEN + GSS_S_NO_CONTEXT + GSS_S_BAD_NAMETYPE + GSS_S_BAD_NAME + GSS_S_BAD_MECH + GSS_S_FAILURE + +Success values of major_status are GSS_S_CONTINUE_NEEDED and +GSS_S_COMPLETE. The exact success code is important during later +processing. + +The values of replay_det_state and mutual_state indicate if the +security package provides replay detection and mutual +authentication, respectively. If one or both of these values +are FALSE, the client MUST abandon this algorithm. + +Client's behavior MAY depend on other OUTPUT parameters according +to the policy local to the client. + +The handle output_context_handle is unique to this negotiation and +is stored in the client's mapping table as the context_handle that +maps to target_name. + + + +3.1.2 Send TKEY Query to Server + +An opaque output_token returned by GSS_Init_sec_context is transmitted +to the server in a query request with QTYPE=TKEY. The token itself +will be placed in a Key Data field of the RDATA field in the TKEY +resource record in the additional records section of the query. The +owner name of the TKEY resource record set queried for and the owner +name of the supplied TKEY resource record in the additional records +section MUST be the same. This name uniquely identifies the security +context to both the client and server, and thus the client SHOULD use +a value which is globally unique as described in [TKEY]. + + + + + + + +Expires January 2001 [Page 6] + +INTERNET-DRAFT GSS-TSIG July 2000 + + + TKEY Record + NAME = client-generated globally unique domain name string + (as described in [TKEY]) + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [TKEY]) + Key Size = size of output_token in octets + Key Data = output_token + +The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, +Error, Other Size and Data Fields, MUST be set according to [TKEY]. + +The query is transmitted to the server. + +Note: if the original client call to GSS_Init_sec_context returned any +major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then +the client MUST NOT send TKEY query. + + +3.1.3 Receive TKEY Query-Response from Server + +Upon the reception of the TKEY query DNS server MUST respond according +to the description in Section 4. This Section specifies the behavior +of the client after it receives the matching response to its query. + +The next processing step depends on the value of major_status from the +most recent call that client performed to GSS_Init_sec_context: either +GSS_S_COMPLETE or GSS_S_CONTINUE. + + + +3.1.3.1 Value of major_status == GSS_S_COMPLETE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, +then the client side component of the negotiation is complete and the +client is awaiting confirmation from the server. + +Confirmation is in the form of a query response with RCODE=NOERROR +and with the last client supplied TKEY record in the answer section +of the query. The response MUST be signed with a TSIG record. The +signature in the TSIG record MUST be verified using the procedure +detailed in section 5, Sending and Verifying Signed Messages. If the +response is not signed, OR if the response is signed but signature is +invalid, then an attacker has tampered with the message in transit or +has attempted to send the client a false response. The client MUST +continue waiting for a response to its last TKEY query until the time +period since the client sent last TKEY query expires. Such a time period +is specified by the policy local to the client. + + + + +Expires January 2001 [Page 7] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +If the signature is verified the context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security context. + + +3.1.3.2 Value of major_status == GSS_S_CONTINUE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_CONTINUE, then the negotiation is not yet complete. The server +will return to the client a query-response with a TKEY record in the +Answer section. Since the message is not signed, the client MUST +disregard the error code of the DNS message and the TKEY record. The +client MUST pass a token specified in the Key Data field in the TKEY +resource record to GSS_Init_sec_context using the same parameters values +as in previous call except values for CONTEXT HANDLE +input_context_handle and OCTET STRING input_token as described below: + + INPUTS + CONTEXT HANDLE input_context_handle = context_handle (this is the + context_handle corresponding to the key_name which is the + owner name of the TKEY record in the answer section in the + TKEY query response) + OCTET STRING input_token = token from Key field of + TKEY record + +Depending on the following OUTPUT values of GSS_Init_sec_context + INTEGER major_status + OCTET STRING output_token +the client MUST take one of the following actions: + +If OUTPUT major_status is set to one of the following values + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_OLD_TOKEN + GSS_S_DUPLICATE_TOKEN + GSS_S_NO_CONTEXT + GSS_S_BAD_NAMETYPE + GSS_S_BAD_NAME + GSS_S_BAD_MECH + GSS_S_FAILURE + +then client MUST abandon this negotiation sequence. The client MAY +repeat the negotiation sequence starting with the uninitialized state as +described in section 3.1. To prevent infinite looping the number of +attempts to establish a security context must be limited. + +If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then +client MUST act as described below. + + +Expires January 2001 [Page 8] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet +finished. The token output_token MUST be passed to the server in a TKEY +record by repeating the negotiation sequence beginning with section +3.1.2. The client MUST place a limit on the number of continuations in +a context negotiation to prevent endless looping. Such limit SHOULD NOT +exceed value of 10. + +If major_status is GSS_S_COMPLETE and output_token is non-NULL, the +client-side component of the negotiation is complete but the token +output_token MUST be passed to the server by repeating the negotiation +sequence beginning with section 3.1.2. + +If major_status is GSS_S_COMPLETE and output_token is NULL, context +negotiation is complete. The context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security context. + + +3.2 Context Established + +When context negotiation is complete, the handle context_handle MUST be +used for the generation and verification of transaction signatures. + +The procedures for sending and receiving signed messages are described +in section 5, Sending and Verifying Signed Messages. + + +4. Server Protocol Details + +As on the client-side, the result of a successful context negotiation +is a context handle used in future generation and verification of the +transaction signatures. + +A server MAY be managing several contexts with several clients. +Clients identify their contexts by providing a key name in their +request. The server maintains a mapping of key names to handles: + + (key_name, context_handle) + + +4.1 Negotiating Context + +A server MUST recognize TKEY queries as security context negotiation +messages. + + + + + + + + + + +Expires January 2001 [Page 9] + +INTERNET-DRAFT GSS-TSIG July 2000 + +4.1.1 Receive TKEY Query from Client + +Upon receiving a query with QTYPE = TKEY, the server MUST examine +whether the Mode and Algorithm Name fields of the TKEY record in the +additional records section of the message contain values of 3 and +gss-tsig, respectively. If they do, then the (key_name, context_handle) +mapping table is searched for the key_name matching the owner name of +the TKEY record in the additional records section of the query. If the +name is found in the table, the corresponding context_handle is used in +subsequent GSS operations. If the name is not found, then the server +interprets this as a start of new security context negotiation. + + +4.1.2 Call GSS_Accept_sec_context + +The server performs its side of a context negotiation by calling +GSS_Accept_sec_context. The following input parameters MUST be used. The +outcome of the call is indicated with the output values below. Consult +Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743] +for syntax definitions. + + INPUTS + CONTEXT HANDLE input_context_handle = 0 if new negotiation, + context_handle matching + key_name if ongoing negotiation + OCTET STRING input_token = token specified in the Key + field from TKEY RR (from Additional records Section of + the client's query) + + CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use + default"). Server MAY instead specify some other valid handle + to its credentials. + OCTET STRING chan_bindings = Any valid channel bindings + as specified in Section 1.1.6 "Channel Bindings" in [RFC2734] + + OUTPUTS + INTEGER major_status + CONTEXT_HANDLE output_context_handle + OCTET STRING output_token + INTEGER minor_status + INTERNAL NAME src_name + OBJECT IDENTIFIER mech_type + BOOLEAN deleg_state + BOOLEAN mutual_state + BOOLEAN replay_det_state + BOOLEAN sequence_state + BOOLEAN anon_state + BOOLEAN trans_state + BOOLEAN prot_ready_state + BOOLEAN conf_avail + BOOLEAN integ_avail + INTEGER lifetime_rec + CONTEXT_HANDLE delegated_cred_handle + +Expires January 2001 [Page 10] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +If this is the first call to GSS_Accept_sec_context in a new +negotiation, then output_context_handle is stored in the server's +key-mapping table as the context_handle that maps to the name of the +TKEY record. + + +4.1.3 Send TKEY Query-Response to Client + +The server MUST respond to the client with a TKEY query response with +RCODE = NOERROR, that contains a TKEY record in the answer section. + +If OUTPUT major_status is one of the following errors the error field +in the TKEY record set to BADKEY. + + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_DUPLICATE_TOKEN + GSS_S_OLD_TOKEN + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_NO_CONTEXT + GSS_S_BAD_MECH + GSS_S_FAILURE + +If OUTPUT major_status is set to GSS_S_COMPLETE or +GSS_S_CONTINUE_NEEDED then server MUST act as described below. + +If major_status is GSS_S_COMPLETE the server component of the +negotiation is finished. If output_token is non-NULL, then it MUST be +returned to the client in a Key Data field of the RDATA in TKEY. The +error field in the TKEY record is set to NOERROR. + +If major_status is GSS_S_COMPLETE and output_token is NULL, then the +TKEY record received from the client MUST be returned in the Answer +section of the response. The message MUST be signed with a TSIG record +as described in section 5, Sending and Verifying Signed Messages. The +context state is advanced to Context Established. Section 4.2 discusses +the usage of the security context. + +If major_status is GSS_S_CONTINUE, the server component of the +negotiation is not yet finished. The server responds to the TKEY +query with a standard query response, placing in the answer section a +TKEY record containing output_token in the Key Data RDATA field. The +error field in the TKEY record is set to NOERROR. The server MUST limit +the number of times that a given context is allowed to repeat, to +prevent endless looping. Such limit SHOULD NOT exceed value of 10. + + + + + +Expires January 2001 [Page 11] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +In all cases except if major_status is GSS_S_COMPLETE and output_token +is NULL other TKEY record fields MUST contain the following values: + NAME = key_name + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [TKEY]) + Key Size = size of output_token in octets + +The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, +Error, Other Size and Data Fields, MUST be set according to [TKEY]. + + +4.2 Context Established + +When context negotiation is complete, the handle context_handle +is used for the generation and verification of transaction signatures. +The handle is valid for a finite amount of time determined by the +underlying security mechanism. A server MAY unilaterally terminate +a context at any time (see section 4.2.1). + +The procedures for sending and receiving signed messages are given in +section 5, Sending and Verifying Signed Messages. + + +4.2.1 Terminating a Context + +A server can terminate any established context at any time. The +server MAY hint to the client that the context is being deleted +by including a TKEY RR in a response with the Mode field set to 5, i.e. +"key deletion" [TKEY]. +An active context is deleted by calling GSS_Delete_sec_context +providing the associated context_handle. + + +5. Sending and Verifying Signed Messages + +5.1 Sending a Signed Message - Call GSS_GetMIC + +The procedure for sending a signature-protected message is specified +in [RFC2845]. The data to be passed to the signature routine includes +the whole DNS message with specific TSIG variables appended. For the +exact format, see [RFC2845]. For this protocol, use the following +TSIG variable values: + + TSIG Record + NAME = key_name that identifies this context + RDATA + Algorithm Name = gss-tsig + +Assign the remaining fields in the TSIG RDATA appropriate values +as described in [RFC2845]. + + +Expires January 2001 [Page 12] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +The signature is generated by calling GSS_GetMIC. The following input +parameters MUST be used. The outcome of the call is indicated with the +output values specified below. Consult Sections 2.3.1 "GSS_GetMIC +call" of the RFC 2743[RFC2743] for syntax definitions. + + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = outgoing message plus TSIG + variables (per [RFC2845]) + INTEGER qop_req = 0 (0 requests a default + value). Caller MAY instead specify other valid value (for + details see Section 1.2.4 in [RFC2743]) + + + OUTPUTS + INTEGER major_status + INTEGER minor_status + OCTET STRING per_msg_token + +If major_status is GSS_S_COMPLETE, then signature generation +succeeded. The signature in per_msg_token is inserted into the +Signature field of the TSIG RR and the message is transmitted. + +If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or +GSS_S_FAILURE the caller MUST delete the security context, return to the +uninitialized state and SHOULD negotiate a new security context, as +described above in Section 3.1 + +If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry +for key_name from the (target_ name, key_name, context_handle) mapping +table, return to the uninitialized state and SHOULD negotiate a new +security context, as described above in Section 3.1 + +If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the +GSS_GetMIC call with allowed QOP value. The number of such repetitions +MUST be limited to prevent infinite loops. + + +5.2 Verifying a Signed Message - Call GSS_VerifyMIC + +The procedure for verifying a signature-protected message is specified +in [RFC2845]. +The NAME of the TSIG record determines which context_handle maps to +the context that MUST be used to verify the signature. If the NAME +does not map to an established context, the server MUST send a +standard TSIG error response to the client indicating BADKEY in the +TSIG error field (as described in [RFC2845]). + + + + + + +Expires January 2001 [Page 13] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: + + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = incoming message plus TSIG + variables (per [RFC2845]) + OCTET STRING per_msg_token = Signature field from TSIG RR + + OUTPUTS + INTEGER major_status + INTEGER minor_status + INTEGER qop_state + +If major_status is GSS_S_COMPLETE, the signature is authentic and the +message was delivered intact. Per [RFC2845], the timer values of the +TSIG record MUST also be valid before considering the message to be +authentic. The caller MUST not act on the request or response in the +message until these checks are verified. + +If major_status is set to one of the following values, the negotiated +context is no longer valid. + GSS_S_DEFECTIVE_TOKEN + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_DUPLICATE_TOKEN + GSS_S_OLD_TOKEN + GSS_S_UNSEQ_TOKEN + GSS_S_GAP_TOKEN + GSS_S_CONTEXT_EXPIRED + GSS_S_NO_CONTEXT + GSS_S_FAILURE + +If this failure occurs when a server is processing a client request, +the server MUST send a standard TSIG error response to the client +indicating BADKEY in the TSIG error field as described in [RFC2845]. + +If the timer values of the TSIG record are invalid, the message MUST +NOT be considered authentic. If this error checking fails when a server +is processing a client request, the appropriate error response MUST be +sent to the client according to [RFC2845]. + + +6. Example usage of GSS-TSIG algorithm + +This Section describes an example where a Client, client.example.com, +and a Server, server.example.com, establish a security context according +to the algorithm described above. + + + + + + + +Expires January 2001 [Page 14] + +INTERNET-DRAFT GSS-TSIG July 2000 + + I. Client initializes security context negotiation + To establish a security context with a server, server.example.com, the + Client calls GSS_Init_sec_context with the following parameters + (Note that some INPUT and OUTPUT parameters not critical for this + algorithm are not described in this example) + CONTEXT HANDLE input_context_handle = 0 + INTERNAL NAME targ_name = "DNS/ server.example.com" + OCTET STRING input_token = NULL + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + + The OUTPUTS parameters returned by GSS_Init_sec_context include + INTEGER major_status = GSS_S_CONTINUE_NEEDED + CONTEXT HANDLE output_context_handle context_handle + OCTET STRING output_token output_token + BOOLEAN replay_det_state = TRUE + BOOLEAN mutual_state = TRUE + + Client verifies that replay_det_state and mutual_state values are + TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a + success OUTPUT major_status value, client stores context_handle that + maps to "DNS/server.example.com" and proceeds to the next step. + + + II. Client sends a query with QTYPE = TKEY to server + Client sends a query with QTYPE = TKEY for a client-generated globally + unique domain name string, 789.client.example.com.server.example.com. + Query contains a TKEY record in its Additional records section with + the following fields (Note that some fields not specific to this + algorithm are not specified) + NAME = 789.client.example.com.server.example.com. + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [TKEY]) + Key Size = size of output_token in octets + Key Data = output_token + + After the key_name 789.client.example.com.server.example.com. + is generated it is stored in the client's (target_name, key_name, + context_handle) mapping table. + + + III. Server receives a query with QTYPE = TKEY + When server receives a query with QTYPE = TKEY, the server verifies + that Mode and Algorithm fields in the TKEY record in the Additional + records section of the query are set to 3 and "gss-tsig" respectively. + It finds that the key_name 789.client.example.com.server.example.com. + is not listed in its (key_name, context_handle) mapping table. + + + + + + +Expires January 2001 [Page 15] + +INTERNET-DRAFT GSS-TSIG July 2000 + + IV. Server calls GSS_Accept_sec_context + To continue security context negotiation server calls + GSS_Accept_sec_context with the following parameters (Note that some + INPUT and OUTPUT parameters not critical for this algorithm are not + described in this example) + INPUTS + CONTEXT HANDLE input_context_handle = 0 + OCTET STRING input_token = token specified in the Key + field from TKEY RR (from Additional + records section of the client's query) + The OUTPUTS parameters returned by GSS_Accept_sec_context include + INTEGER major_status = GSS_S_CONTINUE_NEEDED + CONTEXT_HANDLE output_context_handle context_handle + OCTET STRING output_token output_token + + Server stores the mapping of the + 789.client.example.com.server.example.com. to OUTPUT context_handle + in its (key_name, context_handle) mapping table. + + + V. Server responds to the TKEY query + Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's + call to GSS_Accept_sec_context, the server responds to the TKEY query + placing in the answer section a TKEY record containing output_token in + the Key Data RDATA field. The error field in the TKEY record is set to + 0. The RCODE in the query response is set to NOERROR. + + + VI. Client processes token returned by server + When the client receives the TKEY query response from the server, the + client calls GSS_Init_sec_context with the following parameters (Note + that some INPUT and OUTPUT parameters not critical for this algorithm + are not described in this example) + CONTEXT HANDLE input_context_handle = the context_handle stored + in the client's mapping table entry (DNS/server.example.com., + 789.client.example.com.server.example.com., context_handle) + INTERNAL NAME targ_name = "DNS/server.example.com" + OCTET STRING input_token = token from Key field of TKEY + record from the Answer section of the server's response + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + + + The OUTPUTS parameters returned by GSS_Init_sec_context include + INTEGER major_status = GSS_S_COMPLETE + CONTEXT HANDLE output_context_handle = context_handle + OCTET STRING output_token = output_token + BOOLEAN replay_det_state = TRUE + BOOLEAN mutual_state = TRUE + + Since the major_status is set to GSS_S_COMPLETE the client side + security context is established, but since the output_token is not + NULL client MUST send a TKEY query to the server as described below. + +Expires January 2001 [Page 16] + +INTERNET-DRAFT GSS-TSIG July 2000 + + + VII. Client sends a query with QTYPE = TKEY to server + Client sends to the server a TKEY query for the + 789.client.example.com.server.example.com. name. Query contains a TKEY + record in its Additional records section with the following fields + (Note that some INPUT and OUTPUT parameters not critical to this + algorithm are not described in this example) + NAME = 789.client.example.com.server.example.com. + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [TKEY]) + Key Size = size of output_token in octets + Key Data = output_token + + + VIII. Server receives a TKEY query + When the server receives a TKEY query, the server verifies that Mode + and Algorithm fields in the TKEY record in the Additional records + section of the query are set to 3 and gss-tsig, repectively. It + finds that the key_name 789.client.example.com.server.example.com. is + listed in its (key_name, context_handle) mapping table. + + + IX. Server calls GSS_Accept_sec_context + To continue security context negotiation server calls + GSS_Accept_sec_context with the following parameters (Note that some + INPUT and OUTPUT parameters not critical for this algorithm are not + described in this example) + INPUTS + CONTEXT HANDLE input_context_handle = context_handle from the + (789.client.example.com.server.example.com., context_handle) + entry in the server's mapping table + OCTET STRING input_token = token specified in the Key + field of TKEY RR (from Additional records Section of + the client's query) + + The OUTPUTS parameters returned by GSS_Accept_sec_context include + INTEGER major_status = GSS_S_COMPLETE + CONTEXT_HANDLE output_context_handle = context_handle + OCTET STRING output_token = NULL + + Since major_status = GSS_S_COMPLETE, the security context on the + server side is established, but the server still needs to respond to + the client's TKEY query, as described below. The security context + state is advanced to Context Established. + + + + + + + + + +Expires January 2001 [Page 17] + +INTERNET-DRAFT GSS-TSIG July 2000 + + + X. Server responds to the TKEY query + Since the major_status = GSS_S_COMPLETE in the last server's call to + GSS_Accept_sec_context and the output_token is NULL, the server + responds to the TKEY query placing in the answer section a TKEY record + that was sent by the client in the Additional records section of the + client's latest TKEY query. In addition to this server places a + TSIG record in additional records section of its response. Server + calls GSS_GetMIC to generate a signature to include it in the TSIG + record. The server specifies the following GSS_GetMIC INPUT + parameters: + CONTEXT HANDLE context_handle = context_handle from the + (789.client.example.com.server.example.com., context_handle) + entry in the server's mapping table + OCTET STRING message = outgoing message plus TSIG + variables (as described in [RFC2845]) + + The OUTPUTS parameters returned by GSS_GetMIC include + INTEGER major_status = GSS_S_COMPLETE + OCTET STRING per_msg_token + + Signature field in the TSIG record is set to per_msg_token. + + + XI. Client processes token returned by server + Client receives the TKEY query response from the server. Since the + major_status was GSS_S_COMPLETE in the last client's call to + GSS_Init_sec_context, the client verifies that the server's response + is signed. To validate the signature client calls GSS_VerifyMIC with + the following parameters: + + INPUTS + CONTEXT HANDLE context_handle = context_handle for + 789.client.example.com.server.example.com. key_name + OCTET STRING message = incoming message plus TSIG + variables (as described in [RFC2845]) + OCTET STRING per_msg_token = Signature field from TSIG RR + included in the server's query response + + Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the + signature is validated, security negotiation is complete and the + security context state is advanced to Context Established. These + client and server will use the established security context to sign + and validate the signatures when they exchange packets with each + other until the context expires. + + +7. Security Considerations + +This document describes a protocol for DNS security using GSS-API. +The security provided by this protocol is only as effective as the +security provided by the underlying GSS mechanisms. + + +Expires January 2001 [Page 18] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +8. IANA Considerations + +The authors request that the IANA reserve the TSIG Algorithm name +gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource +records. This Algorithm name refers to the algorithm described in this +document. The requirement to have this name registered with IANA is +specified in RFC 2845. + + +9. Conformance + +The GSS API provides maximum flexibility to choose the underlying +security mechanisms that enables security context negotiation. GSS API +enables client and server to negotiate and choose such underlying +security mechanisms on the fly. At the same time, in order to guarantee +interoperability between clients and servers that support GSS-TSIG it is +required that a GSS APIs called by such client and server MUST support +Kerberos v5 as an underlying security mechanisms. In addition to this, +GSS APIs used by client and server MAY also support other underlying +security mechanisms. + + +10. Acknowledgements + +The authors of this document would like to thank the following people +for their contribution to this specification: Chuck Chan, Mike Swift, +Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd. + + + +11. References + +[RFC2743] J. Linn, "Generic Security Service Application Program + Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories, + January 2000. + +[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, + "Secret Key Transaction Signatures for DNS (TSIG)," RFC 2845, + ISC, NAI Labs, Motorola, Nominum, May, 2000, + +[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY + RR)," draft-ietf-dnsext-tkey-*.txt. + +[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," + RFC 2535, IBM, March 1999. + +[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," + RFC 2137, CyberCash, April 1997. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +Expires January 2001 [Page 19] + +INTERNET-DRAFT GSS-TSIG July 2000 + + +[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1034, November 1987. + +[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, OpenVision Technologies, June 1996. + +[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", + RFC 2025, Bell-Northern Research, October 1996. + + +12. 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 +skwan@microsoft.com + +James Gilroy Levon Esibov +Microsoft Corporation Microsoft Corporation +One Microsoft Way One Microsoft Way +Redmond, WA 98052 Redmond, WA 98052 +USA USA + levone@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + +Expires January 2001 [Page 20] + diff --git a/doc/draft/draft-ietf-dnsext-tkey-03.txt b/doc/draft/draft-ietf-dnsext-tkey-04.txt similarity index 89% rename from doc/draft/draft-ietf-dnsext-tkey-03.txt rename to doc/draft/draft-ietf-dnsext-tkey-04.txt index 7b4dc7c9fa..236a2d38a9 100644 --- a/doc/draft/draft-ietf-dnsext-tkey-03.txt +++ b/doc/draft/draft-ietf-dnsext-tkey-04.txt @@ -1,13 +1,13 @@ DNSEXT Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT Motorola -Expires: December 2000 June 2000 +Expires: January 2001 July 2000 Secret Key Establishment for DNS (TKEY RR) ------ --- ------------- --- --- ----- --- - + @@ -24,10 +24,11 @@ Status of This Document 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." + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt @@ -53,22 +54,20 @@ Status of This Document - Donald Eastlake 3rd [Page 1] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. Abstract - [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating - Domain Name System (DNS) queries and responses using shared secret - keys via the TSIG resource record (RR). However, it provides no - mechanism for setting up such keys other than manual exchange. This - document describes a TKEY RR that can be used in a number of - different modes to establish shared secret keys between a DNS - resolver and server. + [RFC 2845] provides a means of authenticating Domain Name System + (DNS) queries and responses using shared secret keys via the TSIG + resource record (RR). However, it provides no mechanism for setting + up such keys other than manual exchange. This document describes a + TKEY RR that can be used in a number of different modes to establish + shared secret keys between a DNS resolver and server. @@ -110,12 +109,13 @@ Acknowledgments + Donald Eastlake 3rd [Page 2] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. Table of Contents @@ -173,7 +173,7 @@ Table of Contents Donald Eastlake 3rd [Page 3] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. 1. Introduction @@ -185,12 +185,12 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 security and dynamic update [RFC 2535, RFC 2136]. Familiarity with these RFCs is assumed. - [draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently - authenticating DNS messages using shared secret keys via the TSIG - resource record (RR) but provides no mechanism for setting up such - keys other than manual exchange. This document specifies a TKEY RR - that can be used in a number of different modes to establish and - delete such shared secret keys between a DNS resolver and server. + [RFC 2845] provides a means of efficiently authenticating DNS + messages using shared secret keys via the TSIG resource record (RR) + but provides no mechanism for setting up such keys other than manual + exchange. This document specifies a TKEY RR that can be used in a + number of different modes to establish and delete such shared secret + keys between a DNS resolver and server. Note that TKEY established keying material and TSIGs that use it are associated with DNS servers or resolvers. They are not associated @@ -231,7 +231,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 4] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. servers which is currently used only for key deletion. @@ -289,7 +289,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 5] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. name SHOULD be a domain locally unique at the resolver, less than 128 @@ -327,9 +327,9 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 2.3 The Algorithm Field The algorithm name is in the form of a domain name with the same - meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm - determines how the secret keying material agreed to using the TKEY RR - is actually used to derive the algorithm specific key. + meaning as in [RFC 2845]. The algorithm determines how the secret + keying material agreed to using the TKEY RR is actually used to + derive the algorithm specific key. @@ -347,7 +347,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 6] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. To avoid different interpretations of the inception and expiration @@ -390,9 +390,9 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 ----- ----------- 0 - no error 1-15 a non-extended RCODE - 16 BADSIG (tsig) - 17 BADKEY (tsig) - 18 BADTIME (tsig) + 16 BADSIG (TSIG) + 17 BADKEY (TSIG) + 18 BADTIME (TSIG) 19 BADMODE 20 BADNAME 21 BADALG @@ -405,7 +405,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 7] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. RR and DNS header error field could have unrelated non-zero error @@ -463,7 +463,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 8] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. TKEY queries MUST be authenticated for all modes except GSS-API and, @@ -521,7 +521,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 9] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. algorithm field is set to the authentication algorithm the resolver @@ -579,7 +579,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 10] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. the discarded key. @@ -637,18 +637,17 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 11] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. the keying material to be used. The KEY RR that appears in the query need not be accompanied by a SIG(KEY) RR. If the query is - authenticated by the resolver with a TSIG RR [draft-ietf-dnsext- - tsig-*.txt] or SIG(0) RR and that authentication is verified, then - any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in - such a query SHOULD have a name that corresponds to the resolver but - it is only essential that it be a public key for which the resolver - has the corresponding private key so it can decrypt the response - data. + authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR + and that authentication is verified, then any SIG(KEY) provided in + the query SHOULD be ignored. The KEY RR in such a query SHOULD have + a name that corresponds to the resolver but it is only essential that + it be a public key for which the resolver has the corresponding + private key so it can decrypt the response data. The server response contains a TKEY RR in its answer section with the server assigned mode and echoes the KEY RR provided in the query in @@ -690,15 +689,15 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 section. The name of the key and the keying data are completely controlled by the sending resolver so a globally unique key name SHOULD be used. The KEY RR used MUST be one for which the server has + the corresponding private key, or it will not be able to decrypt the Donald Eastlake 3rd [Page 12] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. - the corresponding private key, or it will not be able to decrypt the keying material and will return a FORMERR. It is also important that no untrusted party (preferably no other party than the server) has the private key corresponding to the KEY RR because, if they do, they @@ -750,10 +749,11 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 + Donald Eastlake 3rd [Page 13] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. 6. Methods of Encryption @@ -790,10 +790,10 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 This section is to be interpreted as provided in [RFC 2434]. - Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF - can only be assigned by an IETF standards action. Special - consideration should be given before the allocation of meaning for - Mode field values 0x0000 and 0xFFFF. + Mode field values 0x0000 and 0xFFFF are reserved. + + Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE + can only be assigned by an IETF Standards Action. Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF are allocated by IESG approval or IETF consensus. @@ -811,7 +811,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 14] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. The following assignments are documented herein: @@ -829,7 +829,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 The entirety of this specification is concerned with the secure establishment of a shared secret between DNS clients and servers in - support of TSIG [draft-ietf-dnsext-tsig-*.txt]. + support of TSIG [RFC 2845]. Protection against denial of service via the use of TKEY is not provided. @@ -869,7 +869,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000 Donald Eastlake 3rd [Page 15] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. References @@ -916,9 +916,9 @@ References RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", March 1999. - draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. - Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". - + RFC 2845 - P. Vixie, O. Gudmundsson, D. Eastlake, B. + Wellington,"Secret Key Transaction Authentication for DNS (TSIG)", + May 2000. @@ -927,7 +927,7 @@ References Donald Eastlake 3rd [Page 16] -INTERNET-DRAFT The DNS TKEY RR June 2000 +INTERNET-DRAFT The DNS TKEY RR July 2000. Author's Address @@ -939,17 +939,17 @@ Author's Address Telephone: +1 978-562-2827 (h) +1 508-261-5434 (w) - FAX: +1 978-567-7941 (h) - +1 508-261-4447 (w) + FAX: +1 508-261-4447 (w) email: Donald.Eastlake@motorola.com Expiration and File Name - This draft expires December 2000. + This draft expires January 2001. + + Its file name is draft-ietf-dnsext-tkey-04.txt. - Its file name is draft-ietf-dnsext-tkey-03.txt. diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt deleted file mode 100644 index 93d81bc63b..0000000000 --- a/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt +++ /dev/null @@ -1,587 +0,0 @@ -IPng Working Group R. Draves -Internet Draft Microsoft Research -Document: draft-ietf-ipngwg-default-addr-select-00.txt October 22, 1999 -Category: Standards Track - - Default Address Selection for IPv6 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026 [1]. - - 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. - -Abstract - - This document describes two algorithms, for destination address - ordering and for source address selection. The algorithms specify - default behavior for all IPv6 implementations. They do not override - choices made by applications or upper-layer protocols, nor do they - preclude the development of more advanced mechanisms for address - selection. The two algorithms share a common framework, including an - optional mechanism for allowing administrators to provide policy - that can override the default behavior. - -1. Introduction - - The IPv6 addressing architecture [2] allows multiple unicast - addresses to be assigned to interfaces. These addresses may have - different reachability scopes (link-local, site-local, or global). - These addresses may be "preferred" or "deprecated" [3]. In addition, - multi-homing situations will result in more addresses per node. For - example, a node may have multiple interfaces, some of them tunnels - or virtual interfaces, or a site may have multiple ISP attachments. - - The end result is that IPv6 implementations will very often be faced - with multiple possible source and destination addresses when - initiating communication. It is desirable to have simple default - algorithms, common across all implementations, for selecting source - -Draves Standards Track - Expires May 2000 1 - -Default Address Selection for IPv6 October 22, 1999 - - - and destination addresses so that developers and administrators can - reason about and predict the behavior of their systems. - - This document specifies source address selection and destination - address selection separately, but using a common framework so that - together the two algorithms yield useful results. The algorithms - attempt to choose source and destination addresses of appropriate - scope and configuration status (preferred or deprecated). - Furthermore, this document suggests a preferred method, longest - matching prefix, for choosing among otherwise equivalent addresses - in the absence of better information. - - The framework also has policy hooks to allow administrative override - of the default behavior. For example, using these hooks an - administrator can specify a preferred source prefix for use with a - destination prefix, or prefer destination addresses with one prefix - over addresses with another prefix. These hooks give an - administrator flexibility in dealing with some multi-homing and - transition scenarios, but they are certainly not a panacea. - - The rules specified in this document MUST NOT be construed to - override an application or upper-layer's explicit choice of - destination or source address. - -1.1. 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 RFC-2119 [4]. - -2. Framework - - Our framework for address selection derives from the most common - implementation architecture, which separates the choice of - destination address from the choice of source address. Consequently, - the framework specifies two separate algorithms for these tasks. The - algorithms are designed to work well together and they share a - mechanism for administrative policy override. - - In this implementation architecture, applications use APIs [5] like - getipnodebyname() and getaddrinfo() that return a list of addresses - to the application. The application then passes a destination - address to the IPv6 layer with connect() or sendto(). The - application might just use the first address in the list, or it - might loop over the list of addresses to find a working address. In - any case, the IPv6 network layer is never in a position where it - needs to choose a destination address from several alternatives. The - application might also specify a source address with bind(), but - often the source address is left unspecified. Therefore the IPv6 - layer does often choose a source address from several alternatives. - - As a consequence, we intend that implementations of - getipnodebyname() and getaddrinfo() will use the destination address - -Draves Standards Track - Expires May 2000 2 - -Default Address Selection for IPv6 October 22, 1999 - - - ordering algorithm specified here to sort the list of addresses that - they return. Separately, the IPv6 network layer will use the source - address selection algorithm when an application or upper-layer has - not specified a source address. - - The algorithms use several criteria in making their decisions. The - combined effect is to prefer destination/source address pairs for - which the two addresses are of equal scope or type, prefer smaller - scopes over larger scopes for the destination address, prefer non- - deprecated source addresses of sufficient scope to reach the - destination, avoid the use of transitional addresses when native - addresses are available, and all else being equal prefer address - pairs having the longest possible common prefix. - - The framework optionally allows for the possibility of - administrative configuration of policy that can override the default - behavior of the algorithms. The policy override takes the form of a - configurable table that provides precedence values and preferred - source prefixes for destination prefixes. If an implementation is - not configurable, or if an implementation has not been configured, - then the default policy table specified in this document MUST be - used. - -2.1. Scope Comparisons - - Multicast destination addresses have a 4-bit scope field that - controls the propagation of the multicast packet. The IPv6 - addressing architecture defines scope field values for node-local - (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), - and global (0xE) scopes. - - Application of the address selection algorithms in the presence of - multicast destination addresses requires the comparison of a unicast - address scope with a multicast address scope. We map unicast link- - local to multicast link-local, unicast site-local to multicast site- - local, and unicast global scope to multicast global scope. For - example, unicast site-local is equal to multicast site-local, which - is smaller than multicast organization-local, which is smaller than - unicast global, which is equal to multicast global. - - We write Scope(A) to mean the scope of address A. For example, if A - is a link-local unicast address and B is a site-local multicast - address, then Scope(A) < Scope(B). - - This mapping implicitly conflates unicast site boundaries and - multicast site boundaries. - -2.2. IPv4-Compatible Addresses and Other Format Prefixes - - For the purposes of this document, IPv4-compatible addresses have - global scope and "preferred" configuration status. - - - -Draves Standards Track - Expires May 2000 3 - -Default Address Selection for IPv6 October 22, 1999 - - - Similarly, NSAP addresses, IPX addresses, or addresses with as-yet- - undefined format prefixes should be treated as having global scope - and "preferred" configuration status. Later standards may supercede - this treatment. - - The loopback address should be treated as having link-local scope - and "preferred" configuration status. - -2.3. Policy Table - - The policy table is a longest-matching-prefix lookup table, like a - routing table. Given an address A, a lookup in the policy table - produces three values: a precedence value Precedence(A), a - classification or label Label(A), and a second label - MatchSrcLabel(A). - - The precedence value Precedence(A) is used for sorting destination - addresses. If Precedence(A) > Precedence(B), we say that address A - has higher precedence than address B, meaning that our algorithm - will prefer to sort destination address A before destination address - B. - - The labels Label(A) and MatchSrcLabel(A) allow for policies that - prefer a particular source address prefix for use with a destination - address prefix. The algorithms prefer to use a source address S with - a destination address D if Label(S) = MatchSrcLabel(D). - - IPv6 implementations SHOULD support configurable address selection - via a mechanism at least as powerful as the policy tables defined - here. If an implementation is not configurable or has not been - configured, then it MUST operate according to the algorithms - specified here in conjunction with the following default policy - table: - - Prefix Precedence Label MatchSrcLabel - fe80::/10 40 1 1 - fec0::/10 30 2 2 - ::/0 20 3 3 - 2002::/16 10 4 4 - ::/96 10 5 5 - - One effect of the default policy table is to prefer using native - source addresses with native destination addresses, 6to4 source - addresses with 6to4 destination addresses, and v4-compatible source - addresses with v4-compatible destination addresses. Another effect - of the default policy table is to prefer communication using native - addresses to communication using either 6to4 or v4-compatible - addresses, but not to express a preference for 6to4 addresses over - v4-compatible addresses or vice-versa. - - - - - -Draves Standards Track - Expires May 2000 4 - -Default Address Selection for IPv6 October 22, 1999 - - -2.4. Candidate Source Addresses - - Both the destination address ordering algorithm and the source - address selection algorithm use the concept of a "candidate set" of - potential source addresses for a given destination address. - - We write CandidateSrc(A) to denote the candidate set for the address - A. In some cases the destination address A may be qualified with a - scope-id or other information that will constrain the candidate set. - We write PreferSrc(A) to denote the subset of preferred (non- - deprecated) addresses in CandidateSrc(A) We write MatchSrc(A) to - denote the subset of addresses S in PreferSrc(A) for which Label(S) - = MatchSrcLabel(A). - - The destination address ordering algorithm and the source address - selection algorithm specify somewhat different definitions for - CandidateSrc(A). This is because the two algorithms operate in - different environments. The source address selection algorithm - assumes that an outgoing interface for a packet has already been - selected, while the destination address ordering algorithm does not - assume that knowledge. Therefore the destination address ordering - algorithm uses a broader or more-inclusive definition of - CandidateSrc(A). - - In any case, anycast addresses, multicast addresses, and the - unspecified address MUST NOT be included in a candidate set. - -2.5. Common Prefix Length - - We define the common prefix length CommonPrefixLen(A, B) of two - addresses A and B as the length of the longest prefix that the two - addresses have in common. It ranges from 0 to 128. - - We define the maximum common prefix length MaxCommonPrefixLen(A, X) - of an address A and a non-empty set of addresses X as the maximum of - CommonPrefixLen(A, B) for addresses B in the set X. - -3. Destination Address Ordering - - The destination address ordering algorithm takes a list of - destination addresses and sorts the addresses to produce a new list. - It is specified here in terms of the pair-wise comparison of - addresses DA and DB, where DA appears before DB in the original - list. - - The pair-wise comparison consists of four rules, which MUST be - applied in order. If a rule determines a result, then the remaining - rules are not relevant and MUST be ignored. Subsequent rules act as - tie-breakers for earlier rules. - - Rule 1: If MatchSrc(DA) is non-empty and MatchSrc(DB) is empty, then - sort DA before DB. Similarly, if MatchSrc(DA) is empty and - MatchSrc(DB) is non-empty, then sort DB before DA. - -Draves Standards Track - Expires May 2000 5 - -Default Address Selection for IPv6 October 22, 1999 - - - Rule 2: If Precedence(A) > Precedence(B), then sort DA before DB. - Similarly, if Precedence(B) > Precedence(A), then sort DB before DA. - - Rule 3: If MatchSrc(DA) and MatchSrc(DB) are both non-empty. If - MaxCommonPrefixLen(DA, MatchSrc(DA)) > MaxCommonPrefixLen(DB, - MatchSrc(DB)), then sort DA before DB. Similarly, if - MaxCommonPrefixLen(DB, MatchSrc(DB)) > MaxCommonPrefixLen(DA, - MatchSrc(DA)), then sort DB before DA. - - Rule 4: Sort DA before DB. - - The third and fourth rules MAY be superceded if the implementation - has other means of sorting destination addresses. For example, if - the implementation somehow knows which destination addresses will - result in the "best" communications performance. - -3.1. Candidate Source Addresses - - For the purposes of destination address ordering, the candidate set - of source addresses CandidateSrc(D) for a destination address D - SHOULD contain all and only the unicast addresses assigned to - interfaces that might be used to send to the destination D. - - For example, if the address D is a link-local unicast address that - is qualified with a scope-id value specifying a particular - interface, then CandidateSrc(D) SHOULD contain all and only the - unicast addresses assigned to that interface. - - For example, if the address D is a global scope unicast address, - then CandidateSrc(D) MAY contain every unicast address assigned to - all interfaces. However if the implementation wishes to consult a - routing table and determine a likely outgoing interface, then - CandidateSrc(D) MAY contain only unicast addresses assigned to that - outgoing interface. - -4. Source Address Selection - - The source address selection algorithm chooses a source address for - use with a destination address D. It is specified here in terms of - the pair-wise comparison of addresses SA and SB. The pair-wise - comparison can be used to select an address from the set - CandidateSrc(D). - - The pair-wise comparison consists of six rules, which MUST be - applied in order. If a rule chooses an address, then the remaining - rules are not relevant and MUST be ignored. Subsequent rules act as - tie-breakers for earlier rules. If the six rules fail to choose an - address, some unspecified tie-breaker MUST be used. - - Rule 1: If SA is in MatchSrc(D) and SB is not, then choose SA. - Similarly, if SB is in MatchSrc(D) and SA is not, then choose SB. - - - -Draves Standards Track - Expires May 2000 6 - -Default Address Selection for IPv6 October 22, 1999 - - - Rule 2: If SA is equal to D, then choose SA. Similarly, if SB is - equal to D, then choose SB. - - Rule 3a: If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then - choose SB. Otherwise, if one of the source addresses is "preferred" - and one of them is "deprecated", then choose the "preferred" - address. Otherwise, choose SA. - - Rule 3b: Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < - Scope(D), then choose SA. Otherwise, if one of the source addresses - is "preferred" and one of them is "deprecated", then choose the - "preferred" address. Otherwise, choose SB. - - Rule 4: The addresses SA and SB have the same scope. If one of the - source addresses is "preferred" and one of them is "deprecated", an - implementation MUST choose the one that is preferred. - - Rule 5: If Label(SA) = MatchSrcLabel(D) and Label(SB) <> - MatchSrcLabel(D), then choose SA. Similarly, if Label(SA) <> - MatchSrcLabel(D) and Label(SB) = MatchSrcLabel(D), then choose SB. - (Note that this rule will apply only when both SA and SB are - deprecated.) - - Rule 6: If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then - choose SA. Similarly, if CommonPrefixLen(SB, D) > - CommonPrefixLen(SA, D), then choose SB. - - The sixth rule MAY be superceded if the implementation has other - means of choosing among source addresses. For example, if the - implementation somehow knows which source address will result in the - "best" communications performance. - -4.1. Candidate Source Addresses - - For the purposes of source address selection, the candidate set of - source addresses CandidateSrc(D) for a destination address D MUST - contain all and only the unicast addresses assigned to the interface - that will be used to send to the destination D. - -5. Interactions with Routing - - All IPv6 nodes, including both hosts and routers, MUST conform to - this specification. - - This specification of source address selection implies that routing - (more precisely, selecting an outgoing interface on a node with - multiple interfaces) is done before source address selection. - However, implementations MAY use source address considerations as a - tiebreaker when choosing among otherwise equivalent routes. - - For example, suppose a node has interfaces on two different links, - with both links having a working default router. One of the - interfaces has a preferred global address and the other interface - -Draves Standards Track - Expires May 2000 7 - -Default Address Selection for IPv6 October 22, 1999 - - - only has a deprecated global address. When sending to a global - destination address, if there's no routing reason to prefer one - interface over the other, then an implementation MAY preferentially - choose the outgoing interface that will allow it to use the - preferred global source address. - -6. Interactions with Mobility - - TBD - -7. Implementation Considerations - - The destination address ordering algorithm needs information about - potential source addresses. One possible implementation strategy is - for getipnodebyname() and getaddrinfo() to call down to the IPv6 - network layer with a list of destination addresses, sort the list in - the network layer with full current knowledge of available source - addresses, and return the sorted list to getipnodebyname() or - getaddrinfo(). This is simple but it introduces overhead. - - Another implementation strategy is to call down to the network layer - to retrieve source address information and then sort the list of - addresses directly in the context of getipnodebyname() or - getaddrinfo(). To reduce overhead in this approach, the source - address information SHOULD be cached, amortizing the overhead of - retrieving it across multiple calls to getipnodebyname() and - getaddrinfo(). If an implementation uses cached and possibly stale - source address information in its implementation of destination - address ordering, then it MUST ensure that the source address - information is no more than one second out of date. - -8. Security Considerations - - This document has no direct impact on Internet infrastructure - security. - -References - - 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", - RFC 2373, July 1998. - - 3 S. Thompson, T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462 , December 1998. - - 4 S. Bradner, "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - 5 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket - Interface Extensions for IPv6", RFC 2553, March 1999. - - -Draves Standards Track - Expires May 2000 8 - - - -Acknowledgments - - The author would like to acknowledge the contributions of the IPng - Working Group. - -Author's Address - - Richard Draves - Microsoft Research - One Microsoft Way - Redmond, WA 98052 - Email: richdr@microsoft.com - -Revision History - -Changes from draft-draves-ipngw-simple-srcaddr-01 - - Added framework discussion. - - Added algorithm for destination address ordering. - - Added mechanism to allow the specification of administrative policy - that can override the default behavior. - - Added section on routing interactions and TBD section on mobility - interactions. - - Changed the candidate set definition for source address selection, - so that only addresses assigned to the outgoing interface are - allowed. - - Changed the loopback address treatment to link-local scope. - -Changes from draft-draves-ipngw-simple-srcaddr-00 - - Minor wording changes because DHCPv6 also supports "preferred" and - "deprecated" addresses. - - Specified treatment of other format prefixes; now they are - considered global scope, "preferred" addresses. - - Reiterated that anycast and multicast addresses are not allowed as - source addresses. - - Recommended that source addresses be taken from the outgoing - interface. Required this for multicast destinations. Added analogous - requirements for link-local and site-local destinations. - - Specified treatment of the loopback address. - - Changed the second selection rule so that if both candidate source - addresses have scope greater or equal than the destination address - and only of them is preferred, the preferred address is chosen. - - -Draves Standards Track - Expires May 2000 9 - -Default Address Selection for IPv6 October 22, 1999 - - - Full Copyright Statement - - Copyright (C) The Internet Society (1999). 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 implementation 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Draves Standards Track - Expires May 2000 10 - diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt new file mode 100644 index 0000000000..2047267e91 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt @@ -0,0 +1,695 @@ + + +IPng Working Group Richard Draves +Internet Draft Microsoft Research +Document: draft-ietf-ipngwg-default-addr-select-01.txt July 14, 2000 +Category: Standards Track + + Default Address Selection for IPv6 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026 [1]. + + 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. + +Abstract + + This document describes two algorithms, for source address selection + and for destination address selection. The algorithms specify + default behavior for all IPv6 implementations. They do not override + choices made by applications or upper-layer protocols, nor do they + preclude the development of more advanced mechanisms for address + selection. The two algorithms share a common framework, including an + optional mechanism for allowing administrators to provide policy + that can override the default behavior. In dual stack + implementations, the framework allows the destination address + selection algorithm to consider both IPv4 and IPv6 addresses - + depending on the available source addresses, the algorithm might + prefer IPv6 addresses over IPv4 addresses, or vice-versa. + +1. Introduction + + The IPv6 addressing architecture [2] allows multiple unicast + addresses to be assigned to interfaces. These addresses may have + different reachability scopes (link-local, site-local, or global). + These addresses may also be "preferred" or "deprecated" [3]. Privacy + considerations have introduced the concepts of "public addresses" + and "anonymous addresses" [4]. The mobility architecture introduces + "home addresses" and "care-of addresses" [5]. In addition, multi- + homing situations will result in more addresses per node. For + +Draves Standards Track - Expires January 2001 1 +Default Address Selection for IPv6 July 14, 2000 + + + example, a node may have multiple interfaces, some of them tunnels + or virtual interfaces, or a site may have multiple ISP attachments + with a global prefix per ISP. + + The end result is that IPv6 implementations will very often be faced + with multiple possible source and destination addresses when + initiating communication. It is desirable to have simple default + algorithms, common across all implementations, for selecting source + and destination addresses so that developers and administrators can + reason about and predict the behavior of their systems. + + Furthermore, dual or hybrid stack implementations, which support + both IPv6 and IPv4, will very often need to choose between IPv6 and + IPv4 when initiating communication. For example, when DNS name + resolution yields both IPv6 and IPv4 addresses and the network + protocol stack has available both IPv6 and IPv4 source addresses. In + such cases, a simple policy to always prefer IPv6 or always prefer + IPv4 can produce poor behavior. As one example, suppose a DNS name + resolves to a global IPv6 address and a global IPv4 address. If the + node has assigned a global IPv6 address and a 169.254/16 "autonet" + IPv4 address, then IPv6 is the best choice for communication. But if + the node has assigned only a link-local IPv6 address and a global + IPv4 address, then IPv4 is the best choice for communication. The + destination address selection algorithm solves this with a unified + procedure for choosing among both IPv6 and IPv4 addresses. + + This document specifies source address selection and destination + address selection separately, but using a common framework so that + together the two algorithms yield useful results. The algorithms + attempt to choose source and destination addresses of appropriate + scope and configuration status (preferred or deprecated). + Furthermore, this document suggests a preferred method, longest + matching prefix, for choosing among otherwise equivalent addresses + in the absence of better information. + + The framework also has policy hooks to allow administrative override + of the default behavior. For example, using these hooks an + administrator can specify a preferred source prefix for use with a + destination prefix, or prefer destination addresses with one prefix + over addresses with another prefix. These hooks give an + administrator flexibility in dealing with some multi-homing and + transition scenarios, but they are certainly not a panacea. + + The rules specified in this document MUST NOT be construed to + override an application or upper-layer's explicit choice of + destination or source address. + +1.1. 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 RFC-2119 [6]. + + +Draves Standards Track - Expires May 2000 2 +Default Address Selection for IPv6 July 14, 2000 + + +2. Framework + + Our framework for address selection derives from the most common + implementation architecture, which separates the choice of + destination address from the choice of source address. Consequently, + the framework specifies two separate algorithms for these tasks. The + algorithms are designed to work well together and they share a + mechanism for administrative policy override. + + In this implementation architecture, applications use APIs [7] like + getaddrinfo() and getipnodebyname() that return a list of addresses + to the application. This list might contain both IPv6 and IPv4 + addresses (sometimes represented as IPv4-mapped addresses). The + application then passes a destination address to the network stack + with connect() or sendto(). The application might use only the first + address in the list, or it might loop over the list of addresses to + find a working address. In any case, the network layer is never in a + situation where it needs to choose a destination address from + several alternatives. The application might also specify a source + address with bind(), but often the source address is left + unspecified. Therefore the network layer does often choose a source + address from several alternatives. + + As a consequence, we intend that implementations of getaddrinfo() + and getipnodebyname() will use the destination address selection + algorithm specified here to sort the list of IPv6 and IPv4 addresses + that they return. Separately, the IPv6 network layer will use the + source address selection algorithm when an application or upper- + layer has not specified a source address. Application of this + framework to source address selection in an IPv4 network layer may + be possible but this is not explored further here. + + The algorithms use several criteria in making their decisions. The + combined effect is to prefer destination/source address pairs for + which the two addresses are of equal scope or type, prefer smaller + scopes over larger scopes for the destination address, prefer non- + deprecated source addresses of sufficient scope to reach the + destination, avoid the use of transitional addresses when native + addresses are available, and all else being equal prefer address + pairs having the longest possible common prefix. For source address + selection, an anonymous address [4] is preferred over its + corresponding public address. In mobile situations [5], home + addresses are preferred over care-of addresses. + + The framework optionally allows for the possibility of + administrative configuration of policy that can override the default + behavior of the algorithms. The policy override takes the form of a + configurable table that provides precedence values and preferred + source prefixes for destination prefixes. If an implementation is + not configurable, or if an implementation has not been configured, + then the default policy table specified in this document SHOULD be + used. + + +Draves Standards Track - Expires May 2000 3 +Default Address Selection for IPv6 July 14, 2000 + + +2.1. Scope Comparisons + + Multicast destination addresses have a 4-bit scope field that + controls the propagation of the multicast packet. The IPv6 + addressing architecture defines scope field values for node-local + (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), + and global (0xE) scopes. + + Use of the source address selection algorithm in the presence of + multicast destination addresses requires the comparison of a unicast + address scope with a multicast address scope. We map unicast link- + local to multicast link-local, unicast site-local to multicast site- + local, and unicast global scope to multicast global scope. For + example, unicast site-local is equal to multicast site-local, which + is smaller than multicast organization-local, which is smaller than + unicast global, which is equal to multicast global. + + We write Scope(A) to mean the scope of address A. For example, if A + is a link-local unicast address and B is a site-local multicast + address, then Scope(A) < Scope(B). + + This mapping implicitly conflates unicast site boundaries and + multicast site boundaries. + +2.2. IPv4-Compatible Addresses and Other Format Prefixes + + For the purposes of this document, IPv4-compatible addresses have + global scope and "preferred" configuration status. + + Similarly, NSAP addresses, IPX addresses, or addresses with as-yet- + undefined format prefixes should be treated as having global scope + and "preferred" configuration status. Later standards may supercede + this treatment. + + The loopback address should be treated as having link-local scope + and "preferred" configuration status. + +2.3. IPv4 Addresses and IPv4-Mapped Addresses + + The destination address selection algorithm operates on both IPv6 + and IPv4 addresses. For this purpose, IPv4 addresses should be + represented as IPv4-mapped addresses. For example, to lookup the + precedence or other attributes of an IPv4 address in the policy + table, lookup the corresponding IPv4-mapped IPv6 address. + +2.4. Policy Table + + The policy table is a longest-matching-prefix lookup table, much + like a routing table. Given an address A, a lookup in the policy + table produces three values: a precedence value Precedence(A), a + classification or label Label(A), and a second label + MatchSrcLabel(A). + + +Draves Standards Track - Expires May 2000 4 +Default Address Selection for IPv6 July 14, 2000 + + + The precedence value Precedence(A) is used for sorting destination + addresses. If Precedence(A) > Precedence(B), we say that address A + has higher precedence than address B, meaning that our algorithm + will prefer to sort destination address A before destination address + B. + + The labels Label(A) and MatchSrcLabel(A) allow for policies that + prefer a particular source address prefix for use with a destination + address prefix. The algorithms prefer to use a source address S with + a destination address D if Label(S) = MatchSrcLabel(D). + + IPv6 implementations SHOULD support configurable address selection + via a mechanism at least as powerful as the policy tables defined + here. If an implementation is not configurable or has not been + configured, then it SHOULD operate according to the algorithms + specified here in conjunction with the following default policy + table: + + Prefix Precedence Label MatchSrcLabel + ::1/128 100 1 1 + fe80::/10 90 2 2 + fec0::/10 80 3 3 + ::/0 70 4 4 + 2002::/16 60 5 5 + ::/96 50 6 6 + ::ffff:169.254.0.0/112 30 7 7 + ::ffff:10.0.0.0/104 20 8 8 + ::ffff:172.16.0.0/108 20 9 9 + ::ffff:192.168.0.0/112 20 10 10 + ::ffff:0:0/96 10 11 11 + + One effect of the default policy table is to prefer using native + source addresses with native destination addresses, 6to4 source + addresses with 6to4 destination addresses, and v4-compatible source + addresses with v4-compatible destination addresses. Another effect + of the default policy table is to prefer communication using IPv6 + addresses to communication using IPv4 addresses, if matching source + addresses are available. + + Policy table entries for scoped address prefixes MAY be qualified + with an optional scope-id. If so, a prefix table entry only matches + against an address during a lookup if the scope-id also matches the + address's scope-id. + +2.5. Common Prefix Length + + We define the common prefix length CommonPrefixLen(A, B) of two + addresses A and B as the length of the longest prefix (looking at + the most significant, or leftmost, bits) that the two addresses have + in common. It ranges from 0 to 128. + + + + +Draves Standards Track - Expires May 2000 5 +Default Address Selection for IPv6 July 14, 2000 + + +3. Candidate Source Addresses + + The source address selection algorithm uses the concept of a + "candidate set" of potential source addresses for a given + destination address. We write CandidateSource(A) to denote the + candidate set for the address A. + + It is RECOMMENDED that the candidate source addresses be the set of + unicast addresses assigned to the interface that will be used to + send to the destination. (The "outgoing" interface.) On routers, the + candidate set MAY include unicast addresses assigned to any + interface that could forward the destination address to the outgoing + interface. + + In some cases the destination address may be qualified with a scope- + id or other information that will constrain the candidate set. + + For multicast and link-local destination addresses, the set of + candidate source addresses MUST only include addresses assigned to + interfaces belonging to the same link as the outgoing interface. + + For site-local destination addresses, the set of candidate source + addresses MUST only include addresses assigned to interfaces + belonging to the same site as the outgoing interface. + + In any case, anycast addresses, multicast addresses, and the + unspecified address MUST NOT be included in a candidate set. + +4. Source Address Selection + + The source address selection algorithm chooses a source address for + use with a destination address D. It is specified here in terms of + the pair-wise comparison of addresses SA and SB. The pair-wise + comparison can be used to select an address from the set + CandidateSource(D). + + The pair-wise comparison consists of eight rules, which MUST be + applied in order. If a rule chooses an address, then the remaining + rules are not relevant and MUST be ignored. Subsequent rules act as + tie-breakers for earlier rules. If the eight rules fail to choose an + address, some unspecified tie-breaker must be used. + + Rule 1: Prefer same address. + If SA = D, then choose SA. Similarly, if SB = D, then choose SB. + + Rule 2: Prefer matching label. + If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), + then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and + Label(SA) <> MatchSrcLabel(D), then choose SB. + + + + + +Draves Standards Track - Expires May 2000 6 +Default Address Selection for IPv6 July 14, 2000 + + + Rule 3: Prefer appropriate scope. + If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB. + Otherwise, if one of the source addresses is "preferred" and one of + them is "deprecated", then choose the "preferred" address. + Otherwise, choose SA. + Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then + choose SA. Otherwise, if one of the source addresses is "preferred" + and one of them is "deprecated", then choose the "preferred" + address. Otherwise, choose SB. + + Rule 4: Avoid deprecated addresses. + The addresses SA and SB have the same scope. If one of the source + addresses is "preferred" and one of them is "deprecated", an + implementation MUST choose the one that is preferred. + + Rule 5: Prefer home addresses. + If SA is a home address and SB is a care-of address, then prefer SA. + Similarly, if SB is a home address and SA is a care-of address, then + prefer SB. + An implementation MAY support a per-connection configuration + mechanism (for example, a socket option) to reverse the sense of + this preference and prefer care-of addresses over home addresses. + + Rule 6: Prefer outgoing interface. + If SA is assigned to the interface that will be used to send to D + and SB is assigned to a different interface, then prefer SA. + Similarly, if SB is assigned to the interface that will be used to + send to D and SA is assigned to a different interface, then prefer + SB. + + Rule 7: Prefer anonymous addresses. + If SA is an anonymous address and SB is its corresponding public + address, then prefer SA. Similarly, if SB is an anonymous address + and SA is its corresponding public address, then prefer SB. + An implementation MAY support a per-connection configuration + mechanism (for example, a socket option) to reverse the sense of + this preference and prefer public addresses over anonymous + addresses. + + Rule 8: Use longest matching prefix. + If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. + Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then + choose SB. + + Rule 8 MAY be superceded if the implementation has other means of + choosing among source addresses. For example, if the implementation + somehow knows which source address will result in the "best" + communications performance. + +5. Destination Address Selection + + The destination address selection algorithm takes a list of + destination addresses and sorts the addresses to produce a new list. + +Draves Standards Track - Expires May 2000 7 +Default Address Selection for IPv6 July 14, 2000 + + + It is specified here in terms of the pair-wise comparison of + addresses DA and DB, where DA appears before DB in the original + list. + + The destination address selection algorithm uses the source address + selection algorithm as a subroutine. We write Source(D) to indicate + the selected source address for a destination D. + + The pair-wise comparison of destination addresses consists of four + rules, which MUST be applied in order. If a rule determines a + result, then the remaining rules are not relevant and MUST be + ignored. Subsequent rules act as tie-breakers for earlier rules. + + Rule 1: Prefer destinations with a matching source. + If Label(Source(DA)) = MatchSrcLabel(DA) and Label(Source(DB)) <> + MatchSrcLabel(DB), then sort DA before DB. Similarly, if + Label(Source(DB)) = MatchSrcLabel(DB) and Label(Source(DA)) <> + MatchSrcLabel(DA), then sort DB before DA. + + Rule 2: Prefer higher precedence. + If Precedence(DA) > Precedence(DB), then sort DA before DB. + Similarly, if Precedence(DB) > Precedence(DA), then sort DB before + DA. + + Rule 3: Use longest matching prefix. + Applies only if Label(Source(DA)) = MatchSrcLabel(DA) and + Label(Source(DB)) = MatchSrcLabel(DB). + If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, + Source(DB)), then sort DA before DB. Similarly, if + CommonPrefixLen(DB, Source(DB)) > CommonPrefixLen(DA, Source(DA)), + then sort DB before DA. + + Rule 4: Otherwise, leave the order unchanged. + Sort DA before DB. + + The third and fourth rules MAY be superceded if the implementation + has other means of sorting destination addresses. For example, if + the implementation somehow knows which destination addresses will + result in the "best" communications performance. + +6. Interactions with Routing + + All IPv6 nodes, including both hosts and routers, SHOULD conform to + this specification. + + This specification of source address selection assumes that routing + (more precisely, selecting an outgoing interface on a node with + multiple interfaces) is done before source address selection. + However, implementations MAY use source address considerations as a + tiebreaker when choosing among otherwise equivalent routes. + + For example, suppose a node has interfaces on two different links, + with both links having a working default router. Both of the + +Draves Standards Track - Expires May 2000 8 +Default Address Selection for IPv6 July 14, 2000 + + + interfaces have preferred global addresses. When sending to a global + destination address, if there's no routing reason to prefer one + interface over the other, then an implementation MAY preferentially + choose the outgoing interface that will allow it to use the source + address that shares a longer common prefix with the destination. + +7. Implementation Considerations + + The destination address selection algorithm needs information about + potential source addresses. One possible implementation strategy is + for getipnodebyname() and getaddrinfo() to call down to the IPv6 + network layer with a list of destination addresses, sort the list in + the network layer with full current knowledge of available source + addresses, and return the sorted list to getipnodebyname() or + getaddrinfo(). This is simple and gives the best results but it + introduces the overhead of another system call. One way to reduce + this overhead is to cache the sorted address list in the resolver, + so that subsequent calls for the same name do not need to resort the + list. + + Another implementation strategy is to call down to the network layer + to retrieve source address information and then sort the list of + addresses directly in the context of getipnodebyname() or + getaddrinfo(). To reduce overhead in this approach, the source + address information can be cached, amortizing the overhead of + retrieving it across multiple calls to getipnodebyname() and + getaddrinfo(). + + In any case, if the implementation uses cached and possibly stale + information in its implementation of destination address selection, + or if the ordering of a cached list of destination addresses is + possibly stale, then it MUST ensure that the destination address + ordering returned to the application is no more than one second out + of date. For example, an implementation might make a system call to + check if any routing table entries or source address assignments + that might affect these algorithms have changed. + +8. Security Considerations + + This document has no direct impact on Internet infrastructure + security. + +References + + 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998. + + 3 S. Thompson, T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462 , December 1998. + + +Draves Standards Track - Expires May 2000 9 +Default Address Selection for IPv6 July 14, 2000 + + + + 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address + Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy- + 01.txt, July 2000. + + 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- + mobileip-ipv6-12.txt, April 2000. + + 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + 7 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket + Interface Extensions for IPv6", RFC 2553, March 1999. + +Acknowledgments + + The author would like to acknowledge the contributions of the IPng + Working Group. + +Author's Address + + Richard Draves + Microsoft Research + One Microsoft Way + Redmond, WA 98052 + Phone: 1-425-936-2268 + Email: richdr@microsoft.com + +Revision History + +Changes from draft-ietf-ipngwg-default-addr-select-00 + + Changed the candidate set definition so that the strong host model + is recommended but not required. Added a rule to source address + selection to prefer addresses assigned to the outgoing interface. + + Simplified the destination address selection algorithm, by having it + use source address selection as a subroutine. + + Added a rule to source address selection to handle anonymous/public + addresses. + + Added a rule to source address selection to handle home/care-of + addresses. + + Changed to allow destination address selection to sort both IPv6 and + IPv4 addresses. Added entries in the default policy table for IPv4- + mapped addresses. + + Changed default precedences, so v4-compatible addresses have lower + precedence than 6to4 addresses. + + + +Draves Standards Track - Expires May 2000 10 +Default Address Selection for IPv6 July 14, 2000 + + +Changes from draft-draves-ipngwg-simple-srcaddr-01 + + Added framework discussion. + + Added algorithm for destination address ordering. + + Added mechanism to allow the specification of administrative policy + that can override the default behavior. + + Added section on routing interactions and TBD section on mobility + interactions. + + Changed the candidate set definition for source address selection, + so that only addresses assigned to the outgoing interface are + allowed. + + Changed the loopback address treatment to link-local scope. + +Changes from draft-draves-ipngwg-simple-srcaddr-00 + + Minor wording changes because DHCPv6 also supports "preferred" and + "deprecated" addresses. + + Specified treatment of other format prefixes; now they are + considered global scope, "preferred" addresses. + + Reiterated that anycast and multicast addresses are not allowed as + source addresses. + + Recommended that source addresses be taken from the outgoing + interface. Required this for multicast destinations. Added analogous + requirements for link-local and site-local destinations. + + Specified treatment of the loopback address. + + Changed the second selection rule so that if both candidate source + addresses have scope greater or equal than the destination address + and only of them is preferred, the preferred address is chosen. + + + + + + + + + + + + + + + + +Draves Standards Track - Expires May 2000 11 +Default Address Selection for IPv6 July 14, 2000 + + + Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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 implementation 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Draves Standards Track - Expires May 2000 12 \ No newline at end of file diff --git a/doc/draft/draft-skwan-gss-tsig-05.txt b/doc/draft/draft-skwan-gss-tsig-05.txt deleted file mode 100644 index 0dc51507ca..0000000000 --- a/doc/draft/draft-skwan-gss-tsig-05.txt +++ /dev/null @@ -1,738 +0,0 @@ -INTERNET-DRAFT Stuart Kwan - Praerit Garg - James Gilroy - Microsoft Corp. - February 2000 - Expires August 2000 - - - GSS Algorithm for TSIG (GSS-TSIG) - - -Status of this Memo - -This document is an Internet-Draft and is in full conformance -with all provisions of Section 10 of RFC2026. - -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. - - -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 August 2000 [Page 1] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -Table of Contents - -1: Introduction......................................................2 -2: Protocol Overview.................................................3 - 2.1: GSS Details...................................................4 -3: Client Protocol Details...........................................4 - 3.1: Negotiating Context...........................................4 - 3.1.1: Call GSS_Init_sec_context.................................5 - 3.1.2: Send TKEY Query to Server.................................6 - 3.1.3: Receive TKEY Query-Response from Server...................6 - 3.2: Context Established...........................................8 -4: Server Protocol Details...........................................8 - 4.1: Negotiating Context...........................................8 - 4.1.1: Receive TKEY Query from Client............................9 - 4.1.2: Call GSS_Accept_sec_context...............................9 - 4.1.3: Send TKEY Query-Response to Client........................9 - 4.2: Context Established..........................................10 - 4.2.1: Terminating a Context....................................10 -5: Sending and Verifying Signed Messages............................11 - 5.1: Sending a Signed Message - Call GSS_GetMIC...................11 - 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............12 -6: Security Considerations..........................................12 -7: Acknowledgements.................................................13 -8: References.......................................................13 - - -1. Introduction - -The Secret Key Transaction Signature for DNS [TSIG] protocol was -developed to provide a lightweight alternative to full DNS security -[RFC2535] and secure dynamic update [RFC2137], where full security is -impractical due to implementation complexity, management overhead, or -computational 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 August 2000 [Page 2] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -* 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. - - -2. Protocol Overview - -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. - -In GSS, client and server interact to create a "security context". -The security context is used to create and verify transaction -signatures on messages between the two parties. A unique security -context is required for each unique connection between client and -server. - -Creating a security context involves a negotiation between client and -server. Once a context has been established, it has a finite lifetime -for which it can be used to secure messages. Thus there are three -states of a context associated with a connection: - - - +----------+ - | | - V | - +---------------+ | - | Uninitialized | | - | | | - +---------------+ | - | | - V | - +---------------+ | - | Negotiating | | - | Context | | - +---------------+ | - | | - V | - +---------------+ | - | Context | | - | Established | | - +---------------+ | - | | - +----------+ - -Every connection begins in the uninitialized state. - - - -Expires August 2000 [Page 3] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -2.1 GSS Details - -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 caller should act -appropriately. - - -3. Client Protocol Details - -A unique context is required for each server to which the client sends -secure messages. A context is identified by a context handle. A -client maintains a mapping of handles to servers, - - (target_server_name, key_name, context_handle) - -The value key_name also identifies a context handle, and is used on -the wire to indicate to a server which context should be used to -process the current request. - - -3.1 Negotiating Context - -In GSS, establishing a security context involves the passing of opaque -tokens between the client and the server. The client generates the -initial token and sends it to the server. The server processes the -token and if necessary, returns a subsequent token to the client. The -client processes this token, and so on, until the negotiation is -complete. The number of times the client and server exchange tokens -depends on the underlying security mechanism. A completed negotiation -results in a context handle. - -The TKEY resource record [TKEY] is used as the vehicle to transfer -tokens between client and server. The TKEY record is a general -mechanism for establishing secret keys for use with TSIG. For more -information, see [TKEY]. - - - - - - - - - -Expires August 2000 [Page 4] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -3.1.1 Call GSS_Init_sec_context - -The client obtains the first token by calling GSS_Init_sec_context. -The following input parameters are used. The outcome of the call -is indicated with the output values below. Consult [RFC2078] for -syntax definitions. - - INPUTS - CONTEXT HANDLE input_context_handle = 0 - INTERNAL NAME targ_name = DNS/ - OCTET STRING input_token = NULL - BOOLEAN replay_det_req_flag = TRUE - BOOLEAN mutual_req_flag = TRUE - BOOLEAN deleg_req_flag = TRUE (optional) - - OUTPUTS - INTEGER major_status - CONTEXT HANDLE output_context_handle - OCTET STRING output_token - BOOLEAN replay_det_state - BOOLEAN mutual_state - -The values of replay_det_state and mutual_state indicate if the -security package can provide replay detection and mutual -authentication, respectively. If one or both of these values -are FALSE, the client must abandon this protocol. - -The deleg_req_flag is optional, and can be used if the client wants -the server to be able to call out to other services under the -context of the client. - -If major_status indicates an error, the client must abandon the -protocol. Success values of major_status are GSS_S_CONTINUE_NEEDED -and GSS_S_COMPLETE. The exact success code is important during later -processing. - -The handle output_context_handle is unique to this negotiation and -is stored in the client's mapping table as the context_handle that -maps to target_server_name. - - - - - - - - - - - - -Expires August 2000 [Page 5] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -3.1.2 Send TKEY Query to Server - -The output_token from GSS_Init_sec_context is transmitted to the -server in a query request for a TKEY record. The token itself -will be placed in a TKEY record in the additional records section of -the query. The domain-like name of the TKEY record set queried for -and the name of the supplied TKEY record in the additional section -will uniquely identify the security context to both the client and -server, and thus the client should use a value which is globally -unique. - - TKEY Record - NAME = client-generated globally unique domain name string - (see [TKEY]) - RDATA - Algorithm Name = gss-tsig.microsoft.com - Mode = 3 (GSS-API negotiation - see [TKEY]) - Key Size = size of output_token - Key = output_token - -Assign the remaining fields in the TKEY RDATA appropriate values -per [TKEY]. - -If the last call to GSS_Init_sec_context yielded a major_status value -of GSS_S_COMPLETE, then the message should be signed with a TSIG -record before being sent to the server. See section 5, Sending -and Verifying Signed Messages, for the signing procedure. - -The query is transmitted to the server. - - -3.1.3 Receive TKEY Query-Response from Server - -The server will return a standard TKEY query-response (see [TKEY]). -The response may indicate that TKEY is not supported, or that the -GSS-API mode and algorithm are not supported. If this is the case, -the client must abandon this algorithm. - -If the value of the Error field in the TKEY RDATA (TKEY.Error) is -BADKEY, then the token provided by the client was invalid. The -client must abandon this algorithm. - -If TKEY.Error indicates success, then the client may continue. The -next processing step depends on the value of major_status from the -most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or -GSS_S_CONTINUE. - - - - - -Expires August 2000 [Page 6] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -3.1.3.1 Value of major_status == GSS_S_COMPLETE - -If the last call to GSS_Init_sec_context yielded a major_status value -of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, -then the client side component of the negotiation is complete and the -client is awaiting confirmation from the server. - -Confirmation will be in the form of a NOERROR query response -containing the last client supplied TKEY record in the answer section -of the query. The response may also be signed with a TSIG record, -and if present this signature must be verified using the procedure -detailed in section 5, Sending and Verifying Signed Messages. - -If the message verification completes without an error, or if a TSIG -signature was not included, the context state is advanced to Context -Established. Proceed to section 3.2 for usage of the security -context. - - -3.1.3.2 Value of major_status == GSS_S_CONTINUE - -If the last call to GSS_Init_sec_context yielded a major_status value -of GSS_S_CONTINUE, then the negotiation is not yet complete. The -server will respond to the TKEY query with a NOERROR query response -that contains a TKEY record in the answer section. The TKEY record -contains a token that is passed to GSS_Init_sec_context using the -parameters from the previous call and the following modifications: - - INPUTS - CONTEXT HANDLE input_context_handle = context_handle - OCTET STRING input_token = token from Key field of - TKEY record - - OUTPUTS - INTEGER major_status - OCTET STRING output_token - -If major_status indicates an error, the client must abandon this -algorithm. Success values are GSS_S_CONTINUE and GSS_S_COMPLETE. - -If major_status is GSS_S_CONTINUE the negotiation is not yet -finished. The token output_token must again be passed to the server -in a TKEY record. The negotiation sequence is repeated beginning -with section 3.1.2. The client should place a limit on the number -of continuations in a context negotiation to prevent endless -looping. - - - - - -Expires August 2000 [Page 7] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -If major_status is GSS_S_COMPLETE and output_token is non-NULL, -the client-side component of the negotiation is complete but the -token output_token must be passed to the server. The negotiation -sequence is repeated beginning with section 3.1.2. - -If major_status is GSS_S_COMPLETE and output_token is NULL, context -negotiation is complete. The response from the server may be signed -with a TSIG record, and if present this signature must be verified -using the procedure detailed in section 5, Sending and -Verifying Signed Messages. - -If the message verification completes without an error, or if a TSIG -signature was not included, the context state is advanced to Context -Established. Proceed to section 3.2 for usage of the security -context. - - -3.2 Context Established - -When context negotiation is complete, the handle context_handle is -used for the generation and verification of transaction signatures. - -The procedures for sending and receiving signed messages are given in -section 5, Sending and Verifying Signed Messages. - - -4. Server Protocol Details - -As on the client-side, the result of a successful context negotiation -is a context handle used in future processing. - -A server may be managing several contexts with several clients. -Clients identify their contexts by providing a key name in their -request. The server maintains a mapping of key names to handles: - - (key_name, context_handle) - - -4.1 Negotiating Context - -A server recognizes TKEY queries as security context negotiation -messages. - - - - - - - - - -Expires August 2000 [Page 8] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -4.1.1 Receive TKEY Query from Client - -Upon receiving a TKEY query, the server must examine the Mode and -Algorithm Name fields to see if they match this algorithm. If they -match, the (key_name, context_handle) mapping table is searched for -the NAME value of the TKEY record. If the name is found in the table, -the corresponding context_handle is used in following GSS operations. -If the name is not found a new negotiation is started. - - -4.1.2 Call GSS_Accept_sec_context - -The server performs its side of a context negotiation by calling -GSS_Accept_sec_context with the token provided by the client in the -TKEY record. - -The server calls GSS_Accept_sec_context: - - INPUTS - CONTEXT HANDLE input_context_handle = 0 if new negotiation, - context_handle if ongoing - OCTET STRING input_token = Key field from TKEY RR - - OUTPUTS - INTEGER major_status - CONTEXT_HANDLE output_context_handle - OCTET STRING output_token - -If this is the first call to GSS_Accept_sec_context in a new -negotiation, then output_context_handle is stored in the server's -key-mapping table as the context_handle that maps to the name of the -TKEY record. - - -4.1.3 Send TKEY Query-Response to Client - -If major_status returns a GSS failure code, the negotiation has -failed. The server must respond to the client with a standard -TKEY query-response where the TKEY error field value is set to -BADKEY. - -Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE. - - - - - - - - - -Expires August 2000 [Page 9] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -If major_status is GSS_S_COMPLETE the server component of the -negotiation is finished. The message from the client may be signed -with a TSIG RR, and if present this signature must be verified -using the procedure detailed in section 5, Sending and -Verifying Signed Messages. The server responds to the TKEY query -using a standard query response. If output_token is non-NULL, then it -must be returned to the client in a TKEY in the Answer section of the -response. If output_token is NULL, then the TKEY record received from -the client must be returned in the Answer section of the response. -The answer should be signed with a TSIG record per the procedure given -in section 5, Sending and Verifying Signed Messages. -The context state is advanced to Established. Section 4.2 discusses -the usage of the security context. - -If major_status is GSS_S_CONTINUE, the server component of the -negotiation is not yet finished. The server responds to the TKEY -query with a standard query response, placing a TKEY record containing -output_token in the answer section. The negotiation sequence then -repeats beginning with section 4.1.1. The server must limit the -number of times that a given context is allowed to repeat, to prevent -endless looping. - - -4.2 Context Established - -When context negotiation is complete, the handle context_handle -is used for the generation and verification of transaction signatures. -The handle is valid for a finite amount of time determined by the -underlying security mechanism. A server may unilaterally terminate -a context at any time. - -The procedures for sending and receiving signed messages are given in -section 5, Sending and Verifying Signed Messages. - - -4.2.1 Terminating a Context - -A server can terminate any established context at any time. The -server may hint to the client that the context is being deleted -by including a TKEY RR in a response with the mode field set to -"key deletion". See [TKEY] for more details. - -An active context is deleted by calling GSS_Delete_sec_context -providing the associated context_handle. - - - - - - - -Expires August 2000 [Page 10] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -5. Sending and Verifying Signed Messages - -5.1 Sending a Signed Message - Call GSS_GetMIC - -The procedure for sending a signature-protected message is specified -in [TSIG]. The data to be passed to the signature routine includes -the whole DNS message with specific TSIG variables appended. For the -exact format, see [TSIG]. For this protocol, use the following -TSIG variable values: - - TSIG Record - NAME = key_name that identifies this context - RDATA - Algorithm Name = gss-tsig.microsoft.com - -Assign the remaining fields in the TKEY RDATA appropriate values -per [TKEY]. - -For the GSS algorithm, the signature is generated by calling -GSS_GetMIC: - - INPUTS - CONTEXT HANDLE context_handle = context_handle for key_name - OCTET STRING message = outgoing message plus TSIG - variables (see [TSIG]) - - OUTPUTS - INTEGER major_status - OCTET STRING per_msg_token - -If major_status is GSS_S_COMPLETE, then signature generation -succeeded. The signature in per_msg_token is inserted into the -Signature field of the TSIG RR and the message is transmitted. - -If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED, -the caller needs to return to the uninitialized state and negotiate -a new security context. - - - - - - - - - - - - - - -Expires August 2000 [Page 11] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -5.2 Verifying a Signed Message - Call GSS_VerifyMIC - -The procedure for verifying a signature-protected message is specified -in [TSIG]. - -The NAME of the TSIG record determines which context_handle -maps to this context. If the NAME does not map to a currently active -context, the server must send a standard TSIG error response to the -client indicating BADKEY in the TSIG error field (see [TSIG]). - -For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: - - INPUTS - CONTEXT HANDLE context_handle = context_handle for key_name - OCTET STRING message = incoming message plus TSIG - variables (see [TSIG]) - OCTET STRING per_msg_token = Signature field from TSIG RR - - OUTPUTS - INTEGER major_status - -If major_status is GSS_S_COMPLETE, the signature is authentic and the -message was delivered intact. Per [TSIG], the timer values of the -TSIG record must also be valid before considering the message to be -authentic. The caller must not act on the request or response in the -message until these checks are verified. - -If major_status is GSS_S_CONTEXT_EXPIRED, the negotiated context is no -longer valid. If this failure occurs when a server is processing a -client request, the server must send a standard TSIG error response -to the client indicating BADKEY in the TSIG error field (see [TSIG]). - -If major_status is any other error code or if the timer values of the -TSIG record are invalid, the message must not be considered authentic. -If this error checking fails when a server is processing a client -request, the appropriate error response must be sent to the client -per [TSIG]. - - -6. Security Considerations - -This document describes a protocol for DNS security using GSS-API. -The security provided by this protocol is only as effective as the -security provided by the underlying GSS mechanisms. - - - - - - - -Expires August 2000 [Page 12] - - -INTERNET-DRAFT GSS-TSIG February 2000 - - -7. Acknowledgements - -The authors of this document would like to thank the following people -for their contribution to this specification: Chuck Chan, Mike Swift, -Ram Viswanathan and Donald E. Eastlake 3rd. - - -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-*..txt, ISC, TIS, Cybercash. - -[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY - RR)," draft-ietf-dnssec-tkey-*.txt. - -[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," - RFC 2535, IBM, March 1999. - -[RFC2137] D. Eastlake 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 - - -James Gilroy -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 -USA - - - - - - - - - - -Expires August 2000 [Page 13] - - diff --git a/doc/draft/draft-skwan-gss-tsig-06.txt b/doc/draft/draft-skwan-gss-tsig-06.txt new file mode 100644 index 0000000000..c760fda59c --- /dev/null +++ b/doc/draft/draft-skwan-gss-tsig-06.txt @@ -0,0 +1,11 @@ + +This document has been replaced by draft-ietf-dnsext-gss-tsig-00.txt. +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +S. Kwan: skwan@microsoft.com +J. Gilroy: jamesg@microsoft.com +P. Garg: praeritg@microsoft.com + + diff --git a/doc/draft/draft-skwan-utf8-dns-03.txt b/doc/draft/draft-skwan-utf8-dns-04.txt similarity index 89% rename from doc/draft/draft-skwan-utf8-dns-03.txt rename to doc/draft/draft-skwan-utf8-dns-04.txt index 54378038a2..d6558ee457 100644 --- a/doc/draft/draft-skwan-utf8-dns-03.txt +++ b/doc/draft/draft-skwan-utf8-dns-04.txt @@ -1,9 +1,8 @@ - INTERNET-DRAFT Stuart Kwan James Gilroy Microsoft Corp. - February 2000 - Expires August 2000 + July 2000 + Expires January 2001 Using the UTF-8 Character Set in the Domain Name System @@ -34,8 +33,8 @@ http://www.ietf.org/shadow.html. Abstract -The Domain Name System standard specifies that names are represented -using the ASCII character encoding. This document expands that +The Domain Name System standard specifies that names are represented +using the ASCII character encoding. This document expands that specification to allow the use of the UTF-8 character encoding, a superset of ASCII and a translation of the UCS-2 character encoding. @@ -50,10 +49,10 @@ superset of ASCII and a translation of the UCS-2 character encoding. -Expires August 2000 [Page 1] +Expires January 2001 [Page 1] -INTERNET-DRAFT UTF-8 DNS February 2000 +INTERNET-DRAFT UTF-8 DNS July 2000 1. Introduction @@ -106,10 +105,10 @@ UTF-8 characters before transmitting those names in any message. -Expires August 2000 [Page 2] +Expires January 2001 [Page 2] -INTERNET-DRAFT UTF-8 DNS February 2000 +INTERNET-DRAFT UTF-8 DNS July 2000 For consistency, UTF-8-aware DNS servers must compare names that @@ -152,7 +151,7 @@ containing UTF-8 names to a non-UTF-8-aware DNS server. 4. Security Considerations The choice of character encoding for names does not impact the -security of the DNS protocol. +security of the DNS protocol. 5. Acknowledgements @@ -163,10 +162,10 @@ Cliff Van Dyke and Bjorn Rettig. -Expires August 2000 [Page 3] +Expires January 2001 [Page 3] -INTERNET-DRAFT UTF-8 DNS February 2000 +INTERNET-DRAFT UTF-8 DNS July 2000 6. References @@ -174,7 +173,7 @@ INTERNET-DRAFT UTF-8 DNS February 2000 [RFC1035] P.V. Mockapetris, "Domain Names - Implementation and Specification," RFC 1035, ISI, Nov 1987. -[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode +[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646," RFC 2044, Alis Technologies, Oct 1996. [RFC1958] B. Carpenter, "Architectural Principles of the @@ -183,11 +182,11 @@ INTERNET-DRAFT UTF-8 DNS February 2000 [RFC1123] R. Braden, "Requirements for Internet Hosts - Application and Support," STD 3, RFC 1123, January 1989. -[RFC2130] C. Weider et. al., "The Report of the IAB Character - Set Workshop held 29 February - 1 March 1996", +[RFC2130] C. Weider et. al., "The Report of the IAB Character + Set Workshop held 29 July - 1 March 1996", RFC 2130, Apr 1997. -[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS +[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS Specification," RFC 2181, University of Melbourne and RGnet Inc, July 1997. @@ -220,6 +219,8 @@ USA USA -Expires August 2000 [Page 4] +Expires January 2001 [Page 4] + +