IMAP4 Authentication Mechanisms
Extracted elements (23)
S/Key authentication deliberately provides no protection mechanisms. This is an implicit design choice: S/Key is a one-time-password scheme for authentication only, offering no session integrity or privacy after login.
The protection mechanism negotiation uses a bit-mask in a single octet, allowing the server to advertise multiple supported mechanisms simultaneously and the client to select one. This design enables extensible capability advertisement within the authentication exchange itself.
GSSAPI target name must be constructed as 'SERVICE:imap@hostname' where hostname is the fully qualified host name of the server with all letters in lower case, passed to GSS_Import_Name with input_name_type of NULL.
Kerberos V4 principal name must be 'imap.hostname@realm' where hostname is the first component of the server host name in lower case and realm is the Kerberos realm of the server.
For GSSAPI, the client must call GSS_Init_sec_context with input_name_string 'SERVICE:imap@hostname' where hostname is the fully qualified host name in lower case. The client must respond with the resulting output_token.
For Kerberos V4, the encrypted checksum in the authenticator must contain the server-provided 32-bit number in network byte order, providing proof of freshness and binding the authenticator to the specific authentication session.
The client must construct the response data, pad it to a multiple of 8 octets by appending 1 to 8 octets, and PCBC-encrypt the data with the session key before responding to the second server ready response.
The GSSAPI server must seal its 4-octet capability advertisement using GSS_Seal with conf_flag set to FALSE, and must pass the client's reply through GSS_Unseal to extract the selected protection mechanism, maximum message size, and user name.
The GSSAPI server must verify that the GSS src_name is authorized to authenticate as the provided user name before considering the client authenticated.
Upon decrypting the Kerberos ticket and authenticator, the server must add one to the checksum and encrypt the resulting 8-octet response in the session key. The server must verify that the principal in the Kerberos ticket is authorized to connect as the specified user name.
Upon successful verification of the S/Key one-time-password, the server should consider the client authenticated. S/Key authentication provides no protection mechanisms for subsequent protocol interactions.
Kerberos V4 and GSSAPI protection mechanisms are encoded as bit-masks: 1 = no protection, 2 = integrity protection (krb_mk_safe / GSS_Seal with conf_flag FALSE), 4 = privacy protection (krb_mk_priv / GSS_Seal with conf_flag TRUE).
The GSSAPI authentication type identifier is 'GSSAPI', used with all mechanisms employing GSSAPI [RFC1508]. The server issues an empty first ready response; the client initiates GSS_Init_sec_context with targ_name derived from 'SERVICE:imap@hostname'.
The KERBEROS_V4 authentication type uses the IMAP4 AUTHENTICATE command. The server issues a challenge containing a random 32-bit number, and the client responds with a Kerberos ticket and authenticator for the principal 'imap.hostname@realm'.
The S/Key authentication type identifier is 'SKEY'. The server issues an empty first ready response; the client responds with the user name string. The server then issues the decimal sequence number followed by a space and the seed string.
Security issues are discussed throughout the memo. The Kerberos V4 mechanism provides mutual authentication via nonce verification; GSSAPI provides configurable integrity and privacy protection; S/Key provides one-time-password authentication without session protection.
GSSAPI authentication proceeds through the following states: (1) server issues empty challenge; (2) client calls GSS_Init_sec_context and sends output_token; (3) if GSS_CONTINUE_NEEDED, tokens are exchanged until GSS_COMPLETE; (4) server sends sealed capability octets; (5) client sends sealed selection and user name; (6) server verifies authorization and authentication is complete.
After GSSAPI context establishment, the server constructs 4 octets sealed with GSS_Seal (conf_flag FALSE): octet 1 is the protection mechanism bit-mask, octets 2-4 (network byte order) are the maximum output_token size the server can receive.
The first Kerberos V4 server ready response encodes a random 32-bit number in network byte order. This nonce is used as the checksum field in the Kerberos authenticator sent by the client.
The GSSAPI client constructs a plaintext message sealed with GSS_Seal (conf_flag FALSE): octet 1 is the selected protection mechanism bit-mask, octets 2-4 (network byte order) are the maximum output_message size the client can receive, followed by the user name string.
The Kerberos V4 client final message contains: octets 1-4 with the original server checksum (network byte order), octet 5 with the selected protection mechanism bit-mask, octets 6-8 with the maximum cipher-text buffer size the client can receive (network byte order), followed by the user name string. The data is padded to a multiple of 8 octets and PCBC-encrypted with the session key.
The Kerberos V4 second server ready response contains 8 octets encrypted in the session key: octets 1-4 are the incremented checksum (network byte order), octet 5 is a protection mechanism bit-mask, and octets 6-8 are the maximum cipher-text buffer size the server can receive (network byte order).
The S/Key second server ready response contains the decimal sequence number, a single space, and the seed string for the indicated user. The client responds with the one-time-password as either a 64-bit value in network byte order or encoded as 'six English words'.