No User Authentication

The No User Authentication UAM requires no authentication information. When the FPLogin and FPLoginExt commands use the No User Authentication UAM, there is no UserAuthInfo parameter. The corresponding case-insensitive UAM protocol name for the No User Authentication UAM is No User Authent. The No User Authentication UAM is used when a user logs on as the Guest user.

In order to implement the directory access controls described later in this section, the server must assign a User ID and a Group ID to the user for the session.

User ID numbers and Group ID numbers are assigned from the same pool of numbers. In addition, starting with AFP 2.1, AFP servers must assign zero to users who log in as the Guest user and 1 to the Administrator/Owner.

In this UAM, the server assigns to the user “Everyone” access privileges for every directory in every server volume. “Everyone” access privileges are described in the section Directory Access Controls.

Cleartext Password

The Cleartext Password UAM transmits the user name and password to the server as cleartext (that is, not encoded). The protocol name for the Cleartext Password UAM is Cleartxt Passwrd.

For the FPLogin command, the UserAuthInfo parameter consists of a user name (which is a string of up to 255 Macintosh Roman characters) followed by the user’s password (up to 8 bytes). For the FPLoginExt command, the UserAuthInfo parameter consists of a user name (which is a string of up to 255 Unicode characters) followed by the user’s password (up to 8 bytes). To ensure that the user’s password is aligned on an even byte boundary in the packet, the AFP client may have to insert a null byte (0x00) between the user name and the password. If the user provides a password that is shorter than 8 bytes, it must be padded at the end with null bytes to make the password eight bytes long. The permissible set of characters in passwords consists of all 8-bit ASCII characters.

User name comparison is case-insensitive, but password comparison is case-sensitive for this UAM. If there is a user of the specified name whose password matches the password supplied by the caller of FPLogin or FPLoginExt, the user has been authenticated and the login succeeds. If the passwords do not match, a kFPUserNotAuth result code is returned.

The Cleartext Password UAM should be used by AFP clients only if the intervening network is secure against eavesdropping. Otherwise, the password information can be read from FPLogin or FPLoginExt command packets by anyone listening on the network.

Figure 3-1 shows the request block for calling FPChangePassword when using the Cleartext Password UAM.

Random Number Exchange

In environments in which the network is not secure against eavesdropping, Random Number Exchange is a more secure user authentication method. The protocol name for this UAM is Randnum Exchange. With Random Number Exchange, the user’s password is never sent over the network and cannot be picked up by eavesdropping. Deriving the password from information sent over the network is as difficult as breaking a DES-encrypted password.

With the Random Number Exchange UAM, only the user name is sent in the UserAuthInfo parameter of the FPLogin or FPLoginExt command. If the user name is valid, the server generates an eight-byte random number and sends it back to the AFP client, along with an ID number and a kFPAuthContinue result code. The kFPAuthContinue result code indicates that all is well at this point, but the user has not yet been authenticated. The AFP client then encrypts the random number with the user’s password and sends the result to the server in the UserAuthInfo parameter of the FPLoginCont command along with the ID number returned earlier by the server in the reply block from the FPLogin or FPLoginExt command. The server uses the ID number to associate an earlier FPLogin or FPLoginExt command with this call to FPLoginCont. The server looks up the password for that user and uses it as a key to encrypt the same random number. If the two encrypted numbers match, the user has been authenticated and the login succeeds. Otherwise, the server returns a kFPUserNotAuth result code.

The following steps explain the Random Number Exchange UAM in greater detail:

1. The AFP client sends the FPLogin or FPLoginExt command block with the UAM string and the UserAuthInfo parameter containing the user name string. For FPLogin, the user name can be up to 255 Macintosh Roman characters long; for FPLoginExt, the user name can be up to 255 Unicode characters long.

2. Upon receiving this command block, the server examines its user database to determine whether the user name is valid. User name comparison is case-insensitive and diacritical-sensitive.

3. If the server does not find the user name in the user database, it sends an error code to the AFP client indicating that the user name is not valid and denies the login request. If the server finds the name in the user database, it generates an eight-byte random number and sends it to the AFP client, along with an ID number and an kFPAuthContinue result code. The kFPAuthContinue result code indicates that all is well at this point, but the user is not yet authenticated.

