As per Relevance of the word assigned, we have this rfc below:
Network Working Group D. Eastlake, 3
Request for Comments: 2930
Category: Standards Track September 2000
Secret Key Establishment for DNS (TKEY RR
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
[RFC 2845] provides a means of authenticating Domain Name
(DNS) queries and responses using shared secret keys via
Transaction Signature (TSIG) resource record (RR). However,
provides no mechanism for setting up such keys other than
exchange. This document describes a Transaction Key (TKEY) RR
can be used in a number of different modes to establish shared
keys between a DNS resolver and server
The comments and ideas of the following persons (listed in
order) have been incorporated herein and are gratefully acknowledged
Olafur Gudmundsson (TIS
Stuart Kwan (Microsoft
Ed Lewis (TIS
Erik Nordmark (SUN
Brian Wellington (Nominum
Eastlake Standards Track [Page 1]
RFC 2930 The DNS TKEY RR September 2000
Table of
1. Introduction............................................... 2
1.1 Overview of Contents...................................... 3
2. The TKEY Resource Record................................... 4
2.1 The Name Field............................................ 4
2.2 The TTL Field............................................. 5
2.3 The Algorithm Field....................................... 5
2.4 The Inception and Expiration Fields....................... 5
2.5 The Mode Field............................................ 5
2.6 The Error Field........................................... 6
2.7 The Key Size and Data Fields.............................. 6
2.8 The Other Size and Data Fields............................ 6
3. General TKEY Considerations................................ 7
4. Exchange via Resolver Query................................ 8
4.1 Query for Diffie-Hellman Exchanged Keying................. 8
4.2 Query for TKEY Deletion................................... 9
4.3 Query for GSS-API Establishment........................... 10
4.4 Query for Server Assigned Keying.......................... 10
4.5 Query for Resolver Assigned Keying........................ 11
5. Spontaneous Server Inclusion............................... 12
5.1 Spontaneous Server Key Deletion........................... 12
6. Methods of Encryption...................................... 12
7. IANA Considerations........................................ 13
8. Security Considerations.................................... 13
References.................................................... 14
Author's Address.............................................. 15
Full Copyright Statement...................................... 16
1.
The Domain Name System (DNS) is a hierarchical, distributed,
available database used for bi-directional mapping between
names and addresses, for email routing, and for other
[RFC 1034, 1035]. It has been extended to provide for public
security and dynamic update [RFC 2535, RFC 2136]. Familiarity
these RFCs is assumed
[RFC 2845] provides a means of efficiently authenticating
messages using shared secret keys via the TSIG resource record (RR
but provides no mechanism for setting up such keys other than
exchange. This document specifies a TKEY RR that can be used in
number of different modes to establish and delete such shared
keys between a DNS resolver and server
Eastlake Standards Track [Page 2]
RFC 2930 The DNS TKEY RR September 2000
Note that TKEY established keying material and TSIGs that use it
associated with DNS servers or resolvers. They are not
with zones. They may be used to authenticate queries and
but they do not provide zone based DNS data origin or
authentication [RFC 2535].
Certain modes of TKEY perform encryption which may affect
export or import status for some countries. The affected
specified in this document are the server assigned mode and
resolver assigned mode
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC 2119].
In all cases herein, the term "resolver" includes that part of
server which may make full and incremental [RFC 1995] zone
queries, forwards recursive queries, etc
1.1 Overview of
Section 2 below specifies the TKEY RR and provides a description
and considerations for its constituent fields
Section 3 describes general principles of operations with TKEY
Section 4 discusses key agreement and deletion via DNS requests
the Query opcode for RR type TKEY. This method is applicable to
currently defined TKEY modes, although in some cases it is not
would intuitively be called a "query".
Section 5 discusses spontaneous inclusion of TKEY RRs in responses
servers which is currently used only for key deletion
Section 6 describes encryption methods for transmitting secret
information. In this document these are used only for the
assigned mode and the resolver assigned mode
Section 7 covers IANA considerations in assignment of TKEY modes
Finally, Section 8 provides the required security
section
Eastlake Standards Track [Page 3]
RFC 2930 The DNS TKEY RR September 2000
2. The TKEY Resource
The TKEY resource record (RR) has the structure given below. Its
type code is 249.
Field Type
----- ---- -------
NAME domain see description
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY
TTL u_int32_t ignored, SHOULD be
RDLEN u_int16_t size of
RDATA
Algorithm:
Inception: u_int32_
Expiration: u_int32_
Mode: u_int16_
Error: u_int16_
Key Size: u_int16_
Key Data: octet-
Other Size: u_int16_
Other Data: octet-stream undefined by this
2.1 The Name
The Name field relates to naming keys. Its meaning differs
with mode and context as explained in subsequent sections
At any DNS server or resolver only one octet string of
material may be in place for any particular key name. An attempt
establish another set of keying material at a server for an
name returns a BADNAME error
For a TKEY with a non-root name appearing in a query, the TKEY
name SHOULD be a domain locally unique at the resolver, less than 128
octets long in wire encoding, and meaningful to the resolver
assist in distinguishing keys and/or key agreement sessions.
TKEY(s) appearing in a response to a query, the TKEY RR name
be a globally unique server assigned domain
A reasonable key naming strategy is as follows
If the key is generated as the result of a query with root as
owner name, then the server SHOULD create a globally unique
name, to be the key name, by suffixing a pseudo-random [RFC 1750]
label with a domain name of the server. For
89n3mDgX072pp.server1.example.com. If generation of a
Eastlake Standards Track [Page 4]
RFC 2930 The DNS TKEY RR September 2000
pseudo-random name in each case is an excessive computation
or entropy drain, a serial number prefix can be added to a
pseudo-random name generated an DNS server start time, such
1001.89n3mDgX072pp.server1.example.com
If the key is generated as the result of a query with a non-
name, say 789.resolver.example.net, then use the concatenation
that with a name of the server. For
789.resolver.example.net.server1.example.com
2.2 The TTL
The TTL field is meaningless in TKEY RRs. It SHOULD always be zero
be sure that older DNS implementations do not cache TKEY RRs
2.3 The Algorithm
The algorithm name is in the form of a domain name with the
meaning as in [RFC 2845]. The algorithm determines how the
keying material agreed to using the TKEY RR is actually used
derive the algorithm specific key
2.4 The Inception and Expiration
The inception time and expiration times are in number of
since the beginning of 1 January 1970 GMT ignoring leap
treated as modulo 2**32 using ring arithmetic [RFC 1982]. In
between a DNS resolver and a DNS server where these fields
meaningful, they are either the requested validity interval for
keying material asked for or specify the validity interval of
material provided
To avoid different interpretations of the inception and
times in TKEY RRs, resolvers and servers exchanging them must
the same idea of what time it is. One way of doing this is with
NTP protocol [RFC 2030] but that or any other time
used for this purpose MUST be done securely
2.5 The Mode
The mode field specifies the general scheme for key agreement or
purpose of the TKEY DNS message. Servers and resolvers
this specification MUST implement the Diffie-Hellman key
mode and the key deletion mode for queries. All other modes
OPTIONAL. A server supporting TKEY that receives a TKEY request
a mode it does not support returns the BADMODE error. The
values of the Mode octet are defined, available, or reserved
Eastlake Standards Track [Page 5]
RFC 2930 The DNS TKEY RR September 2000
Value
----- -----------
0 - reserved, see section 7
1 server
2 Diffie-Hellman
3 GSS-API
4 resolver
5 key
6-65534 - available, see section 7
65535 - reserved, see section 7
2.6 The Error
The error code field is an extended RCODE. The following values
defined
Value
----- -----------
0 - no
1-15 a non-extended
16 BADSIG (TSIG
17 BADKEY (TSIG
18 BADTIME (TSIG
19
20
21
When the TKEY Error Field is non-zero in a response to a TKEY query
the DNS header RCODE field indicates no error. However, it
possible if a TKEY is spontaneously included in a response the
RR and DNS header error field could have unrelated non-zero
codes
2.7 The Key Size and Data
The key data size field is an unsigned 16 bit integer in
order which specifies the size of the key exchange data field
octets. The meaning of this data depends on the mode
2.8 The Other Size and Data
The Other Size and Other Data fields are not used in
specification but may be used in future extensions. The RDLEN
MUST equal the length of the RDATA section through the end of
Data or the RR is to be considered malformed and rejected
Eastlake Standards Track [Page 6]
RFC 2930 The DNS TKEY RR September 2000
3. General TKEY
TKEY is a meta-RR that is not stored or cached in the DNS and
not appear in zone files. It supports a variety of modes for
establishment and deletion of shared secret keys information
DNS resolvers and servers. The establishment of such a shared
requires that state be maintained at both ends and the allocation
the resources to maintain such state may require mutual agreement.
the absence of willingness to provide such state, servers MUST
errors such as NOTIMP or REFUSED for an attempt to use TKEY
resolvers are free to ignore any TKEY RRs they receive
The shared secret keying material developed by using TKEY is a
octet sequence. The means by which this shared secret
material, exchanged via TKEY, is actually used in any particular
algorithm is algorithm dependent and is defined in connection
that algorithm. For example, see [RFC 2104] for how TKEY
shared secret keying material is used in the HMAC-MD5 algorithm
other HMAC algorithms
There MUST NOT be more than one TKEY RR in a DNS query or response
Except for GSS-API mode, TKEY responses MUST always have
transaction authentication to protect the integrity of any
data, error codes, etc. This authentication MUST use a
established secret (TSIG) or public (SIG(0) [RFC 2931]) key and
NOT use any key that the response to be verified is itself providing
TKEY queries MUST be authenticated for all modes except GSS-API and
under some circumstances, server assignment mode. In particular,
the query for a server assigned key is for a key to assert
privilege, such as update authority, then the query must
authenticated to avoid spoofing. However, if the key is just to
used for transaction security, then spoofing will lead at worst
denial of service. Query authentication SHOULD use an
secret (TSIG) key authenticator if available. Otherwise, it must
a public (SIG(0)) key signature. It MUST NOT use any key that
query is itself providing
In the absence of required TKEY authentication, a NOTAUTH error
be returned
To avoid replay attacks, it is necessary that a TKEY response
query not be valid if replayed on the order of 2**32 second (
136 years), or a multiple thereof, later. To accomplish this,
keying material used in any TSIG or SIG(0) RR that authenticates
TKEY message MUST NOT have a lifetime of more then 2**31 - 1
Eastlake Standards Track [Page 7]
RFC 2930 The DNS TKEY RR September 2000
(about 68 years). Thus, on attempted replay, the authenticating
or SIG(0) RR will not be verifiable due to key expiration and
replay will fail
4. Exchange via Resolver
One method for a resolver and a server to agree about shared
keying material for use in TSIG is through DNS requests from
resolver which are syntactically DNS queries for type TKEY.
queries MUST be accompanied by a TKEY RR in the
information section to indicate the mode in use and accompanied
other information where required
Type TKEY queries SHOULD NOT be flagged as recursive and servers
ignore the recursive header bit in TKEY queries they receive
4.1 Query for Diffie-Hellman Exchanged
Diffie-Hellman (DH) key exchange is a means whereby two parties
derive some shared secret information without requiring any
of the messages they exchange [Schneier]. Provisions have been
for the storage of DH public keys in the DNS [RFC 2539].
A resolver sends a query for type TKEY accompanied by a TKEY RR
the additional information section specifying the Diffie-Hellman
and accompanied by a KEY RR also in the additional
section specifying a resolver Diffie-Hellman key. The TKEY
algorithm field is set to the authentication algorithm the
plans to use. The "key data" provided in the TKEY is used as a
[RFC 1750] nonce to avoid always deriving the same keying
for the same pair of DH KEYs
The server response contains a TKEY in its answer section with
Diffie-Hellman mode. The "key data" provided in this TKEY is used
an additional nonce to avoid always deriving the same keying
for the same pair of DH KEYs. If the TKEY error field is non-zero
the query failed for the reason given. FORMERR is given if the
included no DH KEY and BADKEY is given if the query included
incompatible DH KEY
If the TKEY error field is zero, the resolver supplied Diffie-
KEY RR SHOULD be echoed in the additional information section and
server Diffie-Hellman KEY RR will also be present in the
section of the response. Both parties can then calculate the
shared secret quantity from the pair of Diffie-Hellman (DH) keys
[Schneier] (provided these DH keys use the same generator
modulus) and the data in the TKEY RRs. The TKEY RR data is
with the DH result as follows
Eastlake Standards Track [Page 8]
RFC 2930 The DNS TKEY RR September 2000
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )
Where XOR is an exclusive-OR operation and "|" is byte-
concatenation. The shorter of the two operands to XOR is byte-
left justified and padded with zero-valued bytes to match the
of the other operand. "DH value" is the Diffie-Hellman value
from the KEY RRs. Query data and server data are the values sent
the TKEY RR data fields. These "query data" and "server data"
are suffixed by the DH value, digested by MD5, the
concatenated, and then XORed with the DH value
The inception and expiry times in the query TKEY RR are
requested for the keying material. The inception and expiry times
the response TKEY RR are the maximum period the server will
the keying material valid. Servers may pre-expire keys so this
not a guarantee
4.2 Query for TKEY
Keys established via TKEY can be treated as soft state. Since
transactions are originated by the resolver, the resolver can
toss keys, although it may have to go through another key exchange
it later needs one. Similarly, the server can discard keys
that will result in an error on receiving a query with a TSIG
the discarded key
To avoid attempted reliance in requests on keys no longer in effect
servers MUST implement key deletion whereby the server "discards"
key on receipt from a resolver of an authenticated delete request
a TKEY RR with the key's name. If the server has no record of a
with that name, it returns BADNAME
Key deletion TKEY queries MUST be authenticated. This
MAY be a TSIG RR using the key to be deleted
For querier assigned and Diffie-Hellman keys, the server MUST
"discard" all active state associated with the key. For
assigned keys, the server MAY simply mark the key as no
retained by the client and may re-send it in response to a
query for server assigned keying material
Eastlake Standards Track [Page 9]
RFC 2930 The DNS TKEY RR September 2000
4.3 Query for GSS-API
This mode is described in a separate document under preparation
should be seen for the full description. Basically the resolver
server can exchange queries and responses for type TKEY with a
RR specifying the GSS-API mode in the additional information
and a GSS-API token in the key data portion of the TKEY RR
Any issues of possible encryption of parts the GSS-API token
being transmitted are handled by the GSS-API level. In addition,
GSS-API level provides its own authentication so that this mode
TKEY query and response MAY be, but do not need to be,
with TSIG RR or SIG(0) RR [RFC 2931].
The inception and expiry times in a GSS-API mode TKEY RR are ignored
4.4 Query for Server Assigned
Optionally, the server can assign keying for the resolver. It
sent to the resolver encrypted under a resolver public key.
section 6 for description of encryption methods
A resolver sends a query for type TKEY accompanied by a TKEY
specifying the "server assignment" mode and a resolver KEY RR to
used in encrypting the response, both in the additional
section. The TKEY algorithm field is set to the
algorithm the resolver plans to use. It is RECOMMENDED that any "
data" provided in the query TKEY RR by the resolver be strongly
by the server with server generated randomness [RFC 1750] to
the keying material to be used. The KEY RR that appears in the
need not be accompanied by a SIG(KEY) RR. If the query
authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0)
and that authentication is verified, then any SIG(KEY) provided
the query SHOULD be ignored. The KEY RR in such a query SHOULD
a name that corresponds to the resolver but it is only essential
it be a public key for which the resolver has the
private key so it can decrypt the response data
The server response contains a TKEY RR in its answer section with
server assigned mode and echoes the KEY RR provided in the query
its additional information section
If the response TKEY error field is zero, the key data portion of
response TKEY RR will be the server assigned keying data
under the public key in the resolver provided KEY RR. In this case
the owner name of the answer TKEY RR will be the server assigned
of the key
Eastlake Standards Track [Page 10]
RFC 2930 The DNS TKEY RR September 2000
If the error field of the response TKEY is non-zero, the query
for the reason given. FORMERR is given if the query specified
encryption key
The inception and expiry times in the query TKEY RR are
requested for the keying material. The inception and expiry times
the response TKEY are the maximum period the server will consider
keying material valid. Servers may pre-expire keys so this is not
guarantee
The resolver KEY RR MUST be authenticated, through the
of this query with a TSIG or SIG(0) or the signing of the
KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver
for which they know the private key, and thereby the attacker
obtain a valid shared secret key from the server
4.5 Query for Resolver Assigned
Optionally, a server can accept resolver assigned keys. The
material MUST be encrypted under a server key for protection
transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies
encrypted keying material and a KEY RR specifying the server
key used to encrypt the data, both in the additional
section. The name of the key and the keying data are
controlled by the sending resolver so a globally unique key
SHOULD be used. The KEY RR used MUST be one for which the server
the corresponding private key, or it will not be able to decrypt
keying material and will return a FORMERR. It is also important
no untrusted party (preferably no other party than the server)
the private key corresponding to the KEY RR because, if they do,
can capture the messages to the server, learn the shared secret,
spoof valid TSIGs
The query TKEY RR inception and expiry give the time period
querier intends to consider the keying material valid. The
can return a lesser time interval to advise that it will not
state for that long and can pre-expire keys in any case
This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query,
thereby the attacker could specify a shared secret key that would
accepted, used, and honored by the server
Eastlake Standards Track [Page 11]
RFC 2930 The DNS TKEY RR September 2000
5. Spontaneous Server
A DNS server may include a TKEY RR spontaneously as
information in responses. This SHOULD only be done if the
knows the querier understands TKEY and has this option implemented
This technique can be used to delete a key and may be specified
modes defined in the future. A disadvantage of this technique
that there is no way for the server to get any error or
indication back and, in the case of UDP, no way to even know if
DNS response reached the resolver
5.1 Spontaneous Server Key
A server can optionally tell a client that it has deleted a
key by spontaneously including a TKEY RR in the
information section of a response with the key's name and
the key deletion mode. Such a response SHOULD be authenticated.
authenticated, it "deletes" the key with the given name.
inception and expiry times of the delete TKEY RR are ignored.
by a client to receive or properly process such
information in a response would mean that the client might use a
that the server had discarded and would then get an error indication
For server assigned and Diffie-Hellman keys, the client
"discard" active state associated with the key. For querier
keys, the querier MAY simply mark the key as no longer retained
the server and may re-send it in a future query specifying
assigned keying material
6. Methods of
For the server assigned and resolver assigned key agreement modes
the keying material is sent within the key data field of a TKEY
encrypted under the public key in an accompanying KEY RR [RFC 2535].
This KEY RR MUST be for a public key algorithm where the public
private keys can be used for encryption and the
decryption which recovers the originally encrypted data. The KEY
SHOULD correspond to a name for the decrypting resolver/server
that the decrypting process has access to the corresponding
key to decrypt the data. The secret keying material being sent
generally be fairly short, usually less than 256 bits, because
is adequate for very strong protection with modern keyed hash
symmetric algorithms
If the KEY RR specifies the RSA algorithm, then the keying
is encrypted as per the description of RSAES-PKCS1-v1_5 encryption
PKCS#1 [RFC 2437]. (Note, the secret keying material being sent
directly RSA encrypted in PKCS#1 format. It is not "enveloped"
Eastlake Standards Track [Page 12]
RFC 2930 The DNS TKEY RR September 2000
some other symmetric algorithm.) In the unlikely event that
keying material will not fit within one RSA modulus of the
public key, additional RSA encryption blocks are included.
length of each block is clear from the public RSA key specified
the RSAES-PKCS1-v1_5 padding makes it clear what part of
encrypted data is actually keying material and what part
formatting or the required at least eight bytes of random [RFC 1750]
padding
7. IANA
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 and 0xFFFF are reserved
Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0
can only be assigned by an IETF Standards Action
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0
are allocated by IESG approval or IETF consensus
Mode field values 0x1000 through 0xEFFF are allocated based
Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their
changes. For example, a mode value assigned based just on
a specification should not be changed later just because that use'
status is changed to standards track
The following assignments are documented herein
RR Type 249 for TKEY
TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in
2.6.
8. Security
The entirety of this specification is concerned with the
establishment of a shared secret between DNS clients and servers
support of TSIG [RFC 2845].
Protection against denial of service via the use of TKEY is
provided
Eastlake Standards Track [Page 13]
RFC 2930 The DNS TKEY RR September 2000
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols
Algorithms, and Source Code in C", 1996, John Wiley
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "
Recommendations for Security", RFC 1750, December 1994.
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
September 1996.
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104,
1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA
Specifications Version 2.0", RFC 2437, October 1998.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in
Domain Name System (DNS)", RFC 2539, March 1999.
Eastlake Standards Track [Page 14]
RFC 2930 The DNS TKEY RR September 2000
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B
Wellington, "Secret Key Transaction Authentication for
(TSIG)", RFC 2845, May 2000.
[RFC 2931] Eastlake, D., "DNS Request and Transaction
(SIG(0)s )", RFC 2931, September 2000.
Author's
Donald E. Eastlake 3
140 Forest
Hudson, MA 01749
Phone: +1 978-562-2827 (h
+1 508-261-5434 (w
Fax: +1 508-261-4447 (w
EMail: Donald.Eastlake@motorola.
Eastlake Standards Track [Page 15]
RFC 2930 The DNS TKEY RR September 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Eastlake Standards Track [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
