5 Network Working Group M. StJohns
6 Internet-Draft Nominum, Inc.
7 Expires: July 14, 2006 January 10, 2006
10 Automated Updates of DNSSEC Trust Anchors
11 draft-ietf-dnsext-trustupdate-timers-02
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on July 14, 2006.
40 Copyright (C) The Internet Society (2006).
44 This document describes a means for automated, authenticated and
45 authorized updating of DNSSEC "trust anchors". The method provides
46 protection against single key compromise of a key in the trust point
47 key set. Based on the trust established by the presence of a current
48 anchor, other anchors may be added at the same place in the
49 hierarchy, and, ultimately, supplant the existing anchor.
51 This mechanism, if adopted, will require changes to resolver
52 management behavior (but not resolver resolution behavior), and the
56 StJohns Expires July 14, 2006 [Page 1]
58 Internet-Draft trustanchor-update January 2006
61 addition of a single flag bit to the DNSKEY record.
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
68 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
69 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
70 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
71 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
72 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
73 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
74 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
75 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
76 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
77 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
78 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
79 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
80 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
81 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
82 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8
83 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
84 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9
85 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
86 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
87 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9
88 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
91 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
92 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
93 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
94 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
95 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
97 Intellectual Property and Copyright Statements . . . . . . . . . . 13
112 StJohns Expires July 14, 2006 [Page 2]
114 Internet-Draft trustanchor-update January 2006
119 As part of the reality of fielding DNSSEC (Domain Name System
120 Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
121 community has come to the realization that there will not be one
122 signed name space, but rather islands of signed name space each
123 originating from specific points (i.e. 'trust points') in the DNS
124 tree. Each of those islands will be identified by the trust point
125 name, and validated by at least one associated public key. For the
126 purpose of this document we'll call the association of that name and
127 a particular key a 'trust anchor'. A particular trust point can have
128 more than one key designated as a trust anchor.
130 For a DNSSEC-aware resolver to validate information in a DNSSEC
131 protected branch of the hierarchy, it must have knowledge of a trust
132 anchor applicable to that branch. It may also have more than one
133 trust anchor for any given trust point. Under current rules, a chain
134 of trust for DNSSEC-protected data that chains its way back to ANY
135 known trust anchor is considered 'secure'.
137 Because of the probable balkanization of the DNSSEC tree due to
138 signing voids at key locations, a resolver may need to know literally
139 thousands of trust anchors to perform its duties. (e.g. Consider an
140 unsigned ".COM".) Requiring the owner of the resolver to manually
141 manage this many relationships is problematic. It's even more
142 problematic when considering the eventual requirement for key
143 replacement/update for a given trust anchor. The mechanism described
144 herein won't help with the initial configuration of the trust anchors
145 in the resolvers, but should make trust point key replacement/
146 rollover more viable.
148 As mentioned above, this document describes a mechanism whereby a
149 resolver can update the trust anchors for a given trust point, mainly
150 without human intervention at the resolver. There are some corner
151 cases discussed (e.g. multiple key compromise) that may require
152 manual intervention, but they should be few and far between. This
153 document DOES NOT discuss the general problem of the initial
154 configuration of trust anchors for the resolver.
156 1.1. Compliance Nomenclature
158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
160 document are to be interpreted as described in BCP 14, [RFC2119].
162 1.2. Changes since -00
164 Added the concept of timer triggered resolver queries to refresh the
168 StJohns Expires July 14, 2006 [Page 3]
170 Internet-Draft trustanchor-update January 2006
173 resolvers view of the trust anchor key RRSet.
175 Re-submitted expired draft as -01. Updated DNSSEC RFC References.
177 Draft -02. Added the IANA Considerations section. Added text to
178 describe what happens if all trust anchors at a trust point are
182 2. Theory of Operation
184 The general concept of this mechanism is that existing trust anchors
185 can be used to authenticate new trust anchors at the same point in
186 the DNS hierarchy. When a new SEP key is added to a trust point
187 DNSKEY RRSet, and when that RRSet is validated by an existing trust
188 anchor, then the new key can be added to the set of trust anchors.
190 There are some issues with this approach which need to be mitigated.
191 For example, a compromise of one of the existing keys could allow an
192 attacker to add their own 'valid' data. This implies a need for a
193 method to revoke an existing key regardless of whether or not that
194 key is compromised. As another example assuming a single key
195 compromise, an attacker could add a new key and revoke all the other
200 Assume two trust anchor keys A and B. Assume that B has been
201 compromised. Without a specific revocation bit, B could invalidate A
202 simply by sending out a signed trust point key set which didn't
203 contain A. To fix this, we add a mechanism which requires knowledge
204 of the private key of a DNSKEY to revoke that DNSKEY.
206 A key is considered revoked when the resolver sees the key in a self-
207 signed RRSet and the key has the REVOKE bit (see Section 6 below) set
208 to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
209 key as a trust anchor or for any other purposes except validating the
210 RRSIG over the DNSKEY RRSet specifically for the purpose of
211 validating the revocation. Unlike the 'Add' operation below,
212 revocation is immediate and permanent upon receipt of a valid
213 revocation at the resolver.
215 N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
216 than one without the bit set. This affects the matching of a DNSKEY
217 to DS records in the parent, or the fingerprint stored at a resolver
218 used to configure a trust point. [msj3]
220 In the given example, the attacker could revoke B because it has
224 StJohns Expires July 14, 2006 [Page 4]
226 Internet-Draft trustanchor-update January 2006
229 knowledge of B's private key, but could not revoke A.
233 Assume two trust point keys A and B. Assume that B has been
234 compromised. An attacker could generate and add a new trust anchor
235 key - C (by adding C to the DNSKEY RRSet and signing it with B), and
236 then invalidate the compromised key. This would result in the both
237 the attacker and owner being able to sign data in the zone and have
238 it accepted as valid by resolvers.
240 To mitigate, but not completely solve, this problem, we add a hold-
241 down time to the addition of the trust anchor. When the resolver
242 sees a new SEP key in a validated trust point DNSKEY RRSet, the
243 resolver starts an acceptance timer, and remembers all the keys that
244 validated the RRSet. If the resolver ever sees the DNSKEY RRSet
245 without the new key but validly signed, it stops the acceptance
246 process and resets the acceptance timer. If all of the keys which
247 were originally used to validate this key are revoked prior to the
248 timer expiring, the resolver stops the acceptance process and resets
251 Once the timer expires, the new key will be added as a trust anchor
252 the next time the validated RRSet with the new key is seen at the
253 resolver. The resolver MUST NOT treat the new key as a trust anchor
254 until the hold down time expires AND it has retrieved and validated a
255 DNSKEY RRSet after the hold down time which contains the new key.
257 N.B.: Once the resolver has accepted a key as a trust anchor, the key
258 MUST be considered a valid trust anchor by that resolver until
259 explictly revoked as described above.
261 In the given example, the zone owner can recover from a compromise by
262 revoking B and adding a new key D and signing the DNSKEY RRSet with
265 The reason this does not completely solve the problem has to do with
266 the distributed nature of DNS. The resolver only knows what it sees.
267 A determined attacker who holds one compromised key could keep a
268 single resolver from realizing that key had been compromised by
269 intercepting 'real' data from the originating zone and substituting
270 their own (e.g. using the example, signed only by B). This is no
271 worse than the current situation assuming a compromised key.
273 2.3. Remove Hold-down
275 A new key which has been seen by the resolver, but hasn't reached
276 it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
280 StJohns Expires July 14, 2006 [Page 5]
282 Internet-Draft trustanchor-update January 2006
285 zone owner. If the resolver sees a validated DNSKEY RRSet without
286 this key, it waits for the remove hold-down time and then, if the key
287 hasn't reappeared, SHOULD discard any information about the key.
291 A resolver which has been configured for automatic update of keys
292 from a particular trust point MUST query that trust point (e.g. do a
293 lookup for the DNSKEY RRSet and related RRSIG records) no less often
294 than the lesser of 15 days or half the original TTL for the DNSKEY
295 RRSet or half the RRSIG expiration interval. The expiration interval
296 is the amount of time from when the RRSIG was last retrieved until
297 the expiration time in the RRSIG.
299 If the query fails, the resolver MUST repeat the query until
300 satisfied no more often than once an hour and no less often than the
301 lesser of 1 day or 10% of the original TTL or 10% of the original
304 2.5. Resolver Parameters
306 2.5.1. Add Hold-Down Time
308 The add hold-down time is 30 days or the expiration time of the TTL
309 of the first trust point DNSKEY RRSet which contained the key,
310 whichever is greater. This ensures that at least two validated
311 DNSKEY RRSets which contain the new key MUST be seen by the resolver
312 prior to the key's acceptance.
314 2.5.2. Remove Hold-Down Time
316 The remove hold-down time is 30 days.
318 2.5.3. Minimum Trust Anchors per Trust Point
320 A compliant resolver MUST be able to manage at least five SEP keys
324 3. Changes to DNSKEY RDATA Wire Format
326 Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
327 flag. If this bit is set to '1', AND the resolver sees an
328 RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
329 consider this key permanently invalid for all purposes except for
330 validing the revocation.
336 StJohns Expires July 14, 2006 [Page 6]
338 Internet-Draft trustanchor-update January 2006
343 The most important thing to understand is the resolver's view of any
344 key at a trust point. The following state table describes that view
345 at various points in the key's lifetime. The table is a normative
346 part of this specification. The initial state of the key is 'Start'.
347 The resolver's view of the state of the key changes as various events
350 [msj1] This is the state of a trust point key as seen from the
351 resolver. The column on the left indicates the current state. The
352 header at the top shows the next state. The intersection of the two
353 shows the event that will cause the state to transition from the
354 current state to the next.
357 --------------------------------------------------
358 FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
359 ----------------------------------------------------------
360 Start | |NewKey | | | | |
361 ----------------------------------------------------------
362 AddPend |KeyRem | |AddTime| | |
363 ----------------------------------------------------------
364 Valid | | | |KeyRem |Revbit | |
365 ----------------------------------------------------------
366 Missing | | |KeyPres| |Revbit | |
367 ----------------------------------------------------------
368 Revoked | | | | | |RemTime|
369 ----------------------------------------------------------
370 Removed | | | | | | |
371 ----------------------------------------------------------
374 NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
375 That key will become a new trust anchor for the named trust point
376 after its been present in the RRSet for at least 'add time'.
377 KeyPres The key has returned to the valid DNSKEY RRSet.
378 KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
380 AddTime The key has been in every valid DNSKEY RRSet seen for at
381 least the 'add time'.
382 RemTime A revoked key has been missing from the trust point DNSKEY
383 RRSet for sufficient time to be removed from the trust set.
384 RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
385 "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
392 StJohns Expires July 14, 2006 [Page 7]
394 Internet-Draft trustanchor-update January 2006
398 Start The key doesn't yet exist as a trust anchor at the resolver.
399 It may or may not exist at the zone server, but hasn't yet been
400 seen at the resolver.
401 AddPend The key has been seen at the resolver, has its 'SEP' bit set,
402 and has been included in a validated DNSKEY RRSet. There is a
403 hold-down time for the key before it can be used as a trust
405 Valid The key has been seen at the resolver and has been included in
406 all validated DNSKEY RRSets from the time it was first seen up
407 through the hold-down time. It is now valid for verifying RRSets
408 that arrive after the hold down time. Clarification: The DNSKEY
409 RRSet does not need to be continuously present at the resolver
410 (e.g. its TTL might expire). If the RRSet is seen, and is
411 validated (i.e. verifies against an existing trust anchor), this
412 key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
413 Missing This is an abnormal state. The key remains as a valid trust
414 point key, but was not seen at the resolver in the last validated
415 DNSKEY RRSet. This is an abnormal state because the zone operator
416 should be using the REVOKE bit prior to removal. [Discussion
417 item: Should a missing key be considered revoked after some period
419 Revoked This is the state a key moves to once the resolver sees an
420 RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
421 this key with its REVOKE bit set to '1'. Once in this state, this
422 key MUST permanently be considered invalid as a trust anchor.
423 Removed After a fairly long hold-down time, information about this
424 key may be purged from the resolver. A key in the removed state
425 MUST NOT be considered a valid trust anchor.
427 4.3. Trust Point Deletion
429 A trust point which has all of its trust anchors revoked is
430 considered deleted and is treated as if the trust point was never
431 configured. If there are no superior trust points, data at and below
432 the deleted trust point are considered insecure. If there there ARE
433 superior trust points, data at and below the deleted trust point are
434 evaluated with respect to the superior trust point.
439 The suggested model for operation is to have one active key and one
440 stand-by key at each trust point. The active key will be used to
441 sign the DNSKEY RRSet. The stand-by key will not normally sign this
442 RRSet, but the resolver will accept it as a trust anchor if/when it
443 sees the signature on the trust point DNSKEY RRSet.
448 StJohns Expires July 14, 2006 [Page 8]
450 Internet-Draft trustanchor-update January 2006
453 Since the stand-by key is not in active signing use, the associated
454 private key may (and SHOULD) be provided with additional protections
455 not normally available to a key that must be used frequently. E.g.
456 locked in a safe, split among many parties, etc. Notionally, the
457 stand-by key should be less subject to compromise than an active key,
458 but that will be dependent on operational concerns not addressed
461 5.1. Adding A Trust Anchor
463 Assume an existing trust anchor key 'A'.
464 1. Generate a new key pair.
465 2. Create a DNSKEY record from the key pair and set the SEP and Zone
467 3. Add the DNSKEY to the RRSet.
468 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
472 5.2. Deleting a Trust Anchor
474 Assume existing trust anchors 'A' and 'B' and that you want to revoke
476 1. Set the revolcation bit on key 'A'.
477 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
478 'A' is now revoked. The operator SHOULD include the revoked 'A' in
479 the RRSet for at least the remove hold-down time, but then may remove
480 it from the DNSKEY RRSet.
484 Assume existing keys A and B. 'A' is actively in use (i.e. has been
485 signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
486 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
487 used to sign the RRSet.)
488 1. Generate a new key pair 'C'.
489 2. Add 'C' to the DNSKEY RRSet.
490 3. Set the revocation bit on key 'A'.
491 4. Sign the RRSet with 'A' and 'B'.
492 'A' is now revoked, 'B' is now the active key, and 'C' will be the
493 stand-by key once the hold-down expires. The operator SHOULD include
494 the revoked 'A' in the RRSet for at least the remove hold-down time,
495 but may then remove it from the DNSKEY RRSet.
497 5.4. Active Key Compromised
499 This is the same as the mechanism for Key Roll-Over (Section 5.3)
500 above assuming 'A' is the active key.
504 StJohns Expires July 14, 2006 [Page 9]
506 Internet-Draft trustanchor-update January 2006
509 5.5. Stand-by Key Compromised
511 Using the same assumptions and naming conventions as Key Roll-Over
513 1. Generate a new key pair 'C'.
514 2. Add 'C' to the DNSKEY RRSet.
515 3. Set the revocation bit on key 'B'.
516 4. Sign the RRSet with 'A' and 'B'.
517 'B' is now revoked, 'A' remains the active key, and 'C' will be the
518 stand-by key once the hold-down expires. 'B' SHOULD continue to be
519 included in the RRSet for the remove hold-down time.
522 6. IANA Considerations
524 The IANA will need to assign a bit in the DNSKEY flags field (see
525 section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
526 IANA actions required.
529 7. Security Considerations
531 7.1. Key Ownership vs Acceptance Policy
533 The reader should note that, while the zone owner is responsible
534 creating and distributing keys, it's wholly the decision of the
535 resolver owner as to whether to accept such keys for the
536 authentication of the zone information. This implies the decision
537 update trust anchor keys based on trust for a current trust anchor
538 key is also the resolver owner's decision.
540 The resolver owner (and resolver implementers) MAY choose to permit
541 or prevent key status updates based on this mechanism for specific
542 trust points. If they choose to prevent the automated updates, they
543 will need to establish a mechanism for manual or other out-of-band
544 updates outside the scope of this document.
546 7.2. Multiple Key Compromise
548 This scheme permits recovery as long as at least one valid trust
549 anchor key remains uncompromised. E.g. if there are three keys, you
550 can recover if two of them are compromised. The zone owner should
551 determine their own level of comfort with respect to the number of
552 active valid trust anchors in a zone and should be prepared to
553 implement recovery procedures once they detect a compromise. A
554 manual or other out-of-band update of all resolvers will be required
555 if all trust anchor keys at a trust point are compromised.
560 StJohns Expires July 14, 2006 [Page 10]
562 Internet-Draft trustanchor-update January 2006
567 Allowing a resolver to update its trust anchor set based in-band key
568 information is potentially less secure than a manual process.
569 However, given the nature of the DNS, the number of resolvers that
570 would require update if a trust anchor key were compromised, and the
571 lack of a standard management framework for DNS, this approach is no
572 worse than the existing situation.
574 8. Normative References
576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
577 Requirement Levels", BCP 14, RFC 2119, March 1997.
579 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
580 RFC 2535, March 1999.
582 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
583 Signer (DS)", RFC 3755, May 2004.
585 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
586 Rose, "DNS Security Introduction and Requirements",
587 RFC 4033, March 2005.
589 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
590 Rose, "Resource Records for the DNS Security Extensions",
591 RFC 4034, March 2005.
593 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
594 Rose, "Protocol Modifications for the DNS Security
595 Extensions", RFC 4035, March 2005.
599 [msj1] msj: N.B. This table is preliminary and will be revised to
600 match implementation experience. For example, should there
601 be a state for "Add hold-down expired, but haven't seen the
604 [msj2] msj: To be assigned.
606 [msj3] msj: For discussion: What's the implementation guidance for
607 resolvers currently with respect to the non-assigned flag
608 bits? If they consider the flag bit when doing key matching
609 at the trust anchor, they won't be able to match.
616 StJohns Expires July 14, 2006 [Page 11]
618 Internet-Draft trustanchor-update January 2006
626 Redwood City, CA 94063
629 Phone: +1-301-528-4729
630 Email: Mike.StJohns@nominum.com
672 StJohns Expires July 14, 2006 [Page 12]
674 Internet-Draft trustanchor-update January 2006
677 Intellectual Property Statement
679 The IETF takes no position regarding the validity or scope of any
680 Intellectual Property Rights or other rights that might be claimed to
681 pertain to the implementation or use of the technology described in
682 this document or the extent to which any license under such rights
683 might or might not be available; nor does it represent that it has
684 made any independent effort to identify any such rights. Information
685 on the procedures with respect to rights in RFC documents can be
686 found in BCP 78 and BCP 79.
688 Copies of IPR disclosures made to the IETF Secretariat and any
689 assurances of licenses to be made available, or the result of an
690 attempt made to obtain a general license or permission for the use of
691 such proprietary rights by implementers or users of this
692 specification can be obtained from the IETF on-line IPR repository at
693 http://www.ietf.org/ipr.
695 The IETF invites any interested party to bring to its attention any
696 copyrights, patents or patent applications, or other proprietary
697 rights that may cover technology that may be required to implement
698 this standard. Please address the information to the IETF at
702 Disclaimer of Validity
704 This document and the information contained herein are provided on an
705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
707 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
708 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
709 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
715 Copyright (C) The Internet Society (2006). This document is subject
716 to the rights, licenses and restrictions contained in BCP 78, and
717 except as set forth therein, the authors retain all their rights.
722 Funding for the RFC Editor function is currently provided by the
728 StJohns Expires July 14, 2006 [Page 13]