contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt

   1
   2
   3
   4
   5
   6 DNS Extensions                                              Yuji Kamite
   7 Internet-Draft                                       NTT Communications
   8 Expires: April 15, 2005                                 Masaya Nakayama
   9                                                 The University of Tokyo
  10                                                        October 14, 2004
  11
  12
  13
  14                       TKEY Secret Key Renewal Mode
  15                  draft-ietf-dnsext-tkey-renewal-mode-05
  16
  17
  18 Status of this Memo
  19
  20    This document is an Internet-Draft and is subject to all provisions
  21    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
  22    author represents that any applicable patent or other IPR claims of
  23    which he or she is aware have been or will be disclosed, and any of
  24    which he or she become aware will be disclosed, in accordance with
  25    RFC 3668.
  26
  27    Internet-Drafts are working documents of the Internet Engineering
  28    Task Force (IETF), its areas, and its working groups.  Note that
  29    other groups may also distribute working documents as
  30    Internet-Drafts.
  31
  32    Internet-Drafts are draft documents valid for a maximum of six months
  33    and may be updated, replaced, or obsoleted by other documents at any
  34    time.  It is inappropriate to use Internet-Drafts as reference
  35    material or to cite them other than as "work in progress."
  36
  37    The list of current Internet-Drafts can be accessed at
  38    http://www.ietf.org/ietf/1id-abstracts.txt.
  39
  40    The list of Internet-Draft Shadow Directories can be accessed at
  41    http://www.ietf.org/shadow.html.
  42
  43    This Internet-Draft will expire on April 15, 2005.
  44
  45 Copyright Notice
  46
  47    Copyright (C) The Internet Society (2004).
  48
  49 Abstract
  50
  51    This document defines a new mode in TKEY and proposes an atomic
  52    method for changing secret keys used for TSIG periodically.
  53    Originally, TKEY provides methods of setting up shared secrets other
  54
  55
  56
  57 Kamite, et. al.          Expires April 15, 2005                 [Page 1]
  58 \f
  59 INTERNET-DRAFT                                              October 2004
  60
  61
  62    than manual exchange, but it cannot control timing of key renewal
  63    very well though it can add or delete shared keys separately. This
  64    proposal is a systematical key renewal procedure intended for
  65    preventing signing DNS messages with old and non-safe keys
  66    permanently.
  67
  68 Table of Contents
  69
  70    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  71      1.1   Defined Words  . . . . . . . . . . . . . . . . . . . . . .  3
  72      1.2   New Format and Assigned Numbers  . . . . . . . . . . . . .  4
  73      1.3   Overview of Secret Key Renewal Mode  . . . . . . . . . . .  4
  74    2.  Shared Secret Key Renewal  . . . . . . . . . . . . . . . . . .  5
  75      2.1   Key Usage Time Check . . . . . . . . . . . . . . . . . . .  5
  76      2.2   Partial Revocation . . . . . . . . . . . . . . . . . . . .  6
  77      2.3   Key Renewal Message Exchange . . . . . . . . . . . . . . .  7
  78        2.3.1   Query for Key Renewal  . . . . . . . . . . . . . . . .  7
  79        2.3.2   Response for Key Renewal . . . . . . . . . . . . . . .  7
  80        2.3.3   Attributes of Generated Key  . . . . . . . . . . . . .  8
  81        2.3.4   TKEY RR structure  . . . . . . . . . . . . . . . . . .  8
  82      2.4   Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
  83        2.4.1   Query for Key Adoption . . . . . . . . . . . . . . . . 10
  84        2.4.2   Response for Key Adoption  . . . . . . . . . . . . . . 10
  85      2.5   Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
  86        2.5.1   DH Exchange for Key Renewal  . . . . . . . . . . . . . 11
  87        2.5.2   Server Assigned Keying for Key Renewal . . . . . . . . 12
  88        2.5.3   Resolver Assigned Keying for Key Renewal . . . . . . . 13
  89      2.6   Considerations about Non-compliant Hosts . . . . . . . . . 14
  90    3.  Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
  91    4.  Compulsory Key Revocation  . . . . . . . . . . . . . . . . . . 15
  92      4.1   Compulsory Key Revocation by Server  . . . . . . . . . . . 15
  93      4.2   Authentication Methods Considerations  . . . . . . . . . . 15
  94    5.  Special Considerations for Two Servers' Case   . . . . . . . . 16
  95      5.1   To Cope with Collisions of Renewal Requests  . . . . . . . 16
  96    6.  Key Name Considerations  . . . . . . . . . . . . . . . . . . . 17
  97    7.  Example Usage of Secret Key Renewal Mode   . . . . . . . . . . 17
  98    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
  99    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
 100   10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
 101   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
 102     11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
 103     11.2   Informative References . . . . . . . . . . . . . . . . . . 21
 104        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
 105        Intellectual Property and Copyright Statements . . . . . . . . 23
 106
 107
 108
 109
 110
 111
 112
 113 Kamite, et. al.          Expires April 15, 2005                 [Page 2]
 114 \f
 115 INTERNET-DRAFT                                              October 2004
 116
 117
 118 1.  Introduction
 119
 120    TSIG [RFC2845] provides DNS message integrity and the
 121    request/transaction authentication by means of message authentication
 122    codes (MAC). TSIG is a practical solution in view of calculation
 123    speed and availability. However, TSIG does not have exchanging
 124    mechanism of shared secret keys between server and resolver, and
 125    administrators might have to exchange secret keys manually. TKEY
 126    [RFC2930] is introduced to solve such problem and it can exchange
 127    secrets for TSIG via networks.
 128
 129    In various modes of TKEY, a server and a resolver can add or delete a
 130    secret key be means of TKEY message exchange. However, the existing
 131    TKEY does not care fully about the management of keys which became
 132    too old, or dangerous after long time usage.
 133
 134    It is ideal that the number of secret which a pair of hosts share
 135    should be limited only one, because having too many keys for the same
 136    purpose might not only be a burden to resolvers for managing and
 137    distinguishing according to servers to query, but also does not seem
 138    to be safe in terms of storage and protection against attackers.
 139    Moreover, perhaps holding old keys long time might give attackers
 140    chances to compromise by scrupulous calculation.
 141
 142    Therefore, when a new shared secret is established by TKEY, the
 143    previous old secret should be revoked immediately. To accomplish
 144    this, DNS servers must support a protocol for key renewal. This
 145    document specifies procedure to refresh secret keys between two hosts
 146    which is defined within the framework of TKEY, and it is called "TKEY
 147    Secret Key Renewal Mode".
 148
 149    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
 150    "OPTIONAL" in this document are to be interpreted as described in
 151    [RFC2119].
 152
 153
 154 1.1.  Defined Words
 155
 156    * Inception Time: Beginning of the shared secret key lifetime. This
 157    value is determined when the key is generated.
 158
 159    * Expiry Limit: Time limit of the key's validity. This value is
 160    determined when a new key is generated. After Expiry Limit, server
 161    and client (resolver) must not authenticate TSIG signed with the key.
 162    Therefore, Renewal to the next key should be carried out before
 163    Expiry Limit.
 164
 165    * Partial Revocation Time: Time when server judges the key is too old
 166
 167
 168
 169 Kamite, et. al.          Expires April 15, 2005                 [Page 3]
 170 \f
 171 INTERNET-DRAFT                                              October 2004
 172
 173
 174    and must be updated. It must be between Inception Time and Expiry
 175    Limit.  This value is determined by server freely following its
 176    security policy. e.g., If the time from Inception to Partial
 177    Revocation is short, renewal will be carried out more often, which
 178    might be safer.
 179
 180    * Revocation Time: Time when the key becomes invalid and can be
 181    removed. This value is not determined in advance because it is the
 182    actual time when revocation is completed.
 183
 184    * Adoption Time: Time when the new key is adopted as the next key
 185    formally. After Adoption, the key is valid and server and client can
 186    generate or verify TSIG making use of it. Adoption Time also means
 187    the time when it becomes possible to remove the previous key, so
 188    Revocation and Adoption are usually done at the same time.
 189
 190
 191                   Partial
 192     Inception     Revocation    Revocation         Expiry Limit
 193      |                |              |             |
 194      |----------------|- - - - - - >>|- (revoked) -|
 195      |                |              |             |
 196     previous key      |      |       |
 197                              |- - - -|-------------------->> time
 198                              |       |               new key
 199                          Inception   Adoption
 200
 201
 202 1.2.  New Format and Assigned Numbers
 203
 204    TSIG
 205          ERROR = (PartialRevoke), TBD
 206
 207    TKEY
 208          Mode  = (server assignment for key renewal), TBD
 209          Mode  = (Diffie-Hellman exchange for key renewal), TBD
 210          Mode  = (resolver assignment for key renewal), TBD
 211          Mode  = (key adoption), TBD
 212
 213
 214 1.3.  Overview of Secret Key Renewal Mode
 215
 216    When a server receives a query from a client signed with a TSIG key,
 217    It always checks if the present time is within the range of usage
 218    duration it considers safe. If it is judged that the key is too old,
 219    i.e., after Partial Revocation Time, the server comes to be in
 220    Partial Revocation state about the key, and this key is called
 221    partially revoked.
 222
 223
 224
 225 Kamite, et. al.          Expires April 15, 2005                 [Page 4]
 226 \f
 227 INTERNET-DRAFT                                              October 2004
 228
 229
 230    In this state, if a client sends a normal query (e.g., question about
 231    A RR) other than TKEY Renewal request with TSIG signed with the old
 232    key, the server returns an error message to notify that the time to
 233    renew has come. This is called "PartialRevoke" error message. It is
 234    server's choice whether it returns PartialRevoke or not. If and only
 235    if the server is ready for changing its own key, it decides to return
 236    PartialRevoke.
 237
 238    The client which got this error is able to notice that it is
 239    necessary to refresh the secret. To make a new shared secret, it
 240    sends a TKEY Renewal request, in which several keying methods are
 241    available. It can make use of TSIG authentication signed with the
 242    partially revoked key mentioned above.
 243
 244    After new secret establishment, the client sends a TKEY Adoption
 245    request for renewal confirmation. This can also be authenticated with
 246    the partially revoked key. If this is admitted by the server, the new
 247    key is formally adopted, and at the same time the corresponding old
 248    secret is invalidated. Then the client can send the first query again
 249    signed with the new key.
 250
 251    Key renewal procedure is executed based on two-phase commit
 252    mechanism. The first phase is the TKEY Renewal request and its
 253    response, which means preparatory confirmation for key update. The
 254    second phase is Adoption request and its response. If the server gets
 255    request and client receives the response successfully, they can
 256    finish renewal process. If any error happens and renewal process
 257    fails during these phases, client should roll back to the beginning
 258    of the first phase, and send TKEY Renewal request again. This
 259    rollback can be done until the Expiry Limit of the key.
 260
 261
 262 2.  Shared Secret Key Renewal
 263
 264    Suppose a server and a client agree to change their TSIG keys
 265    periodically. Key renewal procedure is defined between two hosts.
 266
 267 2.1.  Key Usage Time Check
 268
 269    Whenever a server receives a query with TSIG and can find a key that
 270    is used for signing it, the server checks its Inception Time, Partial
 271    Revocation Time and Expiry Limit (this information is usually
 272    memorized by the server).
 273
 274    When the present time is before Inception Time, the server MUST NOT
 275    verify TSIG with the key, and server acts the same way as when the
 276    key used by the client is not recognized. It follows [RFC2845] 4.5.1.
 277
 278
 279
 280
 281 Kamite, et. al.          Expires April 15, 2005                 [Page 5]
 282 \f
 283 INTERNET-DRAFT                                              October 2004
 284
 285
 286    When the present time is equal to Inception Time, or between
 287    Inception Time and Partial Revocation Time, the behavior of the
 288    server is the same as when a valid key is found. It follows [RFC2845]
 289    4.5.2 and 4.5.3.
 290
 291    When the present time is the same as the Partial Revocation Time, or
 292    between the Partial Revocation Time and Expiry Limit, the server
 293    comes to be in Partial Revocation state about the TSIG key and
 294    behaves according to the next section.
 295
 296    When the present time is the same as the Expiry Time or after it, the
 297    server MUST NOT verify TSIG with the key, and returns error messages
 298    in the same way as when the key used by the client is not recognized.
 299    It follows [RFC2845] 4.5.1.
 300
 301
 302 2.2.  Partial Revocation
 303
 304    In Partial Revocation state, we say the server has partially revoked
 305    the key and the key has become a "partially revoked key".
 306
 307    If server has received a query signed with the partially revoked key
 308    for TKEY Renewal request (See section 2.3.) or Key Adoption request
 309    (See section 2.4.), then server does proper process following each
 310    specification. If it is for TKEY key deletion request ([RFC2930]
 311    4.2), server MAY process usual deletion operation defined therein.
 312
 313    If server receives other types of query signed with the partially
 314    revoked key, and both the corresponding MAC and signed TIME are
 315    verified, then server begins returning answer whose TSIG error code
 316    is "PartialRevoke" (See section 9.). Server MUST randomly but with
 317    increasing frequency return PartialRevoke when in the Partial
 318    Revocation state.
 319
 320    Server can decide when it actually sends PartialRevoke, checking if
 321    it is appropriate time for renewal. Server MUST NOT return
 322    PartialRevoke if this is apart long lived TSIG transaction (such as
 323    AXFR) that started before the Partial Revocation Time.
 324
 325    If the client receives PartialRevoke and understands it, then it MUST
 326    retry the query with the old key unless a new key has been adopted.
 327    Client SHOULD start the process to renew the TSIG key. For key
 328    renewal procedure, see details in Section 2.3 and 2.4.
 329
 330    PartialRevoke period (i.e., time while server returns PartialRevoke
 331    randomely) SHOULD be small, say 2-5% of key lifetime. This is
 332    server's choice.
 333
 334
 335
 336
 337 Kamite, et. al.          Expires April 15, 2005                 [Page 6]
 338 \f
 339 INTERNET-DRAFT                                              October 2004
 340
 341
 342    Server MUST keep track of clients ignoring PartialRevoke, thus
 343    indicating ignorance of this TKEY mode.
 344
 345    PartialRevoke error messages have the role to inform clients of the
 346    keys' partial revocation and urge them to send TKEY Renewal requests.
 347    These error responses MUST be signed with those partial revoked keys
 348    if the queries are signed with them. They are sent only when the
 349    signing keys are found to be partially revoked. If the MAC of TSIG
 350    cannot be verified with the partially revoked keys, servers MUST NOT
 351    return PartialRevoke error with MAC, but MUST return another error
 352    such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
 353    words, a server informs its key's partial revocation only when the
 354    MAC in the received query is valid.
 355
 356
 357 2.3.  Key Renewal Message Exchange
 358
 359 2.3.1.  Query for Key Renewal
 360
 361    If a client has received a PartialRevoke error and authenticated the
 362    response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
 363    this document, we call it Renewal request, too.) to the server. The
 364    request MUST be signed with TSIG or SIG(0) [RFC2931] for
 365    authentication. If TSIG is selected, the client can sign it with the
 366    partial revoked key.
 367
 368    Key Renewal can use one of several keying methods which is indicated
 369    in "Mode" field of TKEY RR, and its message structure is dependent on
 370    that method.
 371
 372
 373 2.3.2.  Response for Key Renewal
 374
 375    The server which has received Key Renewal request first tries to
 376    verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
 377    verified with the partially revoked key, the request MUST be
 378    authenticated.
 379
 380    After authentication, server must check existing old key's validity.
 381    If the partially revoked key indicated in the request TKEY's OldName
 382    and OldAlgorithm field (See section 2.3.4.) does not exist at the
 383    server, "BADKEY" [RFC2845] is given in Error field for response. If
 384    any other error happens, server returns appropriate error messages
 385    following the specification described in section 2.5. If there are no
 386    errors, server returns a Key Renewal answer. This answer MUST be
 387    signed with TSIG or SIG(0) for authentication.
 388
 389    When this answer is successfully returned and no error is detected by
 390
 391
 392
 393 Kamite, et. al.          Expires April 15, 2005                 [Page 7]
 394 \f
 395 INTERNET-DRAFT                                              October 2004
 396
 397
 398    client, a new shared secret can be established. The details of
 399    concrete keying procedure are given in the section 2.5.
 400
 401    Note:
 402       Sometimes Adoption message and new Renewal request will cross on
 403       the wire. In this case the newly generated key Adoption message is
 404       resent.
 405
 406
 407 2.3.3.  Attributes of Generated Key
 408
 409    As a result of this message exchange, client comes to know the newly
 410    generated key's attributes such as key's name, Inception Time and
 411    Expiry Limit. They are decided by the server and told to the client;
 412    in particular, however, once the server has decided Expiry Limit and
 413    returned a response, it should obey the decision as far as it can. In
 414    other words, they SHOULD NOT change time values for checking Expiry
 415    Limit in the future without any special reason, such as security
 416    issue like "Emergency Compulsory Revocation" described in section 8.
 417
 418    On the other hand, Partial Revocation Time of this generated key is
 419    not decided based on the request, and not informed to the client. The
 420    server can determine any value as long as it is between Inception
 421    Time and Expiry Limit. However, the period from Inception to Partial
 422    Revocation SHOULD be fixed as the server side's configuration or be
 423    set the same as the corresponding old key's one.
 424
 425    Note:
 426       Even if client sends Key Renewal request though the key described
 427       in OldName has not been partially revoked yet, server does renewal
 428       processes.  At the moment when the server accepts such requests
 429       with valid authentication, it MUST forcibly consider the key is
 430       already partially revoked, that is, the key's Partial Revocation
 431       Time must be changed into the present time (i.e., the time when
 432       the server receives the request).
 433
 434
 435 2.3.4.  TKEY RR structure
 436
 437    TKEY RR for Key Renewal message has the structure given below. In
 438    principle, format and definition for each field follows [RFC2930].
 439    Note that each keying scheme sometimes needs different interpretation
 440    of RDATA field; for detail, see section 2.5.
 441
 442         Field        Type         Comment
 443         -------      ------       -------
 444         NAME         domain       used for a new key, see below
 445         TYPE         u_int16_t    (defined in [RFC2930])
 446
 447
 448
 449 Kamite, et. al.          Expires April 15, 2005                 [Page 8]
 450 \f
 451 INTERNET-DRAFT                                              October 2004
 452
 453
 454         CLASS        u_int16_t    (defined in [RFC2930])
 455         TTL          u_int32_t    (defined in [RFC2930])
 456         RDLEN        u_int16_t    (defined in [RFC2930])
 457         RDATA:
 458          Algorithm:   domain       algorithm for a new key
 459          Inception:   u_int32_t    about the keying material
 460          Expiration:  u_int32_t    about the keying material
 461          Mode:        u_int16_t    scheme for key agreement
 462                                    see section 9.
 463          Error:       u_int16_t    see description below
 464          Key Size:    u_int16_t    see description below
 465          Key Data:    octet-stream
 466          Other Size:  u_int16_t    (defined in [RFC2930])
 467                                    size of other data
 468          Other Data:               newly defined: see description below
 469
 470
 471      For "NAME" field, both non-root and root name are allowed. It may
 472      be used for a new key's name in the same manner as [RFC2930] 2.1.
 473
 474      "Algorithm" specifies which algorithm is used for agreed keying
 475      material, which is used for identification of the next key.
 476
 477      "Inception" and "Expiration" are used for the valid period of
 478      keying material. The meanings differ somewhat according to whether
 479      the message is request or answer, and its keying scheme.
 480
 481      "Key Data" has different meanings according to keying schemes.
 482
 483      "Mode" field stores the value in accordance with the keying method,
 484      and see section 2.5. Servers and clients supporting TKEY Renewal
 485      method MUST implement "Diffie-Hellman exchange for key renewal"
 486      scheme. All other modes are OPTIONAL.
 487
 488      "Error" is an extended RCODE which includes "PartialRevoke" value
 489      too. See section 9.
 490
 491      "Other Data" field has the structure given below.  They describe
 492      attributes of the key to be renewed.
 493
 494         in Other Data filed:
 495
 496           Field            Type       Comment
 497           -------          ------     -------
 498           OldNAME          domain     name of the old key
 499           OldAlgorithm     domain     algorithm of the old key
 500
 501
 502
 503
 504
 505 Kamite, et. al.          Expires April 15, 2005                 [Page 9]
 506 \f
 507 INTERNET-DRAFT                                              October 2004
 508
 509
 510           "OldName" indicates the name of the previous key (usually,
 511           this is partially revoked key's name that client noticed by
 512           PartialRevoke answer from server), and "OldAlogirthm"
 513           indicates its algorithm.
 514
 515
 516 2.4.  Key Adoption
 517
 518 2.4.1.  Query for Key Adoption
 519
 520    After receiving a TKEY Renewal answer, the client gets the same
 521    secret as the server. Then, it sends a TKEY Adoption request. The
 522    request's question section's QNAME field is the same as the NAME
 523    filed of TKEY written below. In additional section, there is one TKEY
 524    RR that has the structure and values described below.
 525
 526      "NAME" field is the new key's name to be adopted which was already
 527      generated by Renewal message exchange. "Algorithm" is its
 528      algorithm. "Inception" means the key's Inception Time, and
 529      "Expiration" means Expiry Limit.
 530
 531      "Mode" field is the value of "key adoption". See section 9.
 532
 533      "Other Data" field in Adoption has the same structure as that of
 534      Renewal request message. "OldName" means the previous old key, and
 535      "OldAlogirthm" means its algorithm.
 536
 537    Key Adoption request MUST be signed with TSIG or SIG(0) for
 538    authentication. The client can sign TSIG with the previous key. Note
 539    that until Adoption is finished, the new key is treated as invalid,
 540    thus it cannot be used for authentication immediately.
 541
 542
 543 2.4.2.  Response for Key Adoption
 544
 545    The server which has received Adoption request, it verifies TSIG or
 546    SIG(0) accompanying it. If the TSIG is signed with the partially
 547    revoked key and can be verified, the message MUST be authenticated.
 548
 549    If the next new key indicated by the request TKEY's "NAME" is not
 550    present at the server, BADNAME [RFC2845] is given in Error field and
 551    the error message is returned.
 552
 553    If the next key exists but it has not been adopted formally yet, the
 554    server confirms the previous key's existence indicated by the
 555    "OldName" and "OldAlgorithm" field. If it succeeds, the server
 556    executes Adoption of the next key and Revocation of the previous key.
 557    Response message duplicates the request's TKEY RR with NOERROR,
 558
 559
 560
 561 Kamite, et. al.          Expires April 15, 2005                [Page 10]
 562 \f
 563 INTERNET-DRAFT                                              October 2004
 564
 565
 566    including "OldName" and "OldAlgorithm" that indicate the revoked key.
 567
 568    If the next key exists but it is already adopted, the server returns
 569    a response message regardless of the substance of the request TKEY's
 570    "OldName". In this response, Response TKEY RR has the same data as
 571    the request's one except as to its "Other Data" that is changed into
 572    null (i.e., "Other Size" is zero), which is intended for telling the
 573    client that the previous key name was ignored, and the new key is
 574    already available.
 575
 576    Client sometimes has to retry Adoption request. Suppose the client
 577    sent request signed with the partially revoked key, but its response
 578    did not return successfully (e.g., due to the drop of UDP packet).
 579    Client will probably retry Adoption request; however, the request
 580    will be refused in the form of TSIG "BADKEY" error because the
 581    previous key was already revoked. In this case, client will
 582    retransmit Adoption request signed with the next key, and expect a
 583    response which has null "Other Data" for confirming the completion of
 584    renewal.
 585
 586
 587 2.5.  Keying Schemes
 588
 589    In Renewal message exchanges, there are no limitations as to which
 590    keying method is actually used. The specification of keying
 591    algorithms is independent of the general procedure of Renewal that is
 592    described in section 2.3.
 593
 594    Now this document specifies three algorithms in this section, but
 595    other future documents can make extensions defining other methods.
 596
 597
 598 2.5.1.  DH Exchange for Key Renewal
 599
 600    This scheme is defined as an extended method of [RFC2930] 4.1. This
 601    specification only describes the difference from it and special
 602    notice; assume that all other points, such as keying material
 603    computation, are the exactly same as the specification of [RFC2930]
 604    4.1.
 605
 606    Query
 607       In Renewal request for type TKEY with this mode, there is one TKEY
 608       RR and one KEY RR in the additional information section. KEY RR is
 609       the client's Diffie-Hellman public key [RFC2539].
 610
 611       QNAME in question section is the same as that of "NAME" field in
 612       TKEY RR, i.e., it means the requested new key's name.
 613
 614
 615
 616
 617 Kamite, et. al.          Expires April 15, 2005                [Page 11]
 618 \f
 619 INTERNET-DRAFT                                              October 2004
 620
 621
 622       TKEY "Mode" field stores the value of "DH exchange for key
 623       renewal". See section 9.
 624
 625       TKEY "Inception" and "Expiration" are those requested for the
 626       keying material, that is, requested usage period of a new key.
 627
 628       TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
 629
 630    Response
 631       The server which received this request first verifies the TSIG,
 632       SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
 633       old key's existence validity is checked, following section 2.3. If
 634       any incompatible DH key is found in the request, "BADKEY"
 635       [RFC2845] is given in Error field for response. "FORMERR" is given
 636       if the query included no DH KEY.
 637
 638       If there are no errors, the server processes a response according
 639       to Diffie-Hellman algorithm and returns the answer. In this
 640       answer, there is one TKEY RR in answer section and KEY RR(s) in
 641       additional section.
 642
 643       As long as no error has occurred, all values of TKEY are equal to
 644       that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
 645       Inception, Expiration, Key Size and Key Data.
 646
 647       TKEY "NAME" field in the answer specifies the name of newly
 648       produced key which the client MUST use.
 649
 650       TKEY "Inception" and "Expiration" mean the periods of the produced
 651       key usage. "Inception" is set to be the time when the new key is
 652       actually generated or the time before it, and it will be regarded
 653       as Inception Time. "Expiration" is determined by the server, and
 654       it will be regarded as Expiry Limit.
 655
 656       TKEY "Key Data" is used as an additional nonce, following
 657       [RFC2930] 4.1.
 658
 659       The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
 660       the additional section and a server Diffie-Hellman KEY RR will
 661       also be present in the answer section, following [RFC2930] 4.1.
 662
 663
 664 2.5.2.  Server Assigned Keying for Key Renewal
 665
 666    This scheme is defined as an extended method of [RFC2930] 4.4. This
 667    specification only describes the difference from it and special
 668    notice; assume that all other points, such as secret encrypting
 669    method, are the exactly same as the specification of [RFC2930] 4.4.
 670
 671
 672
 673 Kamite, et. al.          Expires April 15, 2005                [Page 12]
 674 \f
 675 INTERNET-DRAFT                                              October 2004
 676
 677
 678    Query
 679       In Renewal request for type TKEY with this mode, there is one TKEY
 680       RR and one KEY RR in the additional information section. KEY RR is
 681       used in encrypting the response.
 682
 683       QNAME in question section is the same as that of "NAME" field in
 684       TKEY RR, i.e., it means the requested new key's name.
 685
 686       TKEY "Mode" field stores the value of "server assignment for key
 687       renewal". See section 9.
 688
 689       TKEY "Inception" and "Expiration" are those requested for the
 690       keying material, that is, requested usage period of a new key.
 691
 692       TKEY "Key Data" is provided following the specification of
 693       [RFC2930] 4.4.
 694
 695    Response
 696       The server which received this request first verifies the TSIG,
 697       SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
 698       old key's existence validity is checked, following section 2.3.
 699       "FORMERR" is given if the query specified no encryption key.
 700
 701       If there are no errors, the server response contains one TKEY RR
 702       in the answer section, and echoes the KEY RR provided in the query
 703       in the additional information section.
 704
 705       TKEY "NAME" field in the answer specifies the name of newly
 706       produced key which the client MUST use.
 707
 708       TKEY "Inception" and "Expiration" mean the periods of the produced
 709       key usage. "Inception" is set to be the time when the new key is
 710       actually generated or the time before it, and it will be regarded
 711       as Inception Time. "Expiration" is determined by the server, and
 712       it will be regarded as Expiry Limit.
 713
 714       TKEY "Key Data" is the assigned keying data encrypted under the
 715       public key in the resolver provided KEY RR, which is the same as
 716       [RFC2930] 4.4.
 717
 718
 719 2.5.3.  Resolver Assigned Keying for Key Renewal
 720
 721    This scheme is defined as an extended method of [RFC2930] 4.5. This
 722    specification only describes the difference from it and special
 723    notice; assume that all other points, such as secret encrypting
 724    method, are the exactly same as the specification of [RFC2930] 4.5.
 725
 726
 727
 728
 729 Kamite, et. al.          Expires April 15, 2005                [Page 13]
 730 \f
 731 INTERNET-DRAFT                                              October 2004
 732
 733
 734    Query
 735       In Renewal request for type TKEY with this mode, there is one TKEY
 736       RR and one KEY RR in the additional information section. TKEY RR
 737       has the encrypted keying material and KEY RR is the server public
 738       key used to encrypt the data.
 739
 740       QNAME in question section is the same as that of "NAME" field in
 741       TKEY RR, i.e., it means the requested new key's name.
 742
 743       TKEY "Mode" field stores the value of "resolver assignment for key
 744       renewal". See section 9.
 745
 746       TKEY "Inception" and "Expiration" are those requested for the
 747       keying material, that is, requested usage period of a new key.
 748
 749       TKEY "Key Data" is the encrypted keying material.
 750
 751    Response
 752       The server which received this request first verifies the TSIG,
 753       SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
 754       old key's existence validity is checked, following section 2.3.
 755       "FORMERR" is given if the server does not have the corresponding
 756       private key for the KEY RR that was shown sin the request.
 757
 758       If there are no errors, the server returns a response. The
 759       response contains a TKEY RR in the answer section to tell the
 760       shared key's name and its usage time values.
 761
 762       TKEY "NAME" field in the answer specifies the name of newly
 763       produced key which the client MUST use.
 764
 765       TKEY "Inception" and "Expiration" mean the periods of the produced
 766       key usage. "Inception" is set to be the time when the new key is
 767       actually generated or the time before it, and it will be regarded
 768       as Inception Time. "Expiration" is determined by the server, and
 769       it will be regarded as Expiry Limit.
 770
 771
 772 2.6.  Considerations about Non-compliant Hosts
 773
 774    Key Renewal requests and responses must be exchanged between hosts
 775    which can understand them and do proper processes. PartialRevoke
 776    error messages will be only ignored if they should be returned to
 777    non-compliant hosts.
 778
 779    Note that server does not inform actively the necessity of renewal to
 780    clients, but inform it as responses invoked by client's query.
 781    Server needs not care whether the PartialRevoke errors has reached
 782
 783
 784
 785 Kamite, et. al.          Expires April 15, 2005                [Page 14]
 786 \f
 787 INTERNET-DRAFT                                              October 2004
 788
 789
 790    client or not. If client has not received yet because of any reasons
 791    such as packet drops, it will resend the queries, and finally will be
 792    able to get PartialRevoke information.
 793
 794
 795 3.  Secret Storage
 796
 797    Every server keeps all secrets and attached information, e.g.,
 798    Inception Time, Expiry Limit, etc. safely to be able to recover from
 799    unexpected stop. To accomplish this, formally adopted keys SHOULD be
 800    memorized not only on memory, but also be stored in the form of some
 801    files. It will become more secure if they are stored in ecrypted
 802    form.
 803
 804
 805 4.  Compulsory Key Revocation
 806
 807 4.1.  Compulsory Key Revocation by Server
 808
 809    There is a rare but possible case that although servers have already
 810    partially revoked keys, clients do not try to send any Renewal
 811    requests. If this state continues, in the future it will become the
 812    time of Expiry Limit. After Expiry Limit, the keys will be expired
 813    and completely removed, so this is called Compulsory Key Revocation
 814    by server.
 815
 816    If Expiry Limit is too distant from the Partial Revocation Time, then
 817    even though very long time passes, clients will be able to refresh
 818    secrets only if they add TSIG signed with those old partially revoked
 819    keys into requests, which is not safe.
 820
 821    On the other hand, if Expiry Limit is too close to Partial Revocation
 822    Time, perhaps clients might not be able to notice their keys' Partial
 823    Revocation by getting "PartialRevoke" errors.
 824
 825    Therefore, servers should set proper Expiry Limit to their keys,
 826    considering both their keys' safety, and enough time for clients to
 827    send requests and process renewal.
 828
 829
 830 4.2.  Authentication Methods Considerations
 831
 832    It might be ideal to provide both SIG(0) and TSIG as authentication
 833    methods. For example:
 834
 835      A client and a server start SIG(0) authentication at first, to
 836      establish TSIG shared keys by means of "Query for Diffie-Hellman
 837      Exchanged Keying" as described in [RFC2930] 4.1. Once they get
 838
 839
 840
 841 Kamite, et. al.          Expires April 15, 2005                [Page 15]
 842 \f
 843 INTERNET-DRAFT                                              October 2004
 844
 845
 846      shared secret, they keep using TSIG for queries and responses.
 847      After a while the server returns a "ParitalRevoke" error and they
 848      begin a key renewal process. Both TSIG signed with partially
 849      revoked keys and SIG(0) are okay for authentication, but TSIG would
 850      be easier to use considering calculation efficiency.
 851
 852      Suppose now client is halted for long time with some reason.
 853      Because server does not execute any renewal process, it will
 854      finally do Compulsory Revocation. Even if client restarts and sends
 855      a key Renewal request, it will fail because old key is already
 856      deleted at server.
 857
 858      At this moment, however, if client also uses SIG(0) as another
 859      authentication method, it can make a new shared key again and
 860      recover successfully by sending "Query for Diffie-Hellman Exchanged
 861      Keying" with SIG(0).
 862
 863
 864 5.  Special Considerations for Two servers' Case
 865
 866    This section refers to the case where both hosts are DNS servers
 867    which can act as full resolvers as well and using one shared key
 868    only. If one server (called Server A) wants to refresh a shared key
 869    (called "Key A-B"), it will await a TKEY Renewal request from the
 870    other server (called Server B). However, perhaps Server A wants to
 871    refresh the key right now.
 872
 873    In this case, Server A is allowed to send a Renewal request to Server
 874    B, if Server A knows the Key A-B is too old and wants to renew it
 875    immediately.
 876
 877    Note that the initiative in key renewal belongs to Server A because
 878    it can notice the Partial Revocation Time and decide key renewal. If
 879    Server B has information about Partial Revocation Time as well, it
 880    can also decide for itself to send Renewal request to Server A.
 881    However, it is not essential for both two servers have information
 882    about key renewal timing.
 883
 884 5.1.  To Cope with Collisions of Renewal Requests
 885
 886    At least one of two hosts which use Key Renewal must know their key
 887    renewal information such as Partial Revocation Time. It is okay that
 888    both hosts have it.
 889
 890    Provided that both two servers know key renewal timing information,
 891    there is possibility for them to begin partial revocation and sending
 892    Renewal requests to each other at the same time. Such collisions will
 893    not happen so often because Renewal requests are usually invoked when
 894
 895
 896
 897 Kamite, et. al.          Expires April 15, 2005                [Page 16]
 898 \f
 899 INTERNET-DRAFT                                              October 2004
 900
 901
 902    hosts want to send queries, but it is possible.
 903
 904    When one of two servers tries to send Renewal requests, it MUST
 905    protect old secrets that it has partially revoked and prevent it from
 906    being refreshed by any requests from the other server (i.e., it must
 907    lock the old secret during the process of renewal). While the server
 908    is sending Renewal requests and waiting responses, it ignores the
 909    other server's Renewal requests.
 910
 911    Therefore, servers might fail to change secrets by means of their own
 912    requests to others. After failure they will try to resend, but they
 913    should wait for random delays by the next retries. If they get any
 914    Renewal requests from others while they are waiting, their shared
 915    keys may be refreshed, then they do not need to send any Renewal
 916    requests now for themselves.
 917
 918
 919 6.  Key Name Considerations
 920
 921    Since both servers and clients have only to distinguish new secrets
 922    and old ones, keys' names do not need to be specified strictly.
 923    However, it is recommended that some serial number or key generation
 924    time be added to the name and that the names of keys between the same
 925    pair of hosts should have some common labels among their keys. For
 926    example, suppose A.example.com. and B.example.com. share the key
 927    "<serial number>.A.example.com.B.example.com." such as
 928    "10010.A.example.com.B.example.com.". After key renewal, they change
 929    their secret and name into "10011.A.example.com.B.example.com."
 930
 931    Servers and clients must be able to use keys properly for each query.
 932    Because TSIG secret keys themselves do not have any particular IDs to
 933    be distinguished and would be identified by their names and
 934    algorithm, it must be understood correctly what keys are refreshed.
 935
 936
 937 7.  Example Usage of Secret Key Renewal Mode
 938
 939    This is an example of Renewal mode usage where a Server,
 940    server.example.com, and a Client, client.exmple.com have an initial
 941    shared secret key named "00.client.example.com.server.example.com".
 942
 943      (1) The time values for key
 944      "00.client.example.com.server.example.com" was set as follows:
 945      Inception Time is at 1:00, Expiry Limit is at 21:00.
 946
 947      (2) At Server, renewal time has been set: Partial Revocation Time
 948      is at 20:00.
 949
 950
 951
 952
 953 Kamite, et. al.          Expires April 15, 2005                [Page 17]
 954 \f
 955 INTERNET-DRAFT                                              October 2004
 956
 957
 958      (3) Suppose the present time is 19:55. If Client sends a query
 959      signed with key "00.client.example.com.server.example.com" to ask
 960      the IP address of "www.example.com", finally it will get a proper
 961      answer from Server with valid TSIG (NOERROR).
 962
 963      (4) At 20:05. Client sends a query to ask the IP address of
 964      "www2.example.com". It is signed with key
 965      "00.client.example.com.server.example.com". Server returns an
 966      answer for the IP address. However, server has begun retuning
 967      PartialRevoke Error randomely. This answer includes valid TSIG MAC
 968      signed with "00.client.example.com.server.example.com", and its
 969      Error Code indicates PartialRevoke. Client understands that the
 970      current key is partially revoked.
 971
 972      (5) At 20:06. Client sends a Renewal request to Server. This
 973      request is signed with key
 974      "00.client.example.com.server.example.com". It includes data such
 975      as:
 976
 977       Question Section:
 978          QNAME = 01.client.example.com. (Client can set this freely)
 979          TYPE  = TKEY
 980
 981       Additional Section:
 982          01.client.example.com. TKEY
 983           Algorithm    = hmac-md5-sig-alg.reg.int.
 984           Inception    = (value meaning 20:00)
 985           Expiration   = (value meaning next day's 16:00)
 986           Mode         = (DH exchange for key renewal)
 987           OldName      = 00.client.example.com.server.example.com.
 988           OldAlgorithm = hmac-md5-sig-alg.reg.int.
 989
 990       Additional Section also contains a KEY RR for DH and a TSIG RR.
 991
 992      (6) As soon as Server receives this request, it verifies TSIG. It
 993      is signed with the partially revoked key
 994      "00.client.example.com.server.example.com". and Server accepts the
 995      request. It creates a new key by Diffie-Hellman calculation and
 996      returns an answer which includes data such as:
 997
 998       Answer Section:
 999          01.client.example.com.server.example.com. TKEY
1000           Algorithm    = hmac-md5-sig-alg.reg.int.
1001           Inception    = (value meaning 20:00)
1002           Expiration   = (value meaning next day's 16:00)
1003           Mode         = (DH exchange for key renewal)
1004           OldName      = 00.client.example.com.server.example.com.
1005           OldAlgorithm = hmac-md5-sig-alg.reg.int.
1006
1007
1008
1009 Kamite, et. al.          Expires April 15, 2005                [Page 18]
1010 \f
1011 INTERNET-DRAFT                                              October 2004
1012
1013
1014      Answer Section also contains KEY RRs for DH.
1015
1016       Additional Section also contains a TSIG RR.
1017      This response is signed with key
1018      "00.client.example.com.server.example.com" without error.
1019
1020      At the same time, Server decides to set the Partial Revocation Time
1021      of this new key "01.client.example.com.server.example.com." as next
1022      day's 15:00.
1023
1024      (7) Client gets the response and checks TSIG MAC, and calculates
1025      Diffie-Hellman. It will get a new key, and it has been named
1026      "01.client.example.com.server.example.com" by Server.
1027
1028      (8) At 20:07. Client sends an Adoption request to Server. This
1029      request is signed with the previous key
1030      "00.client.example.com.server.example.com". It includes:
1031
1032       Question Section:
1033          QNAME = 01.client.example.com.server.example.com.
1034          TYPE  = TKEY
1035
1036       Additional Section:
1037          01.client.example.com.server.example.com. TKEY
1038           Algorithm    = hmac-md5-sig-alg.reg.int.
1039           Inception    = (value meaning 20:00)
1040           Expiration   = (value meaning next day's 16:00)
1041           Mode         = (key adoption)
1042           OldName      = 00.client.example.com.server.example.com.
1043           OldAlgorithm = hmac-md5-sig-alg.reg.int.
1044
1045      Additional Section also contains a TSIG RR.
1046
1047      (9) Server verifies the query's TSIG. It is signed with the
1048      previous key and authenticated. It returns a response whose TKEY RR
1049      is the same as the request's one. The response is signed with key
1050      "00.client.example.com.server.example.com.". As soon as the
1051      response is sent, Server revokes and removes the previous key. At
1052      the same time, key "01.client.example.com.server.example.com." is
1053      validated.
1054
1055      (10) Client acknowledges the success of Adoption by receiving the
1056      response.  Then, it retries to send an original question about
1057      "www2.example.com". It is signed with the adopted key
1058      "01.client.example.com.server.example.com", so Server authenticates
1059      it and returns an answer.
1060
1061
1062
1063
1064
1065 Kamite, et. al.          Expires April 15, 2005                [Page 19]
1066 \f
1067 INTERNET-DRAFT                                              October 2004
1068
1069
1070      (11) This key is used until next day's 15:00. After that, it will
1071      be partially revoked again.
1072
1073
1074 8.  Security Considerations
1075
1076    This document considers about how to refresh shared secret. Secret
1077    changed by this method is used at servers in support of TSIG
1078    [RFC2845].
1079
1080    [RFC2104] says that current attacks to HMAC do not indicate a
1081    specific recommended frequency for key changes but periodic key
1082    refreshment is a fundamental security practice that helps against
1083    potential weaknesses of the function and keys, and limits the damage
1084    of an exposed key. TKEY Secret Key Renewal provides the method of
1085    periodical key refreshment.
1086
1087    In TKEY Secret Key Renewal, clients need to send two requests
1088    (Renewal and Adoption) and spend time to finish their key renewal
1089    processes. Thus the usage period of secrets should be considered
1090    carefully based on both TKEY processing performance and security.
1091
1092    This document specifies the procedure of periodical key renewal, but
1093    actually there is possibility for servers to have no choice other
1094    than revoking their secret keys immediately especially when the keys
1095    are found to be compromised by attackers. This is called "Emergency
1096    Compulsory Revocation". For example, suppose the original Expiry
1097    Limit was set at 21:00, Partial Revocation Time at 20:00 and
1098    Inception Time at 1:00.  if at 11:00 the key is found to be
1099    compromised, the server sets Expiry Limit forcibly to be 11:00 or
1100    before it.
1101
1102    Consequently, once Compulsory Revocation (See section 4.) is carried
1103    out, normal renewal process described in this document cannot be done
1104    any more as far as the key is concerned. However, after such
1105    accidents happened, the two hosts are able to establish secret keys
1106    and begin renewal procedure only if they have other (non-compromised)
1107    shared TSIG keys or safe SIG(0) keys for the authentication of
1108    initial secret establishment such as Diffie-Hellman Exchanged Keying.
1109
1110
1111 9.  IANA Considerations
1112
1113    IANA needs to allocate a value for "DH exchange for key renewal",
1114    "server assignment for key renewal", "resolver assignment for key
1115    renewal" and "key adoption" in the mode filed of TKEY. It also needs
1116    to allocate a value for "PartialRevoke" from the extended RCODE
1117    space.
1118
1119
1120
1121 Kamite, et. al.          Expires April 15, 2005                [Page 20]
1122 \f
1123 INTERNET-DRAFT                                              October 2004
1124
1125
1126 10.  Acknowledgements
1127
1128    The authors would like to thank Olafur Gudmundsson, whose helpful
1129    input and comments contributed greatly to this document.
1130
1131
1132 11.  References
1133
1134 11.1.  Normative References
1135
1136 [RFC2119]
1137      Bradner, S., "Key words for use in RFCs to Indicate Requirement
1138      Levels", RFC 2119, March 1997.
1139
1140 [RFC2539]
1141      D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
1142      System (DNS)", RFC 2539, March 1999.
1143
1144 [RFC2845]
1145      Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
1146      "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
1147      May 2000.
1148
1149 [RFC2930]
1150      D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
1151      RFC 2930, September 2000.
1152
1153 [RFC2931]
1154      D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
1155      )", RFC 2931, September 2000.
1156
1157 11.2.  Informative References
1158
1159 [RFC2104]
1160      H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
1161      Authentication", RFC2104, February 1997.
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177 Kamite, et. al.          Expires April 15, 2005                [Page 21]
1178 \f
1179 INTERNET-DRAFT                                              October 2004
1180
1181
1182 Authors' Addresses
1183
1184    Yuji Kamite
1185    NTT Communications Corporation
1186    Tokyo Opera City Tower
1187    3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
1188    163-1421, Japan
1189    EMail: y.kamite@ntt.com
1190
1191
1192    Masaya Nakayama
1193    Information Technology Center, The University of Tokyo
1194    2-11-16 Yayoi, Bunkyo-ku, Tokyo
1195    113-8658, Japan
1196    EMail: nakayama@nc.u-tokyo.ac.jp
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233 Kamite, et. al.          Expires April 15, 2005                [Page 22]
1234 \f
1235 INTERNET-DRAFT                                              October 2004
1236
1237
1238 Intellectual Property Statement
1239
1240    The IETF takes no position regarding the validity or scope of any
1241    Intellectual Property Rights or other rights that might be claimed to
1242    pertain to the implementation or use of the technology described in
1243    this document or the extent to which any license under such rights
1244    might or might not be available; nor does it represent that it has
1245    made any independent effort to identify any such rights.  Information
1246    on the procedures with respect to rights in RFC documents can be
1247    found in BCP 78 and BCP 79.
1248
1249    Copies of IPR disclosures made to the IETF Secretariat and any
1250    assurances of licenses to be made available, or the result of an
1251    attempt made to obtain a general license or permission for the use of
1252    such proprietary rights by implementers or users of this
1253    specification can be obtained from the IETF on-line IPR repository at
1254    http://www.ietf.org/ipr.
1255
1256    The IETF invites any interested party to bring to its attention any
1257    copyrights, patents or patent applications, or other proprietary
1258    rights that may cover technology that may be required to implement
1259    this standard.  Please address the information to the IETF at
1260    ietf-ipr@ietf.org.
1261
1262
1263 Disclaimer of Validity
1264
1265    This document and the information contained herein are provided on an
1266    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1267    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1268    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1269    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1270    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1271    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1272
1273
1274 Copyright Statement
1275
1276    Copyright (C) The Internet Society (2004).  This document is subject
1277    to the rights, licenses and restrictions contained in BCP 78, and
1278    except as set forth therein, the authors retain all their rights.
1279
1280
1281 Acknowledgment
1282
1283    Funding for the RFC Editor function is currently provided by the
1284    Internet Society.
1285
1286
1287
1288
1289 Kamite, et. al.          Expires April 15, 2005                [Page 23]
1290 \f
1291
1292