draft-ietf-dnsext-tkey-renewal-mode-02.txt   draft-ietf-dnsext-tkey-renewal-mode-03.txt 
DNSEXT Working Group Yuji Kamite DNSEXT Working Group Yuji Kamite
INTERNET-DRAFT NTT Communications INTERNET-DRAFT NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-02.txt> Masaya Nakayama <draft-ietf-dnsext-tkey-renewal-mode-03.txt> Masaya Nakayama
Expires: Mar. 24, 2003 The University of Tokyo Expires: Sep. 3, 2003 The University of Tokyo
Sep. 24, 2002 Mar. 3, 2003
TKEY Secret Key Renewal Mode TKEY Secret Key Renewal Mode
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6
2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8 2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11
2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12
2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13
2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 14 4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 15
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Special Considerations for Two Servers' Case . . . . . . . . . . 15 5 Special Considerations for Two Servers' Case . . . . . . . . . . 16
5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16
6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 16 6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17
7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19 8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
TSIG [RFC2845] provides DNS message integrity and the TSIG [RFC2845] provides DNS message integrity and the
request/transaction authentication by means of message authentication request/transaction authentication by means of message authentication
codes (MAC). TSIG is a practical solution in view of calculation codes (MAC). TSIG is a practical solution in view of calculation
speed and availability. However, TSIG does not have exchanging speed and availability. However, TSIG does not have exchanging
mechanism of shared secret keys between server and resolver, and mechanism of shared secret keys between server and resolver, and
administrators might have to exchange secret keys manually. TKEY administrators might have to exchange secret keys manually. TKEY
[RFC2930] is introduced to solve such problem and it can exchange [RFC2930] is introduced to solve such problem and it can exchange
skipping to change at page 3, line 36 skipping to change at page 3, line 36
Moreover, perhaps holding old keys long time might give attackers Moreover, perhaps holding old keys long time might give attackers
chances to compromise by scrupulous calculation. chances to compromise by scrupulous calculation.
Therefore, when a new shared secret is established by TKEY, the Therefore, when a new shared secret is established by TKEY, the
previous old secret should be revoked immediately. To accomplish previous old secret should be revoked immediately. To accomplish
this, DNS servers must support a protocol for key renewal. This this, DNS servers must support a protocol for key renewal. This
document specifies procedure to refresh secret keys between two hosts document specifies procedure to refresh secret keys between two hosts
which is defined within the framework of TKEY, and it is called "TKEY which is defined within the framework of TKEY, and it is called "TKEY
Secret Key Renewal Mode". Secret Key Renewal Mode".
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC 2119]. [RFC 2119].
1.1. Defined Words 1.1. Defined Words
* Inception Time: Beginning of the shared secret key lifetime. This * Inception Time: Beginning of the shared secret key lifetime. This
value is determined when the key is generated. value is determined when the key is generated.
* Expiry Limit: Time limit of the key's validity. This value is * Expiry Limit: Time limit of the key's validity. This value is
determined when a new key is generated. After Expiry Limit, server determined when a new key is generated. After Expiry Limit, server
skipping to change at page 4, line 48 skipping to change at page 4, line 48
defined defined
Mode = (resolver assignment for key renewal), to be defined Mode = (resolver assignment for key renewal), to be defined
Mode = (key adoption), to be defined Mode = (key adoption), to be defined
1.3. Overview of Secret Key Renewal Mode 1.3. Overview of Secret Key Renewal Mode
When a server receives a query from a client signed with a TSIG key, When a server receives a query from a client signed with a TSIG key,
It always checks if the present time is within the range of usage It always checks if the present time is within the range of usage
duration it considers safe. If it is judged that the key is too old, duration it considers safe. If it is judged that the key is too old,
i.e., after Partial Revocation Time, the server comes to be in i.e., after Partial Revocation Time, the server comes to be in
Partial Revocation state about the key. Partial Revocation state about the key, and this key is called
partially revoked.
In this state, whenever a client sends a normal query (e.g., question In this state, whenever a client sends a normal query (e.g., question
about A RR) other than TKEY Renewal request with TSIG signed with the about A RR) other than TKEY Renewal request with TSIG signed with the
old key, the server returns an error message to notify that the time old key, the server returns an error message to notify that the time
to renew has come. This is called "PartialRevoke" error message. to renew has come. This is called "PartialRevoke" error message.
The client which got this error is able to notice that it is The client which got this error is able to notice that it is
necessary to refresh the secret. To make a new shared secret, it necessary to refresh the secret. To make a new shared secret, it
sends a TKEY Renewal request, in which several keying methods are sends a TKEY Renewal request, in which several keying methods are
available. After new secret establishment, the client sends a TKEY available. It can make use of TSIG authentication signed with the
Adoption request. If this is admitted by the server, the new key is partially revoked key mentioned above.
formally adopted, and at the same time the corresponding old secret
is invalidated. Then the client can send the first query again signed After new secret establishment, the client sends a TKEY Adoption
with the new key. request for renewal confirmation. This can also be authenticated with
the partially revoked key. If this is admitted by the server, the new
key is formally adopted, and at the same time the corresponding old
secret is invalidated. Then the client can send the first query again
signed with the new key.
Key renewal procedure is executed based on two-phase commit Key renewal procedure is executed based on two-phase commit
mechanism. The first phase is the TKEY Renewal request and its mechanism. The first phase is the TKEY Renewal request and its
response, which means preparatory confirmation for key update. The response, which means preparatory confirmation for key update. The
second phase is Adoption request and its response. If the server gets second phase is Adoption request and its response. If the server gets
request and client receives the response successfully, they can request and client receives the response successfully, they can
finish renewal process. If any error happens and renewal process finish renewal process. If any error happens and renewal process
fails during these phases, client should roll back to the beginning fails during these phases, client should roll back to the beginning
of the first phase, and send TKEY Renewal request again. This of the first phase, and send TKEY Renewal request again. This
rollback can be done until the Expiry Limit of the key. rollback can be done until the Expiry Limit of the key.
skipping to change at page 6, line 17 skipping to change at page 6, line 24
When the present time is the same as the Expiry Time or after it, the When the present time is the same as the Expiry Time or after it, the
server MUST NOT verify TSIG with the key, and returns error messages server MUST NOT verify TSIG with the key, and returns error messages
in the same way as when no valid key is found, following [RFC2845]. in the same way as when no valid key is found, following [RFC2845].
2.2. Partial Revocation 2.2. Partial Revocation
In Partial Revocation state, we say the server has partially revoked In Partial Revocation state, we say the server has partially revoked
the key and the key has become a "partially revoked key". the key and the key has become a "partially revoked key".
Server which has received queries signed with the partially revoked If server has received a query signed with the partially revoked key
key MUST NOT answer them except when they are Renewal requests (See for TKEY Renewal request (See section 2.3.) or "key adoption" request
section 2.3.) or "key adoption" requests (See section 2.4.). Instead, (See section 2.4.), then server does proper process following each
it returns TSIG error messages whose error codes are "PartialRevoke" specification.
(See section 9.)
If server receives other types of query signed with the partially
revoked key and the corresponding MAC is verified, then server SHOULD
return TSIG error message for response whose error code is
"PartialRevoke" (See section 9.). However, if it is for TKEY key
deletion request ([RFC2930] 4.2), server MAY process usual deletion
operation defined therein.
PartialRevoke error messages have the role to inform clients of the PartialRevoke error messages have the role to inform clients of the
keys' partial revocation and urge them to send TKEY Renewal requests. keys' partial revocation and urge them to send TKEY Renewal requests.
These error responses MUST be signed with those partial revoked keys These error responses MUST be signed with those partial revoked keys
if the queries are signed with them. They are sent only when the keys if the queries are signed with them. They are sent only when the keys
used for queries' TSIG are found to be partially revoked. If the MAC used for queries' TSIG are found to be partially revoked. If the MAC
of TSIG cannot be verified with the partially revoked keys, servers of TSIG cannot be verified with the partially revoked keys, servers
MUST NOT return PartialRevoke error with MAC, but should return MUST NOT return PartialRevoke error with MAC, but should return
another error such as "BADSIG" without MAC; in other words, a server another error such as "BADSIG" without MAC; in other words, a server
informs its key's partial revocation only when the MAC in the informs its key's partial revocation only when the MAC in the
skipping to change at page 9, line 37 skipping to change at page 10, line 6
2.4.1. Query for Key Adoption 2.4.1. Query for Key Adoption
After receiving a TKEY Renewal answer, the client gets the same After receiving a TKEY Renewal answer, the client gets the same
secret as the server. Then, it sends a TKEY Adoption request. The secret as the server. Then, it sends a TKEY Adoption request. The
request's question section's QNAME field is the same as the NAME request's question section's QNAME field is the same as the NAME
filed of TKEY written below. In additional section, there is one TKEY filed of TKEY written below. In additional section, there is one TKEY
RR that has the structure and values described below. RR that has the structure and values described below.
"NAME" field is the new key's name to be adopted which was already "NAME" field is the new key's name to be adopted which was already
generated by Renewal message exchange. "Algorithm" is its algorithm generated by Renewal message exchange. "Algorithm" is its algo-
name. "Inception" means the key's Inception Time, and "Expiration" rithm. "Inception" means the key's Inception Time, and "Expiration"
means Expiry Limit. means Expiry Limit.
"Mode" field is the value of "key adoption". See section 9. "Mode" field is the value of "key adoption". See section 9.
"Other Data" field in Adoption has the same structure as that of "Other Data" field in Adoption has the same structure as that of
Renewal request message. "OldName" means the previous old key, and Renewal request message. "OldName" means the previous old key, and
"OldAlogirthm" means its algorithm. "OldAlogirthm" means its algorithm.
Key Adoption request MUST be signed with TSIG or SIG(0) for Key Adoption request MUST be signed with TSIG or SIG(0) for
authentication. The client can sign TSIG with the previous key. Note authentication. The client can sign TSIG with the previous key. Note
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/