4. Both the AFP client and the server use the National Institute of Standards and Technology Data Encryption Standard (NIST DES) algorithm to encrypt the random number. The user’s case-sensitive password is applied as the encryption key to generate an eight-byte value. The server applies the same algorithm to the password it finds associated with the user name in its database.

5. The AFP client sends the encrypted value to the server in the UserAuthInfo parameter of the FPLoginCont command, along with the ID number it received from the server. The server uses the ID number to associate a previous FPLogin or FPLoginExt command with its corresponding FPLoginCont command.

6. The server compares the AFP client’s encrypted value with the encrypted value obtained using the password from its user database. If the two encrypted values match, the authentication process is complete and the login succeeds. The server returns a result code of kFPNoErr to the AFP client. If the two encrypted values do not match, the server returns the kFPUserNotAuth result code.

Figure 3-2 shows the request block for calling FPChangePassword when using the Random Number Exchange UAM.

Two-Way Random Number Exchange

With the Two-Way Random Number Exchange UAM, the user is authenticated to the server and the server is authenticated to the user, which guards against spoofing (that is, using a fake server to get passwords or data). This method uses the same steps as the Random Number Exchange UAM with three additional steps. The corresponding UAM string is 2-Way Randnum.

Like the Random Number Exchange UAM, the Two-Way Random Number Exchange UAM starts when the client sends the FPLogin or FPLoginExt request to the server that includes the user’s user name. If the server finds the user name in the user name database, the server returns an ID number, an eight-byte random number, and a result code of kFPAuthContinue. The client then encodes the random number with the user’s password and sends the encoded number and the ID number to the server in an FPLoginCont request. If the encoded password matches the server’s copy of the random number encoded by the server’s copy of the password, the client is authenticated and kFPNoErr is returned.

The additional steps of the Two-Way Random Number Exchange are

1. The client sends to the server an FPLoginCont request that includes a second eight-byte random number.

2. The server encodes the second eight-byte random number with it’s copy of the user’s password from the user database and returns the encoded random number in the FPLoginCont reply block.

3. The client encodes the random number with the user’s password and compares it with the encoded random number from the server. If they match, the server is also authenticated.

Figure 3-3 shows the request and reply block formats for the FPLoginCont command when the Two-Way Random Number Exchange UAM is used.

The Two-Way Random Number Exchange UAM is not available for use with the FPChangePassword command. Instead, the Random Number Exchange UAM should be used to change a password. A user who has already logged in using the Two-Way Random Number Exchange UAM and who is changing his or her password has already authenticated the server, so there is no need to authenticate the server again by using the Two-Way Random Number Exchange UAM.

Diffie-Hellman Key Exchange

Diffie-Hellman Key Exchange (DHX) is an implementation of the Diffie-Hellman Key Agreement Protocol using the SSLeay/OpenSSL implementation of CAST 128 in CBC mode. The UAM protocol name for DHX is ‘DHCAST128’.

DHX is strong against packet sniffing attacks but vulnerable to active attacks such “Man in the Middle.” There is no way for the client to verify that the server knows the password, so the server could easily be spoofed. There is some weakness in using fixed initialization vectors, p and g. DHX is useful when the server requires passwords in cleartext.

With DHX, the client and the server each generate a random number, Ra and Rb respectively, which serve as “private keys” for the session. The client and server use modulus exponentiation to derive “public keys”, Ma and Mb, from the private keys and exchange them. The client combines Ra and Mb, and the server combines Ma with Rb to generate identical session keys, K.

After the key exchange is complete, a key verification phase follows. Each side generates a random number (nonce), encrypts it with the session key, and sends it to the other side. Each side takes the other’s verifier, decrypts to get the nonce, modifies the nonce in a way that is known to both parties, encrypts it with the session key, and sends it back. The originator verifies that the nonce was modified as expected. Incrementing the nonce is a simple and effective way of modifying the verifier.

Table 3-1 lists the values used to calculate the content of messages exchanged between the client and server when the UAM is DHX.

For DHX, the constants p and g are defined as follows (MSB first):

UInt8 p = { 0xBA, 0x28, 0x73, 0xDF, 0xB0, 0x60, 0x57, 0xD4, 0x3F,  0x20, 0x24, 0x74,  0x4C, 0xEE, 0xE7, 0x5B  };

UInt8 g = { 0x07 };

For DHX, the client-to-server (C2SIV) and server-to-client S2CIV) initialization vectors are defined as follows:

