Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
updates
- rfc-2845 — Secret Key Transaction Authentication for DNS (TSIG)
Extracted elements (26)
GSS-API was chosen as the basis for this TSIG algorithm because it provides mechanism and protocol independence — the underlying security mechanism can be negotiated on the fly and varied per connection — and it removes the protocol developer from the responsibility of creating and managing a security infrastructure such as key distribution systems.
Although clients and servers MAY use various underlying security mechanisms, DNS clients and servers supporting GSS-TSIG MUST ensure that the mechanism used enables Kerberos v5. Servers must specify SPNEGO mech_type; client GSS APIs must support Kerberos v5; server GSS APIs must support both SPNEGO and Kerberos v5.
A server MUST recognize TKEY queries as security context negotiation messages. Upon receiving QTYPE=TKEY, the server MUST examine the Mode and Algorithm Name fields for values 3 and 'gss-tsig' respectively.
A server SHOULD limit the amount of memory used to cache established contexts.
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.
If GSS_Init_sec_context returns an error status, the client MUST abandon the negotiation, delete the active context via GSS_Delete_sec_context, and MAY retry. The number of attempts to establish a security context MUST be limited to ten or less to prevent infinite looping.
If GSS_Init_sec_context returns GSS_S_COMPLETE and either replay_det_state or mutual_state is FALSE, the client MUST abandon this algorithm, as replay detection and mutual authentication are required.
If the key_name in a TKEY query matches an existing established and non-expired security context, the server MUST respond with a BADNAME error in the TKEY error field.
Section 4.2 of RFC 2845 is modified to allow a server to generate a signed response to an unsigned TKEY query when a secret key is established after processing the client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of the individual secret key establishment algorithm.
The owner name of the TKEY resource record queried for and the owner name of the supplied TKEY record in the additional records section MUST be the same. The client SHOULD use a globally unique value, which MAY contain a UUID/GUID.
The server MUST limit the number of times a given context negotiation is allowed to repeat to prevent endless looping; this limit SHOULD NOT exceed 10.
To guarantee interoperability between DNS clients and servers supporting GSS-TSIG, DNS servers MUST specify SPNEGO mech_type, and GSS APIs called by both client and server MUST support Kerberos v5. The client's GSS API MUST also support Kerberos v5.
To obtain the first token to send to a server, a client MUST call GSS_Init_sec_context with specific required parameters including replay_det_req_flag=TRUE, mutual_req_flag=TRUE, and integ_req_flag=TRUE.
To sign a message, GSS_GetMIC MUST be called with the context_handle for key_name and the outgoing message plus TSIG variables. If major_status is GSS_S_COMPLETE, the per_msg_token is inserted into the Signature field of the TSIG RR.
When context negotiation is complete, the context_handle MUST be used for generation and verification of transaction signatures as described in Section 5.
When GSS_Accept_sec_context returns GSS_S_COMPLETE with a non-NULL output_token, the server MUST return it to the client in the Key Data field of the TKEY RDATA, and the response message MUST be signed with a TSIG record.
When GSS_S_COMPLETE was the last major_status and a non-NULL token was sent, the server's confirmation response MUST be signed with a TSIG record. If the response is not signed or the signature is invalid, the client MAY continue waiting for a valid response within a locally specified time period.
When the client intends to stop using the established security context, it SHOULD delete the context by calling GSS_Delete_sec_context AND SHOULD delete the context on the DNS server by using a TKEY RR with Mode field set to 5 (key deletion).
When verifying a message and GSS_VerifyMIC returns certain error statuses (including GSS_S_BAD_SIG, GSS_S_DUPLICATE_TOKEN, GSS_S_CONTEXT_EXPIRED, etc.), the server MUST send a TSIG error response indicating BADKEY as described in RFC 2845.
When verifying a signed message, if the TSIG NAME does not map to an established context, the server MUST send a TSIG error response indicating BADKEY. Additionally, TSIG timer values MUST be valid before the message is considered authentic; the caller MUST NOT act on the request until all checks pass.
The TKEY resource record is used to transfer GSS tokens between client and server. The TKEY record carries Algorithm Name = 'gss-tsig', Mode = 3 (GSS-API negotiation), Key Size = size of output_token in octets, and Key Data = output_token.
The TSIG record used with GSS-TSIG identifies the context via NAME = key_name and Algorithm Name = 'gss-tsig'. The signature field is populated with the per_msg_token output from GSS_GetMIC applied to the full DNS message plus TSIG variables.
IANA has reserved the TSIG Algorithm name 'gss-tsig' for use in the Algorithm fields of TKEY and TSIG resource records, referring to the GSS-TSIG algorithm described in this document as required by RFC 2845.
The security provided by GSS-TSIG is only as effective as the security provided by the underlying GSS mechanisms. All security considerations from RFC 2845, RFC 2930, and RFC 2743 apply to this protocol.
A GSS-TSIG security context has three states: Uninitialized, Negotiating Context, and Context Established. Every connection begins in the Uninitialized state, advances to Negotiating Context during token exchange, and reaches Context Established upon successful GSS negotiation completion.
The TKEY RDATA for GSS-TSIG context negotiation includes: Algorithm Name = 'gss-tsig', Mode = 3 (GSS-API negotiation), Key Size = size of output_token in octets, Key Data = output_token. Remaining fields (Inception, Expiration, Error, Other Size and Data) MUST be set per RFC 2930.