HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:29:03 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:30:00 GMT ETag: "323f6c-b84d-350ea508" Accept-Ranges: bytes Content-Length: 47181 Connection: close Content-Type: text/plain D. Kemp INTERNET-DRAFT NSA Expires 30 January 1998 July 30, 1997 The Public Key Login Protocol 1. Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet-Draft expires in six months. 2. Abstract This document defines the Public Key Login (PKL) protocol, a challenge- response authentication mechanism using digital signatures. It provides start-of-session authentication for firewall proxies, dial-up Network Access Servers, remote email servers, and interactive protocols such as Telnet and FTP. It provides functionality similar to One Time Passwords and handheld authentication tokens, and it supports both one-way and mutual authentication. PKL uses the authentication exchanges specified in ISO/IEC 9798-3 and NIST FIPS Pub 196. The PKL protocol provides strong authentication at the beginning of a session, but does not by itself provide communication channel integrity or confidentiality. PKL should be used in conjunction with a channel integrity mechanism, for example to provide authentication of individual users over (host-keyed) Virtual Private Network connections. This Internet Draft is intended to be the last version of the PKL specification prior to publication as an Informational RFC. Comments are requested no later than the expiration date of this draft. 3. Introduction Despite the development of communication protocols and mechanisms providing a full suite of security services (IPSEC, TLS, GSS-API), there remains a need for authentication mechanisms that can be used in environments with standard application (Telnet, FTP, etc) and network (TCP, IP, PPP) protocols. Password-based authentication is still widely used in these traditional environments because it is well understood and Kemp draft-kemp-auth-pklogin-03.txt [Page 1] INTERNET-DRAFT Public Key Login July 30, 1997 easy to implement. The critical weaknesses of plain passwords are also well understood, and several approaches have been developed to provide stronger forms of authentication. Applications for strong authentication include: * Firewall proxies or gateways. * Modem connections to dial-up Network Access Servers, using authenti- cation/authorization/accounting protocols such as [RADIUS] and [TACACS+]. * Access to [IMAP] or POP remote email servers. * Interactive sessions to individual hosts in a local environment, using a common authentication framework such as OSF Pluggable Authen- tication Modules [PAM]. Strong authentication methods designed specifically to be easy-to-deploy in traditional environments include: * the One Time Password [OTP] protocol (also known as S/Key(TM)), which uses a one-way cryptographic hash function to compute passwords that cannot be intercepted and reused. * various handheld authentication tokens (SecureID, SNK, SafeWord, Watchword), which use a shared secret key to either transform the time-of-day into a non-reusable password, or compute a response to a non-repeating challenge. This document defines a third type of protocol which uses public key digital signatures to provide strong authentication in traditional environments. Like the alternatives, the Public Key Login (PKL) protocol is relatively easy to incorporate into existing systems, but it addresses some limitations of other strong authentication methods. One Time Password systems must be initialized to allow a fixed number of logins. After that number of uses, the server must be reinitialized with a new seed before authentication can be used again. OTP relies on a user- generated secret which may be subject to guessing if not properly chosen. OTP is subject to a race attack by an eavesdropper if the server does not take special precautions to disallow multiple simultaneous login attempts. An OTP server can issue a challenge from a different system, tricking the user into giving the server the ability to break into that other system. In contrast, the PKL protocol has no fixed login count, it uses random private keys that are resistant to guessing, and it does not require special protection from eavesdroppers because a unique challenge is used for each login attempt. Handheld authentication tokens rely on possession of a secret key as proof of identity. Anyone able to obtain the secret key (by compromising a server, for example) is able to masquerade as the user to any other servers using that secret key. Since user tokens contain only a small number of keys (typically from one to ten), users wishing to authenticate to a large number of servers must either carry multiple tokens or share Kemp draft-kemp-auth-pklogin-03.txt [Page 2] INTERNET-DRAFT Public Key Login July 30, 1997 keys among multiple servers. The PKL protocol needs only one user key to authenticate to any number of servers. Each party has sole control of its own private key and the level of protection provided for it. If signature generation is implemented in a hardware token, the user's private key need not ever be exposed outside the token. OTP and most handheld tokens do not allow the user to authenticate a server; the PKL protocol supports both unilateral and mutual authentication. PKL can be implemented in either hardware or software, but it is particularly suited for use with portable cryptographic tokens such as PC Security Cards, Smartcards, and Smartdisks. Such devices generate and verify digital signatures, and they may provide better protection for private keys than can software-only implementations. 4. Protocol The authentication exchange used in this protocol is the challenge- response digital signature exchange defined by ISO 9798-3 [ISO9798] and NIST FIPS Pub 196 [FIPS196]. This document specifies a particular instantiation of these standards, with a level of detail sufficient to enable the development of interoperable implementations. Authentication is conducted between two entities, designated A and B. In the following discussion, entity A will be referred to as the client or user, and entity B will be referred to as the server. ---------- ---------- | | (optional request) ------> | | | | | | | | <--------------- challenge | | | A | | B | | | response ----------------> | | | `client' | | `server' | | | <------- response (mutual) | | | | | | | | (optional status) -------> | | ---------- ---------- The authentication exchange consists of either two or three messages. The first two are used for unilateral authentication, in which B authenticates the identity of A. All three messages are used for mutual authentication, in which each party authenticates the other. The messages are: PKL1: The initial challenge from B to A PKL2: The response from A to B PKL3: The response from B to A in a mutual authentication exchange In addition, optional messages may be used before and after the authentication exchange to provide additional information. An optional authentication request message may precede the authentication exchange Kemp draft-kemp-auth-pklogin-03.txt [Page 3] INTERNET-DRAFT Public Key Login July 30, 1997 to indicate the client's desired protocol version, encoding, and public key access methods. The request message also includes an opaque data field which may be used to convey application-specific information such as a user/account identifier: PKL0: Authentication request from A to B After the authentication exchange, one of the following optional status messages may sent to return status information: PKL4: Status message from B to A after unilateral authentication PKL4: Status message from A to B after mutual authentication 4.1 Message Syntax Each of the messages in a PKL authentication exchange consists of a message header, followed by one or more Type-Length-Value fields. Each field in a message begins with a tag character which specifies the field type. Fields may also include a tag qualifier code and/or a field value as defined in Figure 1. The field descriptions in the next section specify the tag qualifier codes and field values applicable to each field type. The protocol may be extended by defining additional qualifier codes for existing types or by defining new field types. ----------------------------------------------------------------------- %token MSG /* Message header, for example `PKL1' */ %token INT /* Tag qualifier code (an integer) */ %token VALUE /* Variable-length byte string and it's length */ message : MSG `:' fields `:' ; fields : field `:' /* One or more fields per message */ | fields field `:' ; field : `M' /* Mutual Authentication Flag */ | `V' INT /* Protocol Version Number */ | `F' INT /* Message Encoding Format */ | `K' INT /* Public Key Access Method */ | `E' INT /* Error/Status Reply Code */ | `R' VALUE /* Nonrepeating Value (nonce) from A or B */ | `S' VALUE /* Digital Signature generated by A or B */ | `C' INT VALUE /* Cert, Handle, or Cert Path for A or B */ | `X' INT VALUE /* Signed Opaque Data */ | `U' INT VALUE /* Unsigned Opaque Data */ ; ----------------------------------------------------------------------- Figure 1. PKL Generic Message Syntax Kemp draft-kemp-auth-pklogin-03.txt [Page 4] INTERNET-DRAFT Public Key Login July 30, 1997 Figure 1 specifies the PKL message syntax (using the notation of the "yacc" parser generator). PKL messages may be encoded using either ASCII or binary formats. The message syntax for ASCII and binary formats is identical except that field separator characters (`:') are not used with binary messages. Figure 2 shows the field types included in each message of the PKL exchange. Subscripts `a' and `b' are used with some field types to indicate the entity to which the field applies. For example, Rb refers to an R field (nonce) generated by `B' (the server). The A: or B: in the first column specifies the sender of the message. Optional fields are enclosed in braces `{ }'; fields not identified as optional are required. Fields may appear in arbitrary order within a message, and no field except those specifically designated may appear more than once in a message. The optional authentication request message `PKL0:' may include multiple fields of the same type to allow the client to specify a list of acceptable capabilities; the fields which may appear multiple times in that message are identified by an asterisk `*'. ----------------------------------------------------------------------- A: Auth. Request: PKL0:{V}*:{F}*:{K}*:{U}:: B: Challenge: PKL1:K:Rb:Cb:{V}:{U}:{E}:: A: Response: PKL2:Ra:Ca:Sa:{U}:{X}:{M}:{E}:: B: Mutual Response: PKL3:Sb:{U}:{X}:{E}:: B: Unilat. Status: PKL4:E:: A: Mutual Status: PKL4:E:: ----------------------------------------------------------------------- Figure 2. PKL Message Fields 4.2 Message Encoding This document defines two message encoding formats, ASCII and binary. Implementations may support either or both of the formats, as appropriate for the authentication environment. 4.2.1 ASCII Encoding In the ASCII format, each message consists of a message label, one or more tagged value fields, and a null field which serves as the message terminator: PKL#:tag1-value1:tag2-value2:...:: The fixed-format message label (`PKL#') provides a marker for the beginning of authentication protocol messages. In many applications the authentication messages will travel over the same channel as other application-layer data. Implementations may need to scan a continuous datastream to locate message labels before being able to process the authentication messages. Kemp draft-kemp-auth-pklogin-03.txt [Page 5] INTERNET-DRAFT Public Key Login July 30, 1997 Each field includes a tag type character, and may include a tag qualifier and/or a value as specified in Figure 1. Tag qualifiers are integers encoded as one or more ASCII digits. Field values are encoded using the [BASE64] mime-content-type and are separated from the tag by a dash `-' character. Base64 encoding enables binary (8-bit) values to be transported over 7-bit channels, and it implicitly includes the length of the value. Fields are separated by colon characters `:', and an empty field `::' terminates the message. An actual message would look like: PKL1:K1:C0-cAQU5EUk:R-nZImJjnTNHJUtX3r:: Tags and message labels are defined constants and must be capitalized as shown. Whitespace is not allowed within message labels or field tags. Whitespace is allowed between fields and within values as specified in [BASE64]. Implementations should generate PKL messages with lines no wider than 76 characters, and should accept messages with or without linebreaks. 4.2.2 Binary Encoding In binary format, each message consists of a two byte message header followed by one or more variable length fields. Unlike the ASCII encoding, no null field is used to terminate the message since a field count is included in the header. The message header includes the message number and field count: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg | NFields | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg: Message label number - an ASCII digit `0'-'4' (0x30-0x34) NFields: Number of fields in this message. The message fields immediately follow the header. Each field consists of a four byte descriptor and a variable length value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Qual | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Value (variable length) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag: The ASCII Tag Type character (`M', `V', `F', etc.) Qual: Unsigned integer Tag Qualifier code in the range 0-254. If a qualifier is not used with the specified tag type, Qual shall have the value 255 (0xff). Kemp draft-kemp-auth-pklogin-03.txt [Page 6] INTERNET-DRAFT Public Key Login July 30, 1997 Length: The number of bytes in the following Value. This is a two byte unsigned integer, MSB first. If no value is used with the specified tag type, Length shall have the value 0. Value: A variable length binary value, MSB first, 0-65535 bytes. 5. Message Fields 5.1 Protocol Version This document describes version 1 of the Public Key Login protocol. The optional V field indicates the protocol version being used; if not present, version 1 is the default. Protocol evolution may be accommodated by defining additional field qualifier codes or field types without requiring a new version number to be assigned. Implementations should reject messages containing unrecognized field tags other than the allowed Opaque Data tags. If a server receives an authentication request message specifying a version that it does not support, it may either begin an authentication exchange with a supported version and including an explicit version field, or it may reject the request with an error reply code. The following version code is defined: V1: PKL protocol version 1 5.2 Message Encoding Format An optional Format field (`F') in the authentication request message (PKL0) selects the format of the following messages and enables the definition of additional message formats if necessary. If this field is not present, a default encoding suitable for the particular application is used. Message PKL0, if present, must be encoded using the default format. The following encodings are defined: F1: ASCII message labels and field tags, Base64-encoded values F2: binary message labels, field tags and field values Because the two formats are intended for different environments, support for both formats is optional. An environment-specific profile, described in the "Conformance Requirements" section, specifies the required and default message formats. 5.3 Nonces The Ra and Rb fields are non-repeating values generated by the client and server respectively. Nonces must contain at least 64 bits of random data, and the security of the protocol depends critically on the quality of the data in these fields. See the discussion below under Security Considerations. Kemp draft-kemp-auth-pklogin-03.txt [Page 7] INTERNET-DRAFT Public Key Login July 30, 1997 5.4 Public Key access method This field has no associated value; the tag qualifier specifies the type of information used to retrieve public keys. The entity which issues the challenge (referred to as the server) selects the key access method; client implementations must support the selected method or return an error indication. The client may request preferred method(s) using the optional authentication request message. K1: The server certificate handle is contained in message PKL1 and the client certificate handle is contained in message PKL2. A handle is an opaque value used to refer to a certificate. The mapping from handles to certificates is established once using a registration procedure; subsequent authentication exchanges can then use short handles instead of full certificates. K2: The server's certificate is contained in message PKL1 and the client's certificate is contained in message PKL2. K3: The server's and client's certificate paths are contained in messages PKL1 and PKL2. K4: The server's and client's certificate paths and auxiliary information (such as Certificate Revocation Lists) are contained in messages PKL1 and PKL2. The environment profile specifies which key access methods must be supported. It is recommended that client and server implementations support at least methods K1 and K2. The structure and encoding of certificates, certificate paths, and revocation lists is (or should be) specified by the references for the listed certificate types. 5.5 Identifiers and Certificates The PKL protocol requires the use of public/private key pairs and associated parameters to generate and verify digital signatures, but does not specify how implementations are to maintain this information. In the simplest case, keys and parameters are statically configured on the client and server. This is equivalent to configuring a One Time Password system or a symmetric key authentication token. Alternatively, public key certificates can be statically configured, transmitted within the PKL protocol, or retrieved from a directory server. 5.5.1 Certificate Registration and Retrieval When using Key Access option K1, implementations use a handle to refer to a public key or certificate. Certificates are exchanged once using a registration protocol described below, and then only short handles are transmitted during authentication. Implementations may store the full certificate referred to by a handle, or they may store only a certificate identifier (Distinguished Name, etc) and retrieve the full certificate from a directory at authentication time, using a protocol such as [LDAP]. Kemp draft-kemp-auth-pklogin-03.txt [Page 8] INTERNET-DRAFT Public Key Login July 30, 1997 For unilateral authentication, entity B is not required to have a public/ private key pair or certificate. In this case B is referred to by an entity name (certificate type C0). The name should displayed to the user during authentication, but it is not used or interpreted by the protocol. 5.5.2 Certificate Transmission When using certificate-based Key Access options (K2,K3,K4), public key certificates are transmitted as part of the authentication exchange. In this case, implementations should verify that the binding between subject ID and public key is valid by validating all certificates in the path between a trusted party and the entity being authenticated. 5.5.3 Certificate Type Assignments C0 Entity name (no certificate) C1 DER-encoded X.509 certificate(s) [X.509], [PKIX]. C2 PGP [PGP] C3 Secure DNS C4-C6 (unused: unsigned values are not useful for authentication) C7 (unused: X.509 CRLs are included with type C1) C8 SPKI certificate(s) [SPKI] C9 Certificate handle - an opaque value assigned at registration Certificate Type Values 0 through 9 are assigned as shown above. These assignments are compatible with those given in the Certificate Discovery Protocol [CDP]. Values 10 through 249 inclusive are reserved to the IANA for future allocation as Assigned Numbers. Certificate Type Values 250 through 254 inclusive are available for private use. 5.6 Signed and Unsigned Opaque Data The `X#' and `U#' fields represent signed and unsigned data which is not interpreted by the PKL protocol, and which can be used for application- specific purposes. The tags X1: - X127: and U1: - U127: are reserved to the IANA for future allocation as Assigned Numbers; implementations of this version of the protocol must not generate reserved field tags and must fail to authenticate if a reserved field tag is received. Implementations may use non-reserved tag codes (128-254) for any purpose by private agreement. Unrecognized non-reserved tag codes should be ignored on receipt. The following tags are defined: U0 Unsigned data to be displayed to user X0 Signed data to be displayed to user Signed data is transmitted in the `X' field and included in the digital signature calculations. It is thus protected from modification and bound to the sender's authenticated identity. The PKL protocol makes no use of this field except to guarantee it's integrity and authenticity. This field might be used, for example, with a key establishment protocol such as Diffie-Hellman to bind a session key to authenticated endpoint identities. Kemp draft-kemp-auth-pklogin-03.txt [Page 9] INTERNET-DRAFT Public Key Login July 30, 1997 Unsigned data is transmitted in the `U' field but is not used in any way and is not protected from modification by the protocol. Implementations must not rely on unsigned data in any way that affects the success or failure of authentication or affects any actions based on the authenticated identity. 5.7 Signatures The digital signature fields Sa (in message PKL2) and Sb (in message PKL3) are calculated over the following arguments: Sa: (Ia, Ca, Cb, Ra, Rb, X) Sb: (Ib, Cb, Ca, Rb, Ra, X) Ia is the Initiator flag, consisting of the one byte value 0x49. Ib is the Respondor flag, consisting of the one byte value 0x52. Ca and Cb are the values of the "C" (identity) fields. Ra and Rb are the values of the "R" (nonce) fields. X is the value of the "X" (signed data) field, if any, in the message containing the signature. The algorithm used to generate and verify digital signatures is specified in the entity's public key certificate, or in equivalent configuration data if certificates are not used. The value of the signature fields depend on the algorithm used: Digital Signature Standard: The [DSS] signature of a message is a pair of bit strings designated R and S. The value of the signature field is R followed by (concatenated with) S. The DSS public key (community parameters P, Q, and G, and user-specific public value Y) may be extracted from a certificate, manually configured, or obtained by other methods outside the scope of this protocol. P, Q, and G may be inherited from a parent if they are not present in an entity's certificate. RSA Signature: The RSA signature of a message is a single bit string designated S, which is the value of the signature field. The RSA public key (modulus N and public exponent E) may be extracted from a certificate, manually configured, or obtained by other means. 5.8 Mutual Authentication Flag The optional `M' field in message PKL2 allows the client to request mutual authentication. This field has no tag qualifier code or field value. If it is present, the server must generate message PKL3 if the server is configured to allow mutual authentication. If the server cannot generate message PKL3, it should return an error indication (reply code or human-readable message). If the `M' field is not present, the server must not send message PKL3. Note that there is no reason to allow the server to request mutual authentication, since the server cannot force a client to authenticate any information sent by the server. If the server does not support mutual authentication, it sends a name ("cert" format C0) in message PKL1 in lieu of an actual certificate. In this case the client must not send the `M' field in message PKL2. Kemp draft-kemp-auth-pklogin-03.txt [Page 10] INTERNET-DRAFT Public Key Login July 30, 1997 Client and server implementations should support both unilateral and mutual authentication. Clients which support both should be configurable to require the server to be authenticated. 5.9 Reply Codes This optional field has no associated value; the tag qualifier contains the acknowledgment or error status code. This field is not sent by default, but if a reply code field is sent in one authentication message, all following messages in the current exchange must include reply codes. In this manner either client or server can request that reply codes be used. Implementations must support reply codes for Authentication Success, Authentication Failure, and Continue. Implementations may support additional reply codes which provide more detailed information. In environments where the authentication exchange is visible to the user, it is generally obvious that an authentication request has either succeeded or failed. Additional information can be communicated in free form outside the authentication protocol, and reply codes may not be needed. In other environments, such as modem dialer chat scripts, it may be useful to transmit status information in machine-readable form using this field. Reply codes are based on the three digit format defined in [FTP]. The first digit is a `2' for success/continue and `5' for failure. The second digit is a `0' for protocol syntax status and a `3' for authentication status. The third digit gives additional detail. For the binary message format, the three digit code is converted to a single-byte quantity. The most significant bit (0x80) represents the first digit: 0 for success and 1 for failure; the remaining 7 bits encode the binary representation of digits 2 and 3. The following reply codes, shown for both ASCII and binary formats, are defined: Required: E200 0x00: NOP - Continue. This code is sent by either the client or server to request that reply codes be used in the following messages, or if no other status is applicable to the current message. E230 0x1E: Authentication succeeded. E530 0x9E: Authentication failed. Optional: E201 0x01: Info - Unrecognized non-reserved field tag. E500 0x80: Syntax error - unrecognized or invalid field tag. E501 0x81: Base64 value decoding error. E502 0x82: Requested protocol version "V#" not supported. E503 0x83: Requested message encoding "F#" not supported. E504 0x84: Requested key access method "K#" not supported. E505 0x85: Mutual authentication not supported. Kemp draft-kemp-auth-pklogin-03.txt [Page 11] INTERNET-DRAFT Public Key Login July 30, 1997 E506 0x86: Certificate format "C#" not supported. E531 0x9F: Invalid entity ID - public key could not be retrieved. E534 0xA2: Invalid public key certificate - many possible causes, including expired or revoked certificate, path validation failed, unknown or unsupported certificate format, etc. 6. Registration The PKL protocol allows certificates to be either passed within the authentication exchange or referenced by a certificate "handle". The latter case generates considerably less traffic during authentication, but requires that identifiers be assigned to certificates before the authentication protocol can be used. This section specifies a registration protocol by which handles can be assigned to certificates. Handles are chosen by the subject (sender) of a certificate and must uniquely identify that certificate to the receiver. Handles may be meaningful to a user (hostname, username, FQDN, RFC822 name, etc) or they may be a database or cryptographic hash (CRC, SHA, MD5, etc) of the certificate. The use of a particular type of handle is a local implementation matter, driven by tradeoffs among handle size, uniqueness, and ergonomics. The registration protocol consists of two messages, which may be exchanged offline (via email, file transfer, floppy disk, etc.). The messages are protected from modification by a secret key, which should be communicated separately from the registration messages. The registration messages contain the Certificates and a keyed signature field to provide integrity protection. They are encoded using a format similar to the authentication messages, but using a different message header `PKLR:'. The client's and server's messages contain the same field types, and may be exchanged in either order. B: PKLR:C9b:C#b:Sb(K,C9b,C#b):: A: PKLR:C9a:C#a:Sa(K,C9a,C#a):: Registration consists of the following steps: 1. One of the parties (either A or B) generates a registration key K and sends it to the other party. It is recommended that K be sent over a different channel than the registration messages, for example by telephone, fax, mail, or courier service. Implementations must allow K to be specified in hexadecimal format, and should also allow K to be entered in a more user-friendly passphrase format. If a passphrase is used, it must be canonicalized for use as a key by removing all non alphanumeric characters. 2. The server B forms its full certificate path Cb beginning with B's certificate and ending with a certificate signed by an entity trusted by both A and B. B also chooses a handle for it's certificate, iden- tified by the tag "C9". B then creates a registration message contain- ing C9b, Cb and B's signature of K, C9b and Cb, and sends the message to A. Kemp draft-kemp-auth-pklogin-03.txt [Page 12] INTERNET-DRAFT Public Key Login July 30, 1997 3. The user A generates an analogous registration message using K, C9a, and Ca and sends it to B. The two registration messages may be sent in parallel or in either order. 4. The server B processes the message from A by validating the certifi- cate path Ca, prompting the operator for K, verifying A's signature of K and Ca, and computing A's entity ID. B then stores either Ca itself, or information sufficient to retrieve Ca from a directory, indexed by A's handle C9a. 5. A processes the registration message from B in a similar manner, stor- ing the relationship between B's handle and Cb. 7. Conformance Requirements This specification is intended to provide sufficient detail to enable the development of interoperable implementations, but due to the diversity of potential environments, it does not define a minimum set of capabilities that all implementations must support. In order to guarantee interoperability within a particular environment, this specification must be supplemented by a profile which specifies the minimum required: * supported and default message encoding format(s) (ASCII, BINARY) * authentication message(s) (unilateral, mutual, request/status) * key access method(s) (handles, certificates, certification paths) * certificate format(s) (X.509, ...) * signature algorithm(s) (DSA, RSA, ...) All implementations must support the required field types `K', `R', `C', `S', the error field `E', and, if the profile requires mutual authentication, `M'. The profile may require implementations to support the other field types `V', `F', `X', and `U'. 8. Examples A minimal unilateral authentication exchange might look like: B: PKL1:K1:C0-H8grw2+n:R-nZImJjnTNHJU:: A: PKL2:R-As84kLN3/IJm:C9-pNd+lRiu:S-Wiy6IesKvjL5rL9WjXUb9BkA:: The use of cert field C0 in the first message indicates that the server has no certificate and thus cannot perform mutual authentication. A mutual authentication exchange with status codes might look like: B: PKL1:K1:C9-cAQU5EUk:R-nZImJjnTNHJUtX:: A: PKL2:R-As84kLN3/IJm:C9-M39x+I8e:S-Wiy6IesKvjL5rL9WjXUb9BkA:M:E200:: B: PKL3:S-6IesKvjL5rL9WjXUb9MwT9bp:E230:: A: PKL4:E230:: Kemp draft-kemp-auth-pklogin-03.txt [Page 13] INTERNET-DRAFT Public Key Login July 30, 1997 If certificates are exchanged, the messages are considerably longer. The Internet Message Access Protocol [IMAP4] includes an AUTHENTICATE command which could be used to invoke PKL authentication. Because IMAP authentication messages are encoded as a whole in Base64, it is appropriate to use the PKL binary message format to avoid double encoding. A PKL exchange within IMAP4 might look like the following: (C: and S: indicate lines sent by the client and server respectively.) S: * OK IMAP4 Server C: A001 AUTHENTICATE PKL S: + xxxxxxxxxxxxxxxxxxxxxxx C: yyyyyyyyyyyyyyyyyyyyyyy S: A001 OK PKL authentication successful 9. Security Considerations 9.1 Authentication and Data Integrity The primary limitation of start-of-session authentication protocols, including this one, is that they provide no protection to the data exchanged over a connection. Authentication by itself does not protect user data from an eavesdropper, does not protect the user's session against active attacks [CERT], and is of limited usefulness when the channel between authenticating parties is not trusted. If a protocol providing data integrity protection ([IPSEC], [TLS], etc.) is available, it should be used in lieu of an authentication-only protocol. In some situations it may be useful to combine an authentication-only protocol with other methods, for example to provide user authentication at the application layer over (host-keyed) Virtual Private Networks using IPSEC at the network layer. 9.2 Identity Checking and Signing Client software should not respond to unsolicited challenges, i.e. it should operate only in response to a client-initiated connection request. Client software should validate the server identity (including certificate processing) and verify that the server identity is as expected (possibly by user confirmation) prior to sending a response. Similarly, servers should validate the client identity prior to sending the server (mutual authentication) response. 9.3 Challenge Response vs. Time The Public Key Login protocol uses an authentication method based on signed challenges. This avoids the following problems faced by public key authentication methods (for example, [X.509]) based on signed time fields: * Clocks must be synchronized. This may be difficult to achieve in some situations. * Even environments which provide tightly-controlled clocks (using e.g. NTP), the security of the authentication protocol depends on the secu- Kemp draft-kemp-auth-pklogin-03.txt [Page 14] INTERNET-DRAFT Public Key Login July 30, 1997 rity of the time synchronization method. A protocol which does not have this critical reliance on an external service is preferable. * Even in environments which provide synchronized clocks which are resistant to failure or attack, time-based authentication methods must allow a window of acceptance to accommodate communication delays. Eliminating vulnerability to replay attacks within this win- dow requires additional complication, particularly when multiple servers are involved. In contrast, challenge-response authentication is only subject to replay attacks if a challenge is repeated. This is easily prevented, as addressed in the following section. 9.4 Nonces The ability of challenge-response protocols to protect against replay attacks relies on the assumption that nonces will not be repeated during the lifetime of the digital signature keys with which they are used. Random numbers are often used as nonces. However, a number chosen at random will have a small but non-zero probability of taking any particular value. The probability of repeating one of the previously- used nonces increases with continuing use of the authentication protocol with a particular signature key. Nonces containing a deterministic component such as time or a sequence number have zero probability of repeating as long as the deterministic component is reliable, but achieving the required level of reliability is problematic. Accordingly, it is recommended that implementations of this protocol construct nonces by concatenating a random value with a long-term non-repeating value such as time. Note that this application of a time value does not require that clocks be synchronized either with real-world time or between the authenticating parties. 9.5 Authentication, Identities and Authorization The PKL protocol provides authentication - proof that an entity at the other end of a connection possesses the private key corresponding to a given public key. Certificates are used to bind authorizations, either explicitly, or implicitly by use of an entity ID, to the public key. Representation and automated processing of authorizations is the focus of current research efforts, for example [SPKI]. Mechanisms such as Access Control Lists (ACLs) based on users and groups may also be used to grant specific authorizations to specific entities. Note that implementations must take care to ensure that access control or other actions are based on the identity which has been authenticated, not on claimed or otherwise unauthenticated identities. This is particularly important when certificates are contained in the protocol messages and are used for implicit (ID-based) authorization. For example, a user attempting to login with username "Bob" could present a valid certificate for user "Alice" and a signature generated with Alice's private key. After successfully verifying the signature, the server must not log the user on to Bob's account. Kemp draft-kemp-auth-pklogin-03.txt [Page 15] INTERNET-DRAFT Public Key Login July 30, 1997 9.6 Digital Signature Calculations The digital signature fields are calculated over both the sender and the recipient identities. The recipient identity and the initiator/responder flag are included to prevent signatures generated in one context from being replayed in a different context. It is generally considered unnecessary to include the sender's identity in signature calculations because the ability to generate the signature is sufficient proof of identity. However, the sender's identity is included here to address the possibility that a certificate issuer has not required the subject to demonstrate the ability to generate the certified signatures. Most would argue that such an issuer has not correctly performed the certification function and should not be trusted. But since including the sender's identity in the signature calculation costs almost nothing and may conceivably be useful, it is included. 9.7 Certificate Path Validation This protocol is usable with a wide range of keying methods, from static keys to certificate transmission to full online directory services. If locally-generated keys or certificates are used, validation is likely to be less complex than if certificates are obtained from a large-scale PKI. In general, validation may involve verifying certificate paths back to a trusted authority whose public key is known locally, and verifying that the validity period of all certificates in the path include the current date. Validation may also involve retrieving and checking revocation lists to ensure that no certificates in the path have been revoked. Certificate path validation procedures do not affect interoperability of the PKL protocol itself, but appropriate validation procedures are critical to assuring that names are bound to the proper keys. 10. References [BASE64] Internet RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Section 5.2, "Base64 Content-Transfer-Encoding", Borenstein & Freed, September 1993 [CDP] Internet Draft (work-in-progress), "Certificate Discovery Protocol", A. Aziz, T. Markson, H. Prafullchandra, R. Skrenta, G. Caronni, draft-ietf-ipsec-cdp-01.txt [CERT] Computer Emergency Response Team, "IP Spoofing and Hijacked Terminal Connections", CA-95:01, January 1995, ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing [DSS] NIST FIPS Pub 186, "Digital Signature Standard (DSS)", 19 May 1994, http://csrc.ncsl.nist.gov/fips/fips186.txt [FIPS196] NIST FIPS Pub 196, "Entity Authentication Using Public Key Cryptography", 16 September 1996 http://csrc.ncsl.nist.gov/fips/fips196.ps Kemp draft-kemp-auth-pklogin-03.txt [Page 16] INTERNET-DRAFT Public Key Login July 30, 1997 [FTP] Internet RFC 959, "File Transfer Protocol", Section 4.2, "FTP Replies", Postel & Reynolds, October 1985 [IMAP4] Internet RFC 1930, "Internet Message Access Protocol - Version 4", M. Crispin, December 1994. See also RFC 1931, IMAP4 Authentication Mechanisms", J. Myers, December 1994. [ISO9798] ISO/IEC 9798-3, "Information technology - Security techniques - Entity authentication mechanisms - Part 3: Entity authentication using a public key algorithm", Section 5.1.2 "Two pass unilateral authentication" and Section 5.2.2 "Three pass mutual authentication", 1993 [LDAP] Internet Draft (work-in-progress), "Lightweight Directory Access Protocol (v3)", M. Wahl, T. Howes, S. Kille, draft- ietf-asid-ldapv3-protocol-01.txt, 5 June 1996. See also RFC 1777, RFC 1798 [OTP] Internet RFC 1938, "A One-Time Password System", N. Haller, C. Metz, May 1996 [PAM] OSF RFC 86.0, "Unified Login with Pluggable Authentication Modules (PAM)", October 1995 http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc86.0.txt [PGP] Internet Draft (work-in-progress) "PGP Message Exchange Formats", D. Atkins, W. Stallings, P. Zimmermann, draft- atkins-pgpformats-01.txt [PKIX] Internet Draft (work-in-progress) "..." [RADIUS] Internet-Draft (work-in-progress), "Remote Authentication Dial In User Service (RADIUS)", November 1995, draft-rigney- radius-01.txt [SHA] NIST FIPS Pub 180-1, "Secure Hash Standard", 31 May 1994, http://csrc.ncsl.nist.gov/fips/fip180-1.txt [SPKI] Internet-Draft (work-in-progress), "Simple Public Key Certificate", Ellison, Frantz, Thomas, draft-xxx [UDH] Internet Draft (work-in-progress), "Encoding of an Unsigned Diffie-Hellman Public Value", A. Aziz, T. Markson, H. Prafullchandra, draft-ietf-ipsec-skip-udh-00.txt [X.509] ISO 9594-8 / ITU-T X.509, "The Directory: Authentication Framework", ftp://ftp.bull.com/pub/OSIdirectory/ITU/X.509/ 97x509final.doc Kemp draft-kemp-auth-pklogin-03.txt [Page 17] INTERNET-DRAFT Public Key Login July 30, 1997 11. Acknowledgments Thanks to Hugh Harney of SPARTA, Inc., Dave Balenson of Trusted Information Systems, Dale Hapeman of Booz-Allen-Hamilton, Carl Ellison of Cybercash, Denis Pinkas of Bull S.A., and Mike Macgirvin of Netscape for reviewing drafts of this protocol and suggesting many improvements. Special thanks to Jim Press of ICL for suggesting several changes to make the protocol more usable in a real application, and to Andrea Colegrove of NSA for several of the Security Considerations. 12. Author's Address David P. Kemp National Security Agency, X31 9800 Savage Road Fort Meade, MD 20755 USA Email: dpkemp@missi.ncsc.mil Kemp draft-kemp-auth-pklogin-03.txt [Page 18]