UInt8 C2SIV[] = { 0x4c, 0x57, 0x61, 0x6c, 0x6c, 0x61, 0x63, 0x65  };

Uint8 S2CIV[] = { 0x43, 0x4a, 0x61, 0x6c, 0x62, 0x65, 0x72, 0x74  };

Logging in Using DHX

The login sequence when using the DHX UAM consists of an exchange of the four messages shown in Table 3-2. In Table 3-2, the pipe symbol (|) is used to separate the elements that make up the message.

Table 3-2  Login sequence using DHX

Message	Sender/Receiver	Content
1	Client to server	| FPLogin (2 bytes) | AFP Vers | ‘DHCAST128’ | username (padded) | Ma |
2	Server to client	| ID | Mb | (nonce, ServerSig, S2CIV)K | and a result code
3	Client to server	| FPLoginCont (2 bytes) | ID | (nonce + 1, password, C2SIV)K |
4	Server to client	A result code of kFPNoErr if authentication was successful

In response to Message 1, the server may return the following result codes (but it may delay sending some of these result codes until Message 4):

• kFPBadUAM — the server doesn’t support the DHX UAM.

• kFPBadVersNum — the server doesn't support the requested AFP version.

• kFPParamErr — the user name is not valid.

• kFPMiscErr — the session is already authenticated.

• kFPServerGoingDown — the server is shutting down.

• kFPUserAlreadyLoggedOnErr — the server allows only one active session per user.

• kFPAuthContinue — the server is prepared to continue to login process.

The server may delay sending some of the above result codes until the fourth message or may report a kFPUserNotAuth result as kFPParamErr to limit the amount of information disclosed to the client.

In response to Message 3, the server may return any of the following result codes:

• kFPNoErr — authentication was successful; the server decrypted the nonce/password and verified that the nonce was incremented properly and the password sent by the client matches the password on the server.

• kFPUserNotAuth — the password is incorrect.

• kFPParamErr — authentication failed and the server prefers not to indicate whether the user name or the password is invalid.

• kFPPwdExpiredErr — the user’s password has expired.

• kFPPwdNeedsChangeErr — the user’s password needs to be changed.

Figure 3-4 shows the request and reply blocks for FPLogin when using the DHX UAM.

Changing Passwords Using DHX

There is no equivalent to FPLoginCont when changing a password, so the client has to send the FPChangePassword command at least twice and use the ID to keep track of the state of the password-changing process. The ID first appears in Message 1 and is set to 2 bytes of 0x00. The server sends a non-zero value for ID in Message 2, and the client must copy it from Message 2 into Message 3. The key used to encrypt the old and new passwords is created in the same way as the key when logging in. The values of p and g are the same values that are used when logging in.

When using the DHX UAM, the password changing sequence consists of an exchange of at least four messages shown in Table 3-3. In Table 3-3, the pipe symbol (|) is used to separate the elements that make up the message.

Table 3-3  Password-changing sequence using DHX

Message	Sender/Receiver	Content
1	Client to server	| FPChangePassword (2 bytes) | ‘DHCAST128’ | Username (padded) | ID (0x00 0x00) | Ma |
2	Server to client	| ID | Mb | (nonce, ServerSig, S2CIV)K | and a result code
3	Client to server	| FPChangePassword (2 bytes) | ‘DHCAST128’ | Username (padded) | ID | (nonce + 1, newPassword, oldPassword, C2SIV)K |
4	Server to client	A result code of kFPNoErr if the password was changed

In response to Message 1, the server may return any of the following result codes (or may wait until it receives the second FPChangePassword command to return the first three result codes):

• kFPBadUAM —the server doesn’t support DHX for changing passwords.

• kFPParamErr — the user name is not valid.

• kFPServerGoingDown — the server is shutting down.

• kFPAuthContinue — the server is prepared to continue the password-changing process.

In response to Message 3, the server may return any of the following result codes:

• kFPNoErr — the password was changed.

• kFPUserNotAuth — the old password is incorrect.

• kFPParamErr — to limit the amount of information released to the client.

• kFPPwdPolicyErr — the new password does not conform to the server’s password policy.

• kFPPwdSameErr — the new password is the same as the old password.

• kFPPwdTooShortErr — the new password is too short.

Figure 3-5 shows the request and reply blocks for calling FPChangePassword with the DHX UAM.

Diffie-Hellman Key Exchange 2

