As per Relevance of the word mechanism, we have this rfc below:
Network Working Group A.
Request for Comments: 2695 Sun
Category: Informational September 1999
Authentication Mechanisms for ONC
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes two authentication mechanisms created by
Microsystems that are commonly used in conjunction with the
Remote Procedure Call (ONC RPC Version 2) protocol
The DH authentication as defined in Section 2 in this document
to the authentication mechanism with flavor AUTH_DH
implemented in ONC RPC. It uses the underlying Diffie-
algorithm for key exchange. The DH authentication defined in
document is flawed due to the selection of a small prime for the
field (Section 2.5). To avoid the flaw a new DH
mechanism could be defined with a larger prime. However, the new
authentication would not be interoperable with the existing
authentication
As illustrated in [10], a large number of attacks are possible on
RPC system services that use non-secure authentication mechanisms
Other secure authentication mechanisms need to be developed for
RPC. RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor,
secure authentication mechanism that enables RPC protocols to
Generic Security Service Application Program Interface (RFC 2078)
provide security services, integrity and privacy, that
independent of the underlying security mechanisms
Chiu Informational [Page 1]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
Table of
1. Introduction ............................................... 2
2. Diffie-Hellman Authentication .............................. 2
2.1 Naming .................................................... 3
2.2 DH Authentication Verifiers ............................... 3
2.3 Nicknames and Clock Synchronization ....................... 5
2.4 DH Authentication Protocol Specification .................. 5
2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
2.4.2 The Nickname Credential and Verifier (Client) ........... 8
2.4.3 The Nickname Verifier (Server) .......................... 9
2.5 Diffie-Hellman Encryption ................................. 9
3. Kerberos-based Authentication ............................. 10
3.1 Naming ................................................... 11
3.2 Kerberos-based Authentication Protocol Specification ..... 11
3.2.1 The Full Network Name Credential and Verifier (Client) . 12
3.2.2 The Nickname Credential and Verifier (Client) .......... 14
3.2.3 The Nickname Verifier (Server) ......................... 15
3.2.4 Kerberos-specific Authentication Status Values ......... 15
4. Security Considerations ................................... 16
5. REFERENCES ................................................ 16
6. AUTHOR'S ADDRESS .......................................... 17
7. FULL COPYRIGHT STATEMENT ...................................18
1.
The ONC RPC protocol provides the fields necessary for a client
identify itself to a service, and vice-versa, in each call and
message. Security and access control mechanisms can be built on
of this message authentication. Several different
protocols can be supported
This document specifies two authentication protocols created by
Microsystems that are commonly used: Diffie-Hellman (DH
authentication and Kerberos (Version 4) based authentication
As a prerequisite to reading this document, the reader is expected
be familiar with [1] and [2]. This document uses terminology
definitions from [1] and [2].
2. Diffie-Hellman
System authentication (defined in [1]) suffers from some problems
It is very UNIX oriented, and can be easily faked (there is
attempt to provide cryptographically secure authentication).
Chiu Informational [Page 2]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
DH authentication was created to address these problems. However,
has been compromised [9] due to the selection of a small length
the prime in the ONC RPC implementation. While the
provided here will be useful for implementors to
interoperability with existing applications that use
authentication, it is strongly recommended that new applications
more secure authentication, and that existing applications
currently use DH authentication migrate to more robust
mechanisms
2.1
The client is addressed by a simple string of characters instead
by an operating system specific integer. This string of
is known as the "netname" or network name of the client. The
is not allowed to interpret the contents of the client's name in
other way except to identify the client. Thus, netnames should
unique for every client in the Internet
It is up to each operating system's implementation of
authentication to generate netnames for its users that insure
uniqueness when they call upon remote servers. Operating
already know how to distinguish users local to their systems. It
usually a simple matter to extend this mechanism to the network.
example, a UNIX(tm) user at Sun with a user ID of 515 might
assigned the following netname: "unix.515@sun.com". This
contains three items that serve to insure it is unique.
backwards, there is only one naming domain called "sun.com" in
Internet. Within this domain, there is only one UNIX(tm) user
user ID 515. However, there may be another user on another
system, for example VMS, within the same naming domain that,
coincidence, happens to have the same user ID. To insure that
two users can be distinguished we add the operating system name.
one user is "unix.515@sun.com" and the other is "vms.515@sun.com".
The first field is actually a naming method rather than an
system name. It happens that today there is almost a one-to-
correspondence between naming methods and operating systems. If
world could agree on a naming standard, the first field could be
name of that standard, instead of an operating system name
2.2 DH Authentication
Unlike System authentication, DH authentication does have a
so the server can validate the client's credential (and vice-versa).
The contents of this verifier are primarily an encrypted timestamp
The server can decrypt this timestamp, and if it is within
accepted range relative to the current time, then the client
have encrypted it correctly. The only way the client could
Chiu Informational [Page 3]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
it correctly is to know the "conversation key" of the RPC session
and if the client knows the conversation key, then it must be
real client
The conversation key is a DES [5] key which the client generates
passes to the server in the first RPC call of a session.
conversation key is encrypted using a public key scheme in this
transaction. The particular public key scheme used in
authentication is Diffie-Hellman [3] with 192-bit keys. The
of this encryption method are described later
The client and the server need the same notion of the current time
order for all of this to work, perhaps by using the Network
Protocol [4]. If network time synchronization cannot be guaranteed
then the client can determine the server's time before beginning
conversation using a time request protocol
The way a server determines if a client timestamp is valid
somewhat complicated. For any other transaction but the first,
server just checks for two things
(1) the timestamp is greater than the one previously seen from
same client. (2) the timestamp has not expired
A timestamp is expired if the server's time is later than the sum
the client's timestamp plus what is known as the client's "ttl
(standing for "time-to-live" - you can think of this as the
for the client's credential). The "ttl" is a number the
passes (encrypted) to the server in its first transaction
In the first transaction, the server checks only that the
has not expired. Also, as an added check, the client sends
encrypted item in the first transaction known as the "ttl verifier
which must be equal to the time-to-live minus 1, or the server
reject the credential. If either check fails, the server rejects
credential with an authentication status of AUTH_BADCRED, however
the timestamp is earlier than the previous one seen, the
returns an authentication status of AUTH_REJECTEDCRED
The client too must check the verifier returned from the server to
sure it is legitimate. The server sends back to the client
timestamp it received from the client, minus one second,
with the conversation key. If the client gets anything
than this, it will reject it, returning an AUTH_
authentication status to the user
Chiu Informational [Page 4]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
2.3 Nicknames and Clock
After the first transaction, the server's DH authentication
returns in its verifier to the client an integer "nickname" which
client may use in its further transactions instead of passing
netname. The nickname could be an index into a table on the
which stores for each client its netname, decrypted conversation
and ttl
Though they originally were synchronized, the client's and server'
clocks can get out of synchronization again. When this happens
server returns to the client an authentication status
AUTH_REJECTEDVERF at which point the client should attempt
resynchronize
A client may also get an AUTH_BADCRED error when using a
that was previously valid. The reason is that the server's
table is a limited size, and it may flush entries whenever it wants
A client should resend its original full name credential in this
and the server will give it a new nickname. If a server crashes,
entire nickname table gets flushed, and all clients will have
resend their original credentials
2.4 DH Authentication Protocol
There are two kinds of credentials: one in which the client uses
full network name, and one in which it uses its "nickname" (just
unsigned integer) given to it by the server. The client must use
fullname in its first transaction with the server, in which
server will return to the client its nickname. The client may
its nickname in all further transactions with the server. There is
requirement to use the nickname, but it is wise to use it
performance reasons
The following definitions are used for describing the protocol
enum authdh_namekind {
ADN_FULLNAME = 0,
ADN_NICKNAME = 1
};
typedef opaque des_block[8]; /* 64-bit block of encrypted data */
const MAXNETNAMELEN = 255; /* maximum length of a netname */
The flavor used for all DH authentication credentials and
is "AUTH_DH", with the numerical value 3. The opaque
constituting the client credential encodes the following structure
Chiu Informational [Page 5]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
union authdh_cred switch (authdh_namekind namekind) {
case ADN_FULLNAME
authdh_fullname fullname
case ADN_NICKNAME
authdh_nickname nickname
};
The opaque data constituting a verifier that accompanies a
credential encodes the following structure
union authdh_verf switch (authdh_namekind namekind) {
case ADN_FULLNAME
authdh_fullname_verf fullname_verf
case ADN_NICKNAME
authdh_nickname_verf nickname_verf
};
The opaque data constituting a verifier returned by a server
response to a client request encodes the following structure
struct authdh_server_verf
These structures are described in detail below
2.4.1 The Full Network Name Credential and Verifier (Client
First, the client creates a conversation key for the session. Next
the client fills out the following structure
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format
The timestamp encodes the time since midnight, January 1, 1970.
128 bits of data are then encrypted in the DES CBC mode, using
conversation key for the session, and with an initialization
of 0. This yields
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
Chiu Informational [Page 6]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
where T1, T2, W1, and W2 are all 32-bit quantities, and have
correspondence to the original quantities occupying their positions
but are now interdependent on each other for proper decryption.
64 bit sequence comprising T1 and T2 is denoted by T
The full network name credential is represented as follows using
notation
struct authdh_fullname {
string name; /* netname of client */
des_block key; /* encrypted conversation key */
opaque w1[4]; /* W1 */
};
The conversation key is encrypted using the "common key" using
ECB mode. The common key is a DES key that is derived from
Diffie-Hellman public and private keys, and is described later
The verifier is represented as follows
struct authdh_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the encrypted quantities (key, w1, w2, timestamp)
the above structures are opaque
The fullname credential and its associated verifier together
the network name of the client, an encrypted conversation key,
ttl, a timestamp, and a ttl verifier that is one less than the ttl
The ttl is actually the lifetime for the credential. The server
accept the credential if the current server time is "within" the
indicated in the timestamp plus the ttl. Otherwise, the
rejects the credential with an authentication status of AUTH_BADCRED
One way to insure that requests are not replayed would be for
server to insist that timestamps are greater than the previous
seen, unless it is the first transaction. If the timestamp
earlier than the previous one seen, the server returns
authentication status of AUTH_REJECTEDCRED
The server returns a authdh_server_verf structure, which is
in detail below. This structure contains a "nickname", which may
used for subsequent requests in the current conversation
Chiu Informational [Page 7]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
2.4.2 The Nickname Credential and Verifier (Client
In transactions following the first, the client may use the
nickname credential and verifier for efficiency. First, the
fills out the following structure
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format
These 64 bits of data are then encrypted in the DES ECB mode,
the conversation key for the session. This yields
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation
struct authdh_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation
struct authdh_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for
reasons. An authentication status of AUTH_BADCRED indicates that
nickname is no longer valid. The client should retry the
using the fullname credential. AUTH_REJECTEDVERF indicates that
nickname verifier is not valid. Again, the client should retry
request using the fullname credential
Chiu Informational [Page 8]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
2.4.3 The Nickname Verifier (Server
The server never returns a credential. It returns only one kind
verifier, i.e., the nickname verifier. This has the following
representation
struct authdh_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as
client nickname credential. The server sets the timestamp value
the value the client sent minus one second and encrypts it in DES
mode using the conversation key. The server also sends the client
nickname to be used in future transactions (unencrypted).
2.5 Diffie-Hellman
In this scheme, there are two constants "BASE" and "MODULUS" [3].
The particular values Sun has chosen for these for the
authentication protocol are
const BASE = 3;
const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
Note that the modulus is represented above as a hexadecimal string
The way this scheme works is best explained by an example.
there are two people "A" and "B" who want to send encrypted
to each other. So, A and B both generate "secret" keys at
which they do not reveal to anyone. Let these keys be represented
SK(A) and SK(B). They also publish in a public directory
"public" keys. These keys are computed as follows
PK(A) = ( BASE ** SK(A) ) mod
PK(B) = ( BASE ** SK(B) ) mod
The "**" notation is used here to represent exponentiation. Now,
A and B can arrive at the "common" key between them, represented
as CK(A, B), without revealing their secret keys
Chiu Informational [Page 9]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
A computes
CK(A, B) = ( PK(B) ** SK(A)) mod
while B computes
CK(A, B) = ( PK(A) ** SK(B)) mod
These two can be shown to be equivalent
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod
We drop the "mod MODULUS" parts and assume modulo arithmetic to
things
PK(B) ** SK(A) = PK(A) ** SK(B
Then, replace PK(B) by what B computed earlier and likewise for PK(A).
(BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B
which leads to
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
This common key CK(A, B) is not used to encrypt the timestamps
in the protocol. Rather, it is used only to encrypt a
key which is then used to encrypt the timestamps. The reason
doing this is to use the common key as little as possible, for
that it could be broken. Breaking the conversation key is a far
damaging, since conversations are relatively short-lived
The conversation key is encrypted using 56-bit DES keys, yet
common key is 192 bits. To reduce the number of bits, 56 bits
selected from the common key as follows. The middle-most 8-bytes
selected from the common key, and then parity is added to the
order bit of each byte, producing a 56-bit key with 8 bits of parity
Only 48 bits of the 8-byte conversation key are used in the
Authentication scheme. The least and most significant bits of
byte of the conversation key are unused
3. Kerberos-based
Conceptually, Kerberos-based authentication is very similar to
authentication. The major difference is, Kerberos-
authentication takes advantage of the fact that Kerberos tickets
Chiu Informational [Page 10]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
encoded in them the client name and the conversation key. This
does not describe Kerberos name syntax, protocols and ticket formats
The reader is referred to [6], [7], and [8].
3.1
A Kerberos name contains three parts. The first is the
name, which is usually a user's or service's name. The second is
instance, which in the case of a user is usually NULL. Some
may have privileged instances, however, such as root or admin.
the case of a service, the instance is the name of the machine
which it runs; that is, there can be an NFS service running on
machine ABC, which is different from the NFS service running on
machine XYZ. The third part of a Kerberos name is the realm.
realm corresponds to the Kerberos service providing
for the principal. When writing a Kerberos name, the principal
is separated from the instance (if not NULL) by a period, and
realm (if not the local realm) follows, preceded by an "@" sign.
following are examples of valid Kerberos names
jis.
srz@lcs.mit.
treese.root@athena.mit.
3.2 Kerberos-based Authentication Protocol
The Kerberos-based authentication protocol described is based
Kerberos version 4.
There are two kinds of credentials: one in which the client uses
full network name, and one in which it uses its "nickname" (just
unsigned integer) given to it by the server. The client must use
fullname in its first transaction with the server, in which
server will return to the client its nickname. The client may
its nickname in all further transactions with the server. There is
requirement to use the nickname, but it is wise to use it
performance reasons
The following definitions are used for describing the protocol
enum authkerb4_namekind {
AKN_FULLNAME = 0,
AKN_NICKNAME = 1
};
Chiu Informational [Page 11]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
The flavor used for all Kerberos-based authentication credentials
verifiers is "AUTH_KERB4", with numerical value 4. The opaque
constituting the client credential encodes the following structure
union authkerb4_cred switch (authkerb4_namekind namekind) {
case AKN_FULLNAME
authkerb4_fullname fullname
case AKN_NICKNAME
authkerb4_nickname nickname
};
The opaque data constituting a verifier that accompanies a
credential encodes the following structure
union authkerb4_verf switch (authkerb4_namekind namekind) {
case AKN_FULLNAME
authkerb4_fullname_verf fullname_verf
case AKN_NICKNAME
authkerb4_nickname_verf nickname_verf
};
The opaque data constituting a verifier returned by a server
response to a client request encodes the following structure
struct authkerb4_server_verf
These structures are described in detail below
3.2.1 The Full Network Name Credential and Verifier (Client
First, the client must obtain a Kerberos ticket from the
Server. The ticket contains a Kerberos session key, which
become the conversation key. Next, the client fills out
following structure
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format
The timestamp encodes the time since midnight, January 1, 1970.
"ttl" is identical in meaning to the corresponding field in Diffie
Hellman authentication: the credential "time-to-live" for
Chiu Informational [Page 12]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
conversation being initiated. These 128 bits of data are
encrypted in the DES CBC mode, using the conversation key, and
an initialization vector of 0. This yields
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have
correspondence to the original quantities occupying their positions
but are now interdependent on each other for proper decryption.
64 bit sequence comprising T1 and T2 is denoted by T
The full network name credential is represented as follows using
notation
struct authkerb4_fullname {
opaque ticket<>; /* kerberos ticket for the server */
opaque w1[4]; /* W1 */
};
The verifier is represented as follows
struct authkerb4_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the client-encrypted quantities (w1, w2, timestamp
in the above structures are opaque. The client does not encrypt
Kerberos ticket for the server
The fullname credential and its associated verifier together
the Kerberos ticket (which contains the client name and
conversation key), the ttl, a timestamp, and a ttl verifier that
one less than the ttl. The ttl is actually the lifetime for
credential. The server will accept the credential if the
server time is "within" the time indicated in the timestamp plus
ttl. Otherwise, the server rejects the credential with
authentication status of AUTH_BADCRED. One way to insure
requests are not replayed would be for the server to insist
timestamps are greater than the previous one seen, unless it is
first transaction. If the timestamp is earlier than the previous
seen, the server returns an authentication status
AUTH_REJECTEDCRED
Chiu Informational [Page 13]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
The server returns a authkerb4_server_verf structure, which
described in detail below. This structure contains a "nickname",
which may be used for subsequent requests in the current session
3.2.2 The Nickname Credential and Verifier (Client
In transactions following the first, the client may use the
nickname credential and verifier for efficiency. First, the
fills out the following structure
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format
These 64 bits of data are then encrypted in the DES ECB mode,
the conversation key for the session. This yields
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation
struct authkerb4_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation
struct authkerb4_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for
reasons. An authentication status of AUTH_BADCRED indicates that
nickname is no longer valid. The client should retry the
using the fullname credential. AUTH_REJECTEDVERF indicates that
nickname verifier is not valid. Again, the client should retry
Chiu Informational [Page 14]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
request using the fullname credential. AUTH_TIMEEXPIRE
that the session's Kerberos ticket has expired. The client
initiate a new session by obtaining a new Kerberos ticket
3.2.3 The Nickname Verifier (Server
The server never returns a credential. It returns only one kind
verifier, i.e., the nickname verifier. This has the following
representation
struct authkerb4_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as
client nickname credential. The server sets the timestamp value
the value the client sent minus one second and encrypts it in DES
mode using the conversation key. The server also sends the client
nickname to be used in future transactions (unencrypted).
3.2.4 Kerberos-specific Authentication Status
The server may return to the client one of the following errors
the authentication status field
enum auth_stat {
...
/*
* kerberos
*/
AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error
than the following */
AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */
AUTH_TKT_FILE = 10, /* The server was unable to find
ticket file. The client
create a new session by obtaining
new ticket */
AUTH_DECODE = 11, /* The server is unable to decode
authenticator of the client's ticket */
AUTH_NET_ADDR = 12 /* The network address of the
does not match the address
in the ticket */
/* and more to be defined */
};
Chiu Informational [Page 15]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
4. Security
The DH authentication mechanism and the Kerberos V4
mechanism are described in this document only for
purposes
In addition to the weakness pointed out earlier in this document (
WARNING on page 1), the two security mechanisms described herein
the support for integrity and privacy data protection. It is
recommended that new applications use more secure mechanisms,
that existing applications migrate to more robust mechanisms
The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203,
applications built on top of RPC to access security mechanisms
adhere to the GSS-API specification. It provides a GSS-API
security framework that allows for strong security mechanisms.
1964 describes the Kerberos Version 5 GSS-API security
which provides integrity and privacy, in addition to authentication
RFC 2623 [14] describes how Kerberos V5 is pluggued into RPCSEC_GSS
and how the Version 2 and Version 3 of the NFS protocol use
V5 via RPCSEC_GSS. The RPCSEC_GSS/GSS-API/Kerberos-V5 stack
a robust security mechanism for applications that require
protection
5.
[1] Srinivasan, R., "Remote Procedure Call Protocol Version 2",
1831, August 1995.
[2] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
[3] Diffie & Hellman, "New Directions in Cryptography",
Transactions on Information Theory IT-22, November 1976.
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305,
1992.
[5] National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standards Publication 46,
1977.
[6] Miller, S., Neuman, C., Schiller, J. and J. Saltzer, "
E.2.1: Kerberos Authentication and Authorization System",
December 1987.
Chiu Informational [Page 16]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
[7] Steiner, J., Neuman, C. and J. Schiller, "Kerberos:
Authentication Service for Open Network Systems", pp. 191-202
Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[8] Kohl, J. and C. Neuman, "The Kerberos Network
Service (V5)", RFC 1510, September 1993.
[9] La Macchia, B.A., and Odlyzko, A.M., "Computation of
Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes
Cryptography", Kluwer Academic Publishers, 1991.
[10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and
Security," Addison-Wesley, 1995.
[11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996.
[12] Linn, J., "Generic Security Service Application
Interface, Version 2", RFC 2078, January 1997.
[13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS
Specification", RFC 2203, September 1997.
[14] Eisler, M., "NFS Version 2 and Version 3 Security Issues and
NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623,
June 1999.
6. AUTHOR'S
Alex
Sun Microsystems, Inc
901 San Antonio
Palo Alto, CA 94303
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.
Chiu Informational [Page 17]
RFC 2695 Authentication Mechanisms for ONC RPC September 1999
7. Full Copyright
Copyright (C) The Internet Society (1999). 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
Chiu Informational [Page 18]
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
