etc/services - sync with NetBSD-8
[minix.git] / external / bsd / bind / dist / contrib / zkt-1.1.3 / doc / rfc5011.txt
blob42235e977f89ab77e86bee3f14ac261c123309d2
7 Network Working Group                                         M. StJohns
8 Request for Comments: 5011                                   Independent
9 Category: Standards Track                                 September 2007
12         Automated Updates of DNS Security (DNSSEC) Trust Anchors
14 Status of This Memo
16    This document specifies an Internet standards track protocol for the
17    Internet community, and requests discussion and suggestions for
18    improvements.  Please refer to the current edition of the "Internet
19    Official Protocol Standards" (STD 1) for the standardization state
20    and status of this protocol.  Distribution of this memo is unlimited.
22 Abstract
24    This document describes a means for automated, authenticated, and
25    authorized updating of DNSSEC "trust anchors".  The method provides
26    protection against N-1 key compromises of N keys in the trust point
27    key set.  Based on the trust established by the presence of a current
28    anchor, other anchors may be added at the same place in the
29    hierarchy, and, ultimately, supplant the existing anchor(s).
31    This mechanism will require changes to resolver management behavior
32    (but not resolver resolution behavior), and the addition of a single
33    flag bit to the DNSKEY record.
58 StJohns                     Standards Track                     [Page 1]
60 RFC 5011                  Trust Anchor Update             September 2007
63 Table of Contents
65    1. Introduction ....................................................2
66       1.1. Compliance Nomenclature ....................................3
67    2. Theory of Operation .............................................3
68       2.1. Revocation .................................................4
69       2.2. Add Hold-Down ..............................................4
70       2.3. Active Refresh .............................................5
71       2.4. Resolver Parameters ........................................6
72            2.4.1. Add Hold-Down Time ..................................6
73            2.4.2. Remove Hold-Down Time ...............................6
74            2.4.3. Minimum Trust Anchors per Trust Point ...............6
75    3. Changes to DNSKEY RDATA Wire Format .............................6
76    4. State Table .....................................................6
77       4.1. Events .....................................................7
78       4.2. States .....................................................7
79    5. Trust Point Deletion ............................................8
80    6. Scenarios - Informative .........................................9
81       6.1. Adding a Trust Anchor ......................................9
82       6.2. Deleting a Trust Anchor ....................................9
83       6.3. Key Roll-Over .............................................10
84       6.4. Active Key Compromised ....................................10
85       6.5. Stand-by Key Compromised ..................................10
86       6.6. Trust Point Deletion ......................................10
87    7. IANA Considerations ............................................11
88    8. Security Considerations ........................................11
89       8.1. Key Ownership vs. Acceptance Policy .......................11
90       8.2. Multiple Key Compromise ...................................12
91       8.3. Dynamic Updates ...........................................12
92    9. Normative References ...........................................12
93    10. Informative References ........................................12
95 1.  Introduction
97    As part of the reality of fielding DNSSEC (Domain Name System
98    Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
99    come to the realization that there will not be one signed name space,
100    but rather islands of signed name spaces each originating from
101    specific points (i.e., 'trust points') in the DNS tree.  Each of
102    those islands will be identified by the trust point name, and
103    validated by at least one associated public key.  For the purpose of
104    this document, we'll call the association of that name and a
105    particular key a 'trust anchor'.  A particular trust point can have
106    more than one key designated as a trust anchor.
108    For a DNSSEC-aware resolver to validate information in a DNSSEC
109    protected branch of the hierarchy, it must have knowledge of a trust
110    anchor applicable to that branch.  It may also have more than one
114 StJohns                     Standards Track                     [Page 2]
116 RFC 5011                  Trust Anchor Update             September 2007
119    trust anchor for any given trust point.  Under current rules, a chain
120    of trust for DNSSEC-protected data that chains its way back to ANY
121    known trust anchor is considered 'secure'.
123    Because of the probable balkanization of the DNSSEC tree due to
124    signing voids at key locations, a resolver may need to know literally
125    thousands of trust anchors to perform its duties (e.g., consider an
126    unsigned ".COM").  Requiring the owner of the resolver to manually
127    manage these many relationships is problematic.  It's even more
128    problematic when considering the eventual requirement for key
129    replacement/update for a given trust anchor.  The mechanism described
130    herein won't help with the initial configuration of the trust anchors
131    in the resolvers, but should make trust point key
132    replacement/rollover more viable.
134    As mentioned above, this document describes a mechanism whereby a
135    resolver can update the trust anchors for a given trust point, mainly
136    without human intervention at the resolver.  There are some corner
137    cases discussed (e.g., multiple key compromise) that may require
138    manual intervention, but they should be few and far between.  This
139    document DOES NOT discuss the general problem of the initial
140    configuration of trust anchors for the resolver.
142 1.1.  Compliance Nomenclature
144    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146    document are to be interpreted as described in BCP 14, [RFC2119].
148 2.  Theory of Operation
150    The general concept of this mechanism is that existing trust anchors
151    can be used to authenticate new trust anchors at the same point in
152    the DNS hierarchy.  When a zone operator adds a new SEP key (i.e., a
153    DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
154    2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
155    validated by an existing trust anchor, then the resolver can add the
156    new key to its set of valid trust anchors for that trust point.
158    There are some issues with this approach that need to be mitigated.
159    For example, a compromise of one of the existing keys could allow an
160    attacker to add their own 'valid' data.  This implies a need for a
161    method to revoke an existing key regardless of whether or not that
162    key is compromised.  As another example, assuming a single key
163    compromise, we need to prevent an attacker from adding a new key and
164    revoking all the other old keys.
170 StJohns                     Standards Track                     [Page 3]
172 RFC 5011                  Trust Anchor Update             September 2007
175 2.1.  Revocation
177    Assume two trust anchor keys A and B.  Assume that B has been
178    compromised.  Without a specific revocation bit, B could invalidate A
179    simply by sending out a signed trust point key set that didn't
180    contain A.  To fix this, we add a mechanism that requires knowledge
181    of the private key of a DNSKEY to revoke that DNSKEY.
183    A key is considered revoked when the resolver sees the key in a
184    self-signed RRSet and the key has the REVOKE bit (see Section 7
185    below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
186    NOT use this key as a trust anchor or for any other purpose except to
187    validate the RRSIG it signed over the DNSKEY RRSet specifically for
188    the purpose of validating the revocation.  Unlike the 'Add' operation
189    below, revocation is immediate and permanent upon receipt of a valid
190    revocation at the resolver.
192    A self-signed RRSet is a DNSKEY RRSet that contains the specific
193    DNSKEY and for which there is a corresponding validated RRSIG record.
194    It's not a special DNSKEY RRSet, just a way of describing the
195    validation requirements for that RRSet.
197    N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
198    than one without the bit set.  This affects the matching of a DNSKEY
199    to DS records in the parent [RFC3755], or the fingerprint stored at a
200    resolver used to configure a trust point.
202    In the given example, the attacker could revoke B because it has
203    knowledge of B's private key, but could not revoke A.
205 2.2.  Add Hold-Down
207    Assume two trust point keys A and B.  Assume that B has been
208    compromised.  An attacker could generate and add a new trust anchor
209    key C (by adding C to the DNSKEY RRSet and signing it with B), and
210    then invalidate the compromised key.  This would result in both the
211    attacker and owner being able to sign data in the zone and have it
212    accepted as valid by resolvers.
214    To mitigate but not completely solve this problem, we add a hold-down
215    time to the addition of the trust anchor.  When the resolver sees a
216    new SEP key in a validated trust point DNSKEY RRSet, the resolver
217    starts an acceptance timer, and remembers all the keys that validated
218    the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
219    new key but validly signed, it stops the acceptance process for that
220    key and resets the acceptance timer.  If all of the keys that were
226 StJohns                     Standards Track                     [Page 4]
228 RFC 5011                  Trust Anchor Update             September 2007
231    originally used to validate this key are revoked prior to the timer
232    expiring, the resolver stops the acceptance process and resets the
233    timer.
235    Once the timer expires, the new key will be added as a trust anchor
236    the next time the validated RRSet with the new key is seen at the
237    resolver.  The resolver MUST NOT treat the new key as a trust anchor
238    until the hold-down time expires AND it has retrieved and validated a
239    DNSKEY RRSet after the hold-down time that contains the new key.
241    N.B.: Once the resolver has accepted a key as a trust anchor, the key
242    MUST be considered a valid trust anchor by that resolver until
243    explicitly revoked as described above.
245    In the given example, the zone owner can recover from a compromise by
246    revoking B and adding a new key D and signing the DNSKEY RRSet with
247    both A and B.
249    The reason this does not completely solve the problem has to do with
250    the distributed nature of DNS.  The resolver only knows what it sees.
251    A determined attacker who holds one compromised key could keep a
252    single resolver from realizing that the key had been compromised by
253    intercepting 'real' data from the originating zone and substituting
254    their own (e.g., using the example, signed only by B).  This is no
255    worse than the current situation assuming a compromised key.
257 2.3.  Active Refresh
259    A resolver that has been configured for an automatic update of keys
260    from a particular trust point MUST query that trust point (e.g., do a
261    lookup for the DNSKEY RRSet and related RRSIG records) no less often
262    than the lesser of 15 days, half the original TTL for the DNSKEY
263    RRSet, or half the RRSIG expiration interval and no more often than
264    once per hour.  The expiration interval is the amount of time from
265    when the RRSIG was last retrieved until the expiration time in the
266    RRSIG.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
267    1/2*RRSigExpirationInterval))
269    If the query fails, the resolver MUST repeat the query until
270    satisfied no more often than once an hour and no less often than the
271    lesser of 1 day, 10% of the original TTL, or 10% of the original
272    expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
273    .1 * origTTL, .1 * expireInterval)).
282 StJohns                     Standards Track                     [Page 5]
284 RFC 5011                  Trust Anchor Update             September 2007
287 2.4.  Resolver Parameters
289 2.4.1.  Add Hold-Down Time
291    The add hold-down time is 30 days or the expiration time of the
292    original TTL of the first trust point DNSKEY RRSet that contained the
293    new key, whichever is greater.  This ensures that at least two
294    validated DNSKEY RRSets that contain the new key MUST be seen by the
295    resolver prior to the key's acceptance.
297 2.4.2.  Remove Hold-Down Time
299    The remove hold-down time is 30 days.  This parameter is solely a key
300    management database bookeeping parameter.  Failure to remove
301    information about the state of defunct keys from the database will
302    not adversely impact the security of this protocol, but may end up
303    with a database cluttered with obsolete key information.
305 2.4.3.  Minimum Trust Anchors per Trust Point
307    A compliant resolver MUST be able to manage at least five SEP keys
308    per trust point.
310 3.  Changes to DNSKEY RDATA Wire Format
312    Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
313    If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
314    signed by the associated key, then the resolver MUST consider this
315    key permanently invalid for all purposes except for validating the
316    revocation.
318 4.  State Table
320    The most important thing to understand is the resolver's view of any
321    key at a trust point.  The following state table describes this view
322    at various points in the key's lifetime.  The table is a normative
323    part of this specification.  The initial state of the key is 'Start'.
324    The resolver's view of the state of the key changes as various events
325    occur.
327    This is the state of a trust-point key as seen from the resolver.
328    The column on the left indicates the current state.  The header at
329    the top shows the next state.  The intersection of the two shows the
330    event that will cause the state to transition from the current state
331    to the next.
338 StJohns                     Standards Track                     [Page 6]
340 RFC 5011                  Trust Anchor Update             September 2007
343                              NEXT STATE
344            --------------------------------------------------
345     FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
346    ----------------------------------------------------------
347    Start   |       |NewKey  |       |       |       |       |
348    ----------------------------------------------------------
349    AddPend |KeyRem |        |AddTime|       |       |       |
350    ----------------------------------------------------------
351    Valid   |       |        |       |KeyRem |Revbit |       |
352    ----------------------------------------------------------
353    Missing |       |        |KeyPres|       |Revbit |       |
354    ----------------------------------------------------------
355    Revoked |       |        |       |       |       |RemTime|
356    ----------------------------------------------------------
357    Removed |       |        |       |       |       |       |
358    ----------------------------------------------------------
360                            State Table
362 4.1.  Events
364    NewKey   The resolver sees a valid DNSKEY RRSet with a new SEP key.
365             That key will become a new trust anchor for the named trust
366             point after it's been present in the RRSet for at least 'add
367             time'.
369    KeyPres  The key has returned to the valid DNSKEY RRSet.
371    KeyRem   The resolver sees a valid DNSKEY RRSet that does not contain
372             this key.
374    AddTime  The key has been in every valid DNSKEY RRSet seen for at
375             least the 'add time'.
377    RemTime  A revoked key has been missing from the trust-point DNSKEY
378             RRSet for sufficient time to be removed from the trust set.
380    RevBit   The key has appeared in the trust anchor DNSKEY RRSet with
381             its "REVOKED" bit set, and there is an RRSig over the DNSKEY
382             RRSet signed by this key.
384 4.2.  States
386    Start    The key doesn't yet exist as a trust anchor at the resolver.
387             It may or may not exist at the zone server, but either
388             hasn't yet been seen at the resolver or was seen but was
389             absent from the last DNSKEY RRSet (e.g., KeyRem event).
394 StJohns                     Standards Track                     [Page 7]
396 RFC 5011                  Trust Anchor Update             September 2007
399    AddPend  The key has been seen at the resolver, has its 'SEP' bit
400             set, and has been included in a validated DNSKEY RRSet.
401             There is a hold-down time for the key before it can be used
402             as a trust anchor.
404    Valid    The key has been seen at the resolver and has been included
405             in all validated DNSKEY RRSets from the time it was first
406             seen through the hold-down time.  It is now valid for
407             verifying RRSets that arrive after the hold-down time.
408             Clarification: The DNSKEY RRSet does not need to be
409             continuously present at the resolver (e.g., its TTL might
410             expire).  If the RRSet is seen and is validated (i.e.,
411             verifies against an existing trust anchor), this key MUST be
412             in the RRSet, otherwise a 'KeyRem' event is triggered.
414    Missing  This is an abnormal state.  The key remains a valid trust-
415             point key, but was not seen at the resolver in the last
416             validated DNSKEY RRSet.  This is an abnormal state because
417             the zone operator should be using the REVOKE bit prior to
418             removal.
420    Revoked  This is the state a key moves to once the resolver sees an
421             RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
422             contains this key with its REVOKE bit set to '1'.  Once in
423             this state, this key MUST permanently be considered invalid
424             as a trust anchor.
426    Removed  After a fairly long hold-down time, information about this
427             key may be purged from the resolver.  A key in the removed
428             state MUST NOT be considered a valid trust anchor.  (Note:
429             this state is more or less equivalent to the "Start" state,
430             except that it's bad practice to re-introduce previously
431             used keys -- think of this as the holding state for all the
432             old keys for which the resolver no longer needs to track
433             state.)
435 5.  Trust Point Deletion
437    A trust point that has all of its trust anchors revoked is considered
438    deleted and is treated as if the trust point was never configured.
439    If there are no superior configured trust points, data at and below
440    the deleted trust point are considered insecure by the resolver.  If
441    there ARE superior configured trust points, data at and below the
442    deleted trust point are evaluated with respect to the superior trust
443    point(s).
445    Alternately, a trust point that is subordinate to another configured
446    trust point MAY be deleted by a resolver after 180 days, where such a
450 StJohns                     Standards Track                     [Page 8]
452 RFC 5011                  Trust Anchor Update             September 2007
455    subordinate trust point validly chains to a superior trust point.
456    The decision to delete the subordinate trust anchor is a local
457    configuration decision.  Once the subordinate trust point is deleted,
458    validation of the subordinate zone is dependent on validating the
459    chain of trust to the superior trust point.
461 6.  Scenarios - Informative
463    The suggested model for operation is to have one active key and one
464    stand-by key at each trust point.  The active key will be used to
465    sign the DNSKEY RRSet.  The stand-by key will not normally sign this
466    RRSet, but the resolver will accept it as a trust anchor if/when it
467    sees the signature on the trust point DNSKEY RRSet.
469    Since the stand-by key is not in active signing use, the associated
470    private key may (and should) be provided with additional protections
471    not normally available to a key that must be used frequently (e.g.,
472    locked in a safe, split among many parties, etc).  Notionally, the
473    stand-by key should be less subject to compromise than an active key,
474    but that will be dependent on operational concerns not addressed
475    here.
477 6.1.  Adding a Trust Anchor
479    Assume an existing trust anchor key 'A'.
481    1.  Generate a new key pair.
483    2.  Create a DNSKEY record from the key pair and set the SEP and Zone
484        Key bits.
486    3.  Add the DNSKEY to the RRSet.
488    4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
489        'A'.
491    5.  Wait for various resolvers' timers to go off and for them to
492        retrieve the new DNSKEY RRSet and signatures.
494    6.  The new trust anchor will be populated at the resolvers on the
495        schedule described by the state table and update algorithm -- see
496        Sections 2 and 4 above.
498 6.2.  Deleting a Trust Anchor
500    Assume existing trust anchors 'A' and 'B' and that you want to revoke
501    and delete 'A'.
506 StJohns                     Standards Track                     [Page 9]
508 RFC 5011                  Trust Anchor Update             September 2007
511    1.  Set the revocation bit on key 'A'.
513    2.  Sign the DNSKEY RRSet with both 'A' and 'B'.  'A' is now revoked.
514        The operator should include the revoked 'A' in the RRSet for at
515        least the remove hold-down time, but then may remove it from the
516        DNSKEY RRSet.
518 6.3.  Key Roll-Over
520    Assume existing keys A and B. 'A' is actively in use (i.e. has been
521    signing the DNSKEY RRSet).  'B' was the stand-by key. (i.e. has been
522    in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
523    used to sign the RRSet).
525       1.  Generate a new key pair 'C'.
526       2.  Add 'C' to the DNSKEY RRSet.
527       3.  Set the revocation bit on key 'A'.
528       4.  Sign the RRSet with 'A' and 'B'.
530    'A' is now revoked, 'B' is now the active key, and 'C' will be the
531    stand-by key once the hold-down expires.  The operator should include
532    the revoked 'A' in the RRSet for at least the remove hold-down time,
533    but may then remove it from the DNSKEY RRSet.
535 6.4.  Active Key Compromised
537    This is the same as the mechanism for Key Roll-Over (Section 6.3)
538    above, assuming 'A' is the active key.
540 6.5.  Stand-by Key Compromised
542    Using the same assumptions and naming conventions as Key Roll-Over
543    (Section 6.3) above:
545       1.  Generate a new key pair 'C'.
546       2.  Add 'C' to the DNSKEY RRSet.
547       3.  Set the revocation bit on key 'B'.
548       4.  Sign the RRSet with 'A' and 'B'.
550    'B' is now revoked, 'A' remains the active key, and 'C' will be the
551    stand-by key once the hold-down expires.  'B' should continue to be
552    included in the RRSet for the remove hold-down time.
554 6.6.  Trust Point Deletion
556    To delete a trust point that is subordinate to another configured
557    trust point (e.g., example.com to .com) requires some juggling of the
558    data.  The specific process is:
562 StJohns                     Standards Track                    [Page 10]
564 RFC 5011                  Trust Anchor Update             September 2007
567    1.  Generate a new DNSKEY and DS record and provide the DS record to
568        the parent along with DS records for the old keys.
570    2.  Once the parent has published the DSs, add the new DNSKEY to the
571        RRSet and revoke ALL of the old keys at the same time, while
572        signing the DNSKEY RRSet with all of the old and new keys.
574    3.  After 30 days, stop publishing the old, revoked keys and remove
575        any corresponding DS records in the parent.
577    Revoking the old trust-point keys at the same time as adding new keys
578    that chain to a superior trust prevents the resolver from adding the
579    new keys as trust anchors.  Adding DS records for the old keys avoids
580    a race condition where either the subordinate zone becomes unsecure
581    (because the trust point was deleted) or becomes bogus (because it
582    didn't chain to the superior zone).
584 7.  IANA Considerations
586    The IANA has assigned a bit in the DNSKEY flags field (see Section 7
587    of [RFC4034]) for the REVOKE bit (8).
589 8.  Security Considerations
591    In addition to the following sections, see also Theory of Operation
592    above (Section 2) and especially Section 2.2 for related discussions.
594    Security considerations for trust anchor rollover not specific to
595    this protocol are discussed in [RFC4986].
597 8.1.  Key Ownership vs. Acceptance Policy
599    The reader should note that, while the zone owner is responsible for
600    creating and distributing keys, it's wholly the decision of the
601    resolver owner as to whether to accept such keys for the
602    authentication of the zone information.  This implies the decision to
603    update trust-anchor keys based on trusting a current trust-anchor key
604    is also the resolver owner's decision.
606    The resolver owner (and resolver implementers) MAY choose to permit
607    or prevent key status updates based on this mechanism for specific
608    trust points.  If they choose to prevent the automated updates, they
609    will need to establish a mechanism for manual or other out-of-band
610    updates, which are outside the scope of this document.
618 StJohns                     Standards Track                    [Page 11]
620 RFC 5011                  Trust Anchor Update             September 2007
623 8.2.  Multiple Key Compromise
625    This scheme permits recovery as long as at least one valid trust-
626    anchor key remains uncompromised, e.g., if there are three keys, you
627    can recover if two of them are compromised.  The zone owner should
628    determine their own level of comfort with respect to the number of
629    active, valid trust anchors in a zone and should be prepared to
630    implement recovery procedures once they detect a compromise.  A
631    manual or other out-of-band update of all resolvers will be required
632    if all trust-anchor keys at a trust point are compromised.
634 8.3.  Dynamic Updates
636    Allowing a resolver to update its trust anchor set based on in-band
637    key information is potentially less secure than a manual process.
638    However, given the nature of the DNS, the number of resolvers that
639    would require update if a trust anchor key were compromised, and the
640    lack of a standard management framework for DNS, this approach is no
641    worse than the existing situation.
643 9.  Normative References
645    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
646               Requirement Levels", BCP 14, RFC 2119, March 1997.
648    [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
649               Signer (DS)", RFC 3755, May 2004.
651    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
652               Rose, "DNS Security Introduction and Requirements", RFC
653               4033, March 2005.
655    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
656               Rose, "Resource Records for the DNS Security Extensions",
657               RFC 4034, March 2005.
659    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
660               Rose, "Protocol Modifications for the DNS Security
661               Extensions", RFC 4035, March 2005.
663 10.  Informative References
665    [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
666               "Requirements Related to DNS Security (DNSSEC) Trust
667               Anchor Rollover", RFC 4986, August 2007.
674 StJohns                     Standards Track                    [Page 12]
676 RFC 5011                  Trust Anchor Update             September 2007
679 Author's Address
681    Michael StJohns
682    Independent
684    EMail: mstjohns@comcast.net
730 StJohns                     Standards Track                    [Page 13]
732 RFC 5011                  Trust Anchor Update             September 2007
735 Full Copyright Statement
737    Copyright (C) The IETF Trust (2007).
739    This document is subject to the rights, licenses and restrictions
740    contained in BCP 78, and except as set forth therein, the authors
741    retain all their rights.
743    This document and the information contained herein are provided on an
744    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
745    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
746    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
747    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
748    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
749    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
751 Intellectual Property
753    The IETF takes no position regarding the validity or scope of any
754    Intellectual Property Rights or other rights that might be claimed to
755    pertain to the implementation or use of the technology described in
756    this document or the extent to which any license under such rights
757    might or might not be available; nor does it represent that it has
758    made any independent effort to identify any such rights.  Information
759    on the procedures with respect to rights in RFC documents can be
760    found in BCP 78 and BCP 79.
762    Copies of IPR disclosures made to the IETF Secretariat and any
763    assurances of licenses to be made available, or the result of an
764    attempt made to obtain a general license or permission for the use of
765    such proprietary rights by implementers or users of this
766    specification can be obtained from the IETF on-line IPR repository at
767    http://www.ietf.org/ipr.
769    The IETF invites any interested party to bring to its attention any
770    copyrights, patents or patent applications, or other proprietary
771    rights that may cover technology that may be required to implement
772    this standard.  Please address the information to the IETF at
773    ietf-ipr@ietf.org.
786 StJohns                     Standards Track                    [Page 14]