Diffie-Hellman Key Exchange 2 (DHX2) is an implementation of the Diffie-Hellman Key Agreement Protocol using the SSLeay/OpenSSL implementation of CAST 128 in CBC mode. The UAM protocol name for DHX2 is ‘DHX2’.

DHX2 differs from DHX in that DHX2 uses variable-sized prime (p) and generator (g) values, which allows servers to choose an appropriate level of security. The minimum size of the prime is increased to 512 bits to improve resistance to numerical methods of attack. In addition, unlike DHX, DHX2 does not use the server signature(ServerSig) in Message 2.

DHX2 is strong against packet sniffing attacks but vulnerable to active attacks such “Man in the Middle.” There is no way for the client to verify that the server knows the password, so the server could easily be spoofed. There is some weakness in using fixed initialization vectors, p and g, which is alleviated by putting the random nonces first in the encrypted portions of the messages. DHX2 is useful when the server requires passwords in cleartext.

As with DHX, in DHX2 the client and server each generate a random number, Ra and Rb respectively, which serve as “private keys” for the session. The client and server use modulus exponentiation to derive “public keys”, Ma and Mb, from the private keys and exchange them. The client combines Ra and Mb, and the server combines Ma with Rb to generate identical session keys, K.

After the key exchange is complete, a key verification phase follows. Each side generates a random number (nonce), encrypts it with the session key, and sends it to the other side. Each side takes the other’s verifier, decrypts to get the nonce, modifies the nonce in a way that is known to both parties, encrypts it with the session key, and sends it back. The originator verifies that the nonce was modified as expected. Incrementing the nonce is a simple and effective way of modifying the verifier.

Table 3-4 lists the values used to calculate the content of messages exchanged between the client and server when the UAM is DHX2.

For DHX2, the client-to-server (C2SIV) and server-to-client (S2CIV) initialization vectors are defined as follows:

UInt8 C2SIV[] = { 0x4c, 0x57, 0x61, 0x6c, 0x6c, 0x61, 0x63, 0x65  };

Uint8 S2CIV[] = { 0x43, 0x4a, 0x61, 0x6c, 0x62, 0x65, 0x72, 0x74  };

Kerberos

The AFP client learns whether a server supports the Kerberos UAM by examining the kSupportsDirServices bit in the Flags parameter returned by the FPGetSrvrInfo command. If that bit is set, a server that supports Kerberos UAM places its principal name in the DirectoryNames parameter returned by FPGetSrvrInfo.

The AFP client uses the principal name to determine if the server supports Kerberos v4 or v5.

Then the client tries to get a service ticket from the server. If it cannot get a ticket, the client must use some other authentication method. If the client gets a service ticket, it can call FPLoginExt, providing the following values in the request block:

• two-byte Flags parameter

• AFP Version string

• UAM string (Client Krb v2)

• kFPUTF8Name (defined as 3)

• length of the user name that follows

• UTF-8–encoded user name

• kFPUTF8Name (defined as 3)

• length of the realm in that follows

• UTF-8–encoded realm

The server replies with a result code of kFPAuthContinue. The reply block contains a two-byte ID value.

If the client is using Kerberos v4, it calls FPLoginCont, providing the following values in the request block:

• UTF-8–encoded user name

• pad byte if one is necessary to force user name to end on an even boundary

• length of the ticket that follows

• ticket, created by KClientGetTicketForService()

The user is authenticated if the server returns a result code of kFPNoErr and a reply block consisting of a two-byte length parameter and an authenticator.

If the client is using Kerberos v5, it calls FPLoginCont, providing the following values in the request block:

• ID returned by FPLoginExt

• UTF-8–encoded user name

• pad byte if one is necessary to force user name to end on an even boundary

• length of the ticket that follows

• ticket, created by gss_init_sec_context with GSS_C_MUTUAL_FLAG and GSS_C_REPLAY_FLAG set and no channel bindings

The user is authenticated if the server returns a result code of kFPNoErr and a reply block consisting of a two-byte length parameter and an authenticator.

After the client receives the FPLoginCont reply packet, the client sends an FPGetSessionToken command with a type of kGetKerberosSessionKey (8) in order to get a random session key from the server. This session key is encrypted on the server using gss_wrap() and is decrypted on the client using gss_unwrap(). Note that the client may call FPGetSessionToken later on in order to get a disconnect token.

Figure 3-6 shows the request and reply blocks for FPLoginExt and FPLoginCont when using the Kerberos UAM.

