As per Relevance of the word mechanism, we have this rfc below:
Network Working Group R.
Request for Comments: 3163 Entrust
Category: Experimental M.
RSA
August 2001
ISO/IEC 9798-3 Authentication SASL
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
IESG
It is the opinion of the Security Area Directors that this
defines a mechanism to use a complex system (namely PKI certificates
for authentication, but then intentionally discards the key
(namely integrity on each transmission). Put another way, it has
of the pain of implementing a PKI and none of the benefits.
should not support it in use in Internet protocols
The same effect, with the benefits of PKI, can be had by
TLS/SSL, an existing already standards track protocol
This document defines a SASL (Simple Authentication and
Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS
196 entity authentication
Zuccherato & Nystrom Experimental [Page 1]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
1.
1.1.
This document defines a SASL [RFC2222] authentication mechanism
on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS]
authentication
This mechanism only provides authentication using X.509
[X509]. It has no effect on the protocol encodings and does
provide integrity or confidentiality services
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 [RFC2119].
The key benefit of asymmetric (public key) security, is that
secret (private key) only needs to be placed with the entity that
being authenticated. Thus, a private key can be issued to a client
which can then be authenticated by ANY server based on a
generated by the client and the generally available public key
Symmetric authentication mechanisms (password mechanisms such
CRAM-MD5 [RFC2195]) require a shared secret, and the need to
it at both endpoints. This means that a secret key for the
needs to be maintained at every server that may need to
the client
The service described in this memo provides authentication only
There are a number of places where an authentication only service
useful, e.g., where confidentiality and integrity are provided
lower layers, or where confidentiality or integrity services
provided by the application
1.2. Relationship to
The functionality defined here can be provided by TLS, and it
important to consider why it is useful to have it in both places
There are several reasons for this, e.g.:
- Simplicity. This mechanism is simpler than TLS. If there
only a requirement for this functionality (as distinct from
of TLS), this simplicity will facilitate deployment
- Layering. The SASL mechanism to establish authentication
cleanly with most protocols. This mechanism can fit
cleanly than TLS for some protocols
Zuccherato & Nystrom Experimental [Page 2]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
- Proxies. In some architectures the endpoint of the TLS
may not be the application endpoint. In these situations,
mechanism can be used to obtain end-to-end authentication
- Upgrade of authentication. In some applications it may not
clear at the time of TLS session negotiation what type
authentication may be required (e.g., anonymous, server
client-server). This mechanism allows the negotiation of
anonymous or server authenticated TLS session which can, at
later time, be upgraded to provide the desired level
authentication
2. Description of
2.1.
The mechanism described in this memo provides either mutual
unilateral entity authentication as defined in ISO/IEC 9798-1 [ISO1]
using an asymmetric (public-key) digital signature mechanism
2.2. Authentication
This SASL mechanism contains two authentication modes
- Unilateral client authentication: The client digitally signs
challenge from the server, thus authenticating itself to
server
- Mutual authentication: The client digitally signs a
from the server and the server digitally signs a challenge
the client. Thus both the client and server authenticate
other
2.3. SASL
This mechanism has two SASL keys corresponding to the two
modes
- "9798-U-<algorithm>" for unilateral client authentication
- "9798-M-<algorithm>" for mutual authentication
Each SASL key may be used with a list of algorithms. A list
supported algorithms is given in Section 4.
Zuccherato & Nystrom Experimental [Page 3]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2.4. Unilateral Client
This section gives a brief description of the steps that
performed for unilateral client authentication. The actual
structures are described fully in Section 3.
a) The server generates a random challenge value R_B and sends
to the client
b) The client generates a random value R_A and creates a
TokenAB. The token contains R_A, the client's certificate
also a digital signature created by the client over both R_
and R_B. Optionally, it also contains an identifier for
server
c) The client sends the token to the server
d) The server verifies the token by
- verifying the client's signature in TokenAB (this
full certificate path processing as described in [RFC2459]),
- verifying that the random number R_B, sent to the client
Step 1, agrees with the random number contained in
signed data of TokenAB,
- verifying that the identifier for the server, if present
matches the server's distinguishing identifier
2.5. Mutual
This section gives a brief description of the steps that
performed for mutual authentication. The actual data structures
described fully in Section 3.
a) The server generates a random challenge value R_B and sends
to the client
b) The client generates a random value R_A and creates a
TokenAB. The token contains R_A, the client's certificate
also a digital signature created by the client over both R_
and R_B. Optionally, it also contains an identifier for
server
c) The client sends the token to the server
d) The server verifies the token by
Zuccherato & Nystrom Experimental [Page 4]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
- verifying the client's signature in TokenAB (this
full certificate path processing as described in [RFC2459]),
- verifying that the random number R_B, sent to the client
Step 1, agrees with the random number contained in
signed data of TokenAB,
- verifying that the identifier for the server, if present
matches the server's distinguishing identifier
e) The server creates a token TokenBA. The token contains a
random value R_C, the server's certificate and a
signature created by the server over R_A, R_B and R_C
Optionally, it also contains an identifier for the client
f) The server sends the token to the client
g) The client verifies the token by
- verifying the server's signature in TokenBA (this
full certificate path processing as described in [RFC2459]),
- verifying that the random number R_B, received by the
in Step 1, agrees with the random number contained in
signed data of TokenBA
- verifying that the random number R_A, sent to the server
Step 2, agrees with the random number contained in
signed data of Token BA
- verifying that the identifier for the client, if present
matches the client's distinguishing identifier
3. Token and Message
Note - Protocol data units (PDUs) SHALL be DER-encoded [X690]
before transmitted
3.1. The "TokenBA1"
TokenBA1 is used in both the unilateral client authentication
mutual authentication modes and is sent by the server to the client
TokenBA1 contains a random value, and, optionally, the servers
and certificate information
Zuccherato & Nystrom Experimental [Page 5]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
TokenBA1 ::= SEQUENCE {
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth
}
3.2. The "TokenAB"
TokenAB is used in the unilateral client authentication and
authentication modes and is sent by the client to the server
TokenAB contains a random number, entity B's name (optionally),
entity certification information, an (optional)
identity, and a signature of a DER-encoded value of type TBSDataAB
The certA field is used to send the client's X.509 certificate (or
URL to it) and a related certificate chain to the server
The authID field is to be used when the identity to be used
access control is different than the identity contained in
certificate of the signer. If this field is not present, then
identity from the client's X.509 certificate shall be used
TokenAB ::= SEQUENCE {
randomA RandomNumber
entityB [0] GeneralNames OPTIONAL
certA [1] CertData
authID [2] GeneralNames OPTIONAL
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be
-- in TokenAB if and only if they are also included in TBSDataAB
-- The entityB field SHOULD be present in TokenAB whenever
-- client believes it knows the identity of the server.--})
TBSDataAB ::= SEQUENCE {
randomA RandomNumber
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
authID [1] GeneralNames
}
3.3. The "TokenBA2"
TokenBA2 is used in the mutual authentication mode and is sent by
server to the client. TokenBA2 contains a random number, entity A'
name (optionally), certification information, and a signature of
DER-encoded value of type TBSDataBA. The certB field is to be
to send the server's X.509 certificate and a related
chain to the client
Zuccherato & Nystrom Experimental [Page 6]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
TokenBA2 ::= SEQUENCE {
randomC RandomNumber
entityA [0] GeneralNames OPTIONAL
certB [1] CertData
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA
-- if and only if it is also included in TBSDataBA. The
-- field SHOULD be present and MUST contain the client's
-- from their X.509 certificate.--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber
randomA RandomNumber
randomC RandomNumber
entityA GeneralNames
}
3.4. The "TrustedAuth"
TrustedAuth ::= CHOICE {
authorityName [0] Name
-- SubjectName from CA
issuerNameHash [1] OCTET STRING
-- SHA-1 hash of Authority's
issuerKeyHash [2] OCTET STRING
-- SHA-1 hash of Authority's public
authorityCertificate [3] Certificate
-- CA
pkcs15KeyHash [4] OCTET
-- PKCS #15 key
}
The TrustedAuth type can be used by a server in its initial
("TokenBA1") to indicate to a client preferred certificates/
key pairs to use in the authentication
A trusted authority is identified by its name, hash of its name,
of its public key, its certificate, or PKCS #15 key hash.
identified by its name, then the authorityName field in
contains the SubjectName of its CA certificate. If it is
by the hash of its name then the issuerNameHash field contains
SHA-1 hash of the DER encoding of SubjectName from its
certificate. If it is identified by the hash of its public key
the issuerKeyHash field contains the SHA-1 hash of the authority'
public key. The hash shall be calculated over the value (
tag and length) of the subject public key field in the issuer'
certificate. If it is identified by its certificate then
authorityCertificate field contains its CA certificate. If it
Zuccherato & Nystrom Experimental [Page 7]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
identified by the PKCS #15 key hash then the pkcs15KeyHash
contains the hash of the CA's public key as defined in PKCS #15
[PKCS15] Section 6.1.4.
3.5. The "CertData"
The certification data is a choice between a set of certificates
a certificate URL
The certificate set alternative is as in [RFC2630], meaning it
intended that the set be sufficient to contain chains from
recognized "root" or "top-level certification authority" to all
the sender certificates with which the set is associated. However
there may be more certificates than necessary, or there may be
than necessary
Note - The precise meaning of a "chain" is outside the scope
this document. Some applications may impose upper limits
the length of a chain; others may enforce
relationships between the subjects and issuers
certificates within a chain
When the certURL type is used to specify the location at which
user's certificate can be found, it MUST be a non-relative URL,
MUST follow the URL syntax and encoding rules specified in [RFC1738].
The URL must include both a scheme (e.g., "http" or "ldap") and
scheme-specific part. The scheme-specific part must include a
qualified domain name or IP address as the host
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate
certURL IA5String
... -- For future
}
3.6. The "RandomNumber"
A random number is simply defined as an octet string, at least 8
bytes long
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
3.7. The "SIGNATURE"
This is similar to the "SIGNED" parameterized type defined
[RFC2459], the difference being that the "SIGNATURE" type does
include the data to be signed
Zuccherato & Nystrom Experimental [Page 8]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier
signature BIT
}(CONSTRAINED BY {-- Must be the result of applying the
-- operation indicated in "algorithm" to the DER-encoded octets
-- a value of type -- ToBeSigned })
3.8. Other
The "GeneralNames" type is defined in [RFC2459].
4. Supported
The following signature algorithms are recognized for use with
mechanism, and identified by a key. Each key would be combined
make two possible SASL mechanisms. For example the DSA-SHA
algorithm would give 9798-U-DSA-SHA1, and 9798-M-DSA-SHA1.
algorithm names are constrained to 13 characters, to keep within
total SASL limit of 20 characters
The following table gives a list of algorithm keys, noting the
identifier and the body that assigned the identifier
Key Object Id
RSA-SHA1-ENC 1.2.840.113549.1.1.5
DSA-SHA1 1.2.840.10040.4.3
ECDSA-SHA1 1.2.840.10045.4.1
Support of the RSA-SHA1-ENC algorithm is RECOMMENDED for use
this mechanism
5.
5.1. IMAP4
The following example shows the use of the ISO/IEC 9798-3
Authentication SASL mechanism with IMAP4 [RFC2060].
The base64 encoding of challenges and responses, as well as the "+ "
preceding the responses are part of the IMAP4 profile, not part
this specification itself (note that the line breaks in the
authenticators are for editorial clarity and are not in
authenticators).
Zuccherato & Nystrom Experimental [Page 9]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
S: * OK IMAP4 server
C: A001 AUTHENTICATE 9798-U-RSA-SHA
S: + MAoECBI4l1h5h0
C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2
ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0
PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG
NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1
buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/
kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user:
6. IANA
By registering the 9798--<algorithm> protocols as
mechanisms, implementers will have a well-defined way of adding
authentication mechanism to their product. Here is the
template for the SASL mechanisms defined in this memo
SASL mechanism names: 9798-U-RSA-SHA1-
9798-M-RSA-SHA1-
9798-U-DSA-SHA
9798-M-DSA-SHA
9798-U-ECDSA-SHA
9798-M-ECDSA-SHA
; For a definition of the
see Section 4 of this memo
Security Considerations: See Section 7 of this
Published specification: This
Person & email address
contact for
information: See Section 9 of this memo
Intended usage:
Author/Change controller: See Section 9 of this memo
7. Security
The mechanisms described in this memo only provides
against passive eavesdropping attacks. They do not provide
privacy or protection from active attacks. In particular, man-in
the-middle attacks aimed at session "hi-jacking" are possible
The random numbers used in this protocol MUST be generated by
cryptographically strong random number generator. If the number
chosen from a small set or is otherwise predictable by a third party
then this mechanism can be attacked
Zuccherato & Nystrom Experimental [Page 10]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
The inclusion of the random number R_A in the signed part of
prevents the server from obtaining the signature of the client
data chosen by the server prior to the start of the
mechanism. This measure may be required, for example, when the
key is used by the client for purposes other than
authentication. However, the inclusion of R_B in TokenBA2,
necessary for security reasons which dictate that the client
check that it is the same as the value sent in the first message,
not offer the same protection to the server, since R_B is known
the client before R_A is chosen. For this reason a third
number, R_C, is included in the TokenBA2 PDU
8.
[FIPS] FIPS 196, "Entity authentication using public
cryptography," Federal Information Processing
Publication 196, U.S. Department of Commerce/N.I.S.T.,
National Technical Information Service, Springfield
Virginia, 1997.
[ISO1] ISO/IEC 9798-1: 1997, Information technology -
techniques - Entity authentication - Part 1: General
[ISO3] ISO/IEC 9798-3: 1997, Information technology -
techniques - Entity authentication - Part 3:
using digital signature techniques
[PKCS15] RSA Laboratories, "The Public-Key Cryptography
- PKCS #15 v1.1: Cryptographic token information
standard", June 6, 2000.
[RFC1738] Berners-Lee, T., Masinter L. and M. McCahill "
Resource Locators (URL)", RFC 1738, December 1994.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2060] Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, December 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede "IMAP/
AUTHorize Extension for Simple Challenge/Response",
2195, September 1997.
Zuccherato & Nystrom Experimental [Page 11]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
[RFC2222] J. Meyers, "Simple Authentication and Security Layer",
RFC 2222, October 1997.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "
X.509 Public Key Infrastructure: X.509 Certificate
CRL Profile", RFC 2459, January 1999.
[RFC2630] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[X509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
Information Technology - Open Systems Interconnection -
The Directory: Authentication Framework
[X690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
Information Technology - ASN.1 Encoding Rules
Specification of Basic Encoding Rules (BER),
Encoding Rules (CER) and Distinguished Encoding
(DER).
9. Authors'
Robert
Entrust
1000 Innovation
Ottawa,
Canada K2K 3E
Phone: +1 613 247 2598
EMail: robert.zuccherato@entrust.
Magnus
RSA
Box 10704
121 29
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.
Zuccherato & Nystrom Experimental [Page 12]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
A. ASN.1
A.1. 1988 ASN.1
SASL-9798-3-1988
DEFINITIONS IMPLICIT TAGS ::=
-- EXPORTS ALL --
Name, AlgorithmIdentifier,
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)};
TokenBA1 ::= SEQUENCE {
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth
}
TokenAB ::= SEQUENCE {
randomA RandomNumber
entityB [0] GeneralNames OPTIONAL
certA [1] CertData
authID [2] GeneralNames OPTIONAL
signature SEQUENCE {
algorithm AlgorithmIdentifier
signature BIT
}
} -- The entityB and authID fields shall be included in
-- if and only if they are also included in TBSDataAB. The
-- field SHOULD be present in TokenAB whenever the
-- believes it knows the identity of the server
-- The signature operation shall be done on
-- DER-encoded value of type TBSDataAB
Zuccherato & Nystrom Experimental [Page 13]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
TBSDataAB ::= SEQUENCE {
randomA RandomNumber
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
authID [1] GeneralNames
}
TokenBA2 ::= SEQUENCE {
randomC RandomNumber
entityA [0] GeneralNames OPTIONAL
certB [1] CertData
signature SEQUENCE {
algorithm AlgorithmIdentifier
signature BIT
}
} -- The entityA field shall be included in TokenBA
-- if and only if it is also included in TBSDataBA. The
-- field SHOULD be present and MUST contain the client's
-- from their X.509 certificate. The signature shall be
-- on a DER-encoded value of type TBSDataBA
TBSDataBA ::= SEQUENCE {
randomB RandomNumber
randomA RandomNumber
randomC RandomNumber
entityA GeneralNames
}
TrustedAuth ::= CHOICE {
authorityName [0] Name
-- SubjectName from CA
issuerNameHash [1] OCTET STRING
-- SHA-1 hash of Authority's
issuerKeyHash [2] OCTET STRING
-- SHA-1 hash of Authority's public
authorityCertificate [3] Certificate
-- CA
pkcs15KeyHash [4] OCTET
-- PKCS #15 key
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate
certURL IA5
}
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
Zuccherato & Nystrom Experimental [Page 14]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
A.2. 1997 ASN.1
SASL-9798-3-1997
DEFINITIONS IMPLICIT TAGS ::=
-- EXPORTS ALL --
AlgorithmIdentifier, Name,
FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-93(3)}
FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-93(4)};
TokenBA1 ::= SEQUENCE {
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth
}
TokenAB ::= SEQUENCE {
randomA RandomNumber
entityB [0] GeneralNames OPTIONAL
certA [1] CertData
authID [2] GeneralNames OPTIONAL
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be
-- in TokenAB if and only if they are also included in TBSDataAB
-- The entityB field SHOULD be present in TokenAB whenever
-- client believes it knows the identity of the server.--})
TBSDataAB ::= SEQUENCE {
randomA RandomNumber
randomB RandomNumber
entityB [0] GeneralNames OPTIONAL
authID [1] GeneralNames
}
Zuccherato & Nystrom Experimental [Page 15]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
TokenBA2 ::= SEQUENCE {
randomC RandomNumber
entityA [0] GeneralNames OPTIONAL
certB [1] CertData
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA
-- if and only if it is also included in TBSDataBA. The
-- field SHOULD be present and MUST contain the client's
-- from their X.509 certificate.--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber
randomA RandomNumber
randomC RandomNumber
entityA GeneralNames
}
TrustedAuth ::= CHOICE {
authorityName [0] Name
-- SubjectName from CA
issuerNameHash [1] OCTET STRING
-- SHA-1 hash of Authority's
issuerKeyHash [2] OCTET STRING
-- SHA-1 hash of Authority's public
authorityCertificate [3] Certificate
-- CA
pkcs15KeyHash [4] OCTET
-- PKCS #15 key
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate
certURL IA5String
... -- For future
}
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier
signature BIT
}(CONSTRAINED BY {-- Must be the result of applying the
-- operation indicated in "algorithm" to the DER-encoded octets
-- a value of type -- ToBeSigned })
Zuccherato & Nystrom Experimental [Page 16]
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
Full Copyright
Copyright (C) The Internet Society (2001). 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
Zuccherato & Nystrom Experimental [Page 17]
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