Reconnect

Unlike the other UAMs described in this section, which are used to log in to an AFP server, the Reconnect UAM is used only to reconnect to a server. The Reconnect UAM can be used when the original connection was made using a UAM that provides a session key, such as DHX, DHX2, and Kerberos. The UAM protocol name for the Reconnect UAM is ‘Recon1’.

The goals of the Reconnect UAM are:

• Store in a token returned by the FPGetSessionToken command all of the information required to reconnect, even if the server has been rebooted.

• Use only a secure hash function and a symmetric encryption algorithm.

• Provide mutual authentication to prove that the server to which the client is reconnecting is the same server that was originally authenticated.

• Ensure that a compromised session key or seed value will not compromise the long term server key.

Table 3-7 lists the variables used to calculate values for the Reconnect UAM.

For the reconnect UAM, the client-to-server (C2SIV) and server-to-client S2CIV) initialization vectors are defined as follows:

UInt8 C2SIV[] = { 0x57, 0x4f, 0x4d, 0x44, 0x4d, 0x4f, 0x41, 0x42 };

Uint8 S2CIV[] = { 0x57, 0x4f, 0x4d, 0x44, 0x4d, 0x4f, 0x41, 0x42 };

Table 3-8 describes common methods of attack and the ways in which the Reconnect UAM is protected from these attacks.

id = (t1, cid)k1

cred = (s, m, exp, t3, user, domain)ks

(sessionInfo, s, m, exp, cred)k1

id = (t1, cred)k1

k2 = (cred, s)H

cred' = (s', m', exp', t3', user, domain)ks

(sessionInfo, s', m', exp', cred')k2

Using the Credential to Reconnect

If the connection to the server goes down for any reason, the client has the current credential (cred), the Lamports hash seed (s), and the maximum number of times to run the hash (m). The server knows the long-term server key (ks).

1. The client logs back in using the FPLoginExt command, specifying Recon1ReconnectLogin as the UAM, and sending the following information to the server:

   (sig, (s)H(n), n, t2, (clientNonce)k, cred)

   Where sig is

   ((s)H(n), n, t2, (clientNonce)k)HMAC(s)

   and k is

   (s)H(n-1)

2. The server uses its long term session key (ks) to decrypt cred. If decryption fails, the server fails the login attempt.

3. If the decryption succeeds, the server retrieves s, m, exp, t3, user, and domain from the credential.

4. The server computes (cred)H and looks it up in the revocation list. If found, the credential has expired, so the server fails the login attempt.

5. If (cred)H is not found in the revocation list, the server checks exp, m >= n, and HMAC(s) user/domain. If any are invalid, the server fails the login attempt.

6. The server computes (s)H(n) using s from the decrypted credential and n from the client packet and compares the result with the value of (s)H(n) provided in the client message. If they don’t match, the server fails the login attempt.

7. The server decrypts and hashes clientNonce, chooses serverNonce, adds (cred)H, t3+now to the revocation list, and sends the following value to the client:

   (serverNonce, (clientNonce)H)k

   where k is

   (s)H(n-1)

8. The client decrypts the value, verifies (clientNonce)H, and hashes serverNonce. The client uses the FPLoginCont command to send the following value to the server:

   ((serverNonce)H)k

   where k is

   (s)H(n-1)

9. The server decrypts the value and verifies (serverNonce)H. If they don’t match, the server fails the login attempt.

10. If they match, the server replies to the client with a result code of kFPNoErr. The client is now logged in.

11. Both the server and the client make the following calculation:

    k1' = (clientNonce, serverNonce)H

12. The client calls FPGetSessionToken using k1' as the session key to get a new credential. It also calls FPDisconnectOldSession to tell the server to disconnect the old session and transfer its resources to the new session.

Table 3-11 summarizes the exchange between client and server when reconnecting.

Inherited Access Privileges

AFP Version 2.1 and later supports inherited access privileges through the directory’s Blank Access Privileges bit in the Directory bitmap. When the Blank Access Privileges bit is set for a directory, its other access privilege bits are ignored, and the access privilege bits of the directory’s parent apply to the directory, including the parent’s group affiliation.

The Blank Access Privileges bit cannot be set for a directory that is a share point. Likewise, the Blank Access Privileges bit cannot be set for a volume root directory (Directory ID = 2) of a shared volume because it is always a share point for the administrator/owner.