D. Kemp
INTERNET-DRAFT NSA
Expires 31 May 1997 November 26, 1996
The Public Key Login Protocol
<draft-kemp-auth-pklogin-02.txt>
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 31 May 1997.
2. Abstract
This document defines the Public Key Login (PKL) protocol, a strong
authentication mechanism for interactive sessions. PKL employs the
digital signature challenge-response exchange specified by ISO 9798-3
and NIST FIPS Pub 196. It is suitable for use with unmodified session
protocols such as Telnet and FTP, firewall proxies, dial-up Network
Access Servers, remote mail servers, and similar applications. It
provides functionality similar to One Time Passwords or handheld
authentication tokens, and it supports both one-way and mutual
authentication.
The PKL protocol provides strong authentication at the beginning of a
session and perhaps periodically thereafter, but does not by itself
provide communication channel integrity or confidentiality. Channel
integrity is required in order to fully realize the benefits of strong
authentication; session keys for a cryptographically-protected channel
can be established securely within the PKL exchange.
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 unmodified application (Telnet, FTP, etc) and network
(TCP, IP, PPP) protocols. Plain password authentication is still widely
used in these "traditional" environments because it is well understood
and easy to implement. The critical weaknesses of plain passwords are
also well understood, and several approaches have been developed to
Kemp draft-kemp-auth-pklogin-02.txt [Page 1]
Internet DRAFT Public Key Login November 26, 1996
provide stronger forms of authentication. Applications for strong
authentication include:
* Firewall proxies.
* 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 (once 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;
Steve Bellovin has described a system called "Monkey" that performs
guessing attacks against OTP. 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 additional problem with OTP is
that a 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
cryptographic quality random private keys that are not subject 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. This does not provide non-repudiation - anyone able to
obtain the secret key (by compromising a server, for example) is able to
masquerade as the user to any servers using that secret key. Since user
tokens contain only a small number of keys (typically from one to ten),
Kemp draft-kemp-auth-pklogin-02.txt [Page 2]
Internet DRAFT Public Key Login November 26, 1996
users wishing to authenticate to a large number of servers must either
carry multiple tokens or share 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; this requires an attacker to take physical possession of a
user's token in order to masquerade as that user.
Neither OTP nor most current handheld tokens 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 devices in the
form of PC Cards, Smartcards, and Smartdisks. Such devices perform the
processor-intensive digital signature generation and verification
operations, and may provide better protection for a user's private key
than can systems which generate digital signatures in software.
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
Kemp draft-kemp-auth-pklogin-02.txt [Page 3]
Internet DRAFT Public Key Login November 26, 1996
In addition, optional messages may be used before and after the
authentication exchange to provide additional unauthenticated (advisory)
information. An optional authentication request message may precede the
authentication exchange 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 Tag-Length-Value (TLV) fields.
Each field in a message includes a tag that specifies the field type.
Fields may also include a tag qualifier code and/or a field value and
length as shown in the field definitions in Figure 1. The individual
descriptions for each field type specify the applicable tag qualifier
codes and field values for that type. The protocol may be extended by
defining additional qualifier codes for existing types, or if necessary,
by defining new field types.
-----------------------------------------------------------------------
%token MSG /* Message label, 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 from 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-02.txt [Page 4]
Internet DRAFT Public Key Login November 26, 1996
Figure 1 defines the PKL generic message syntax using a yacc grammar. PKL
messages may be encoded using either ASCII or binary formats. The message
syntax for ASCII and binary formats is identical except that no field
separator characters (`:') are used with binary messages.
Figure 2 shows the fields included in each PKL message. Subscripts `a'
and `b' are used with some field types to indicate to which entity the
field value applies. For example, Rb refers to an R field (nonce)
generated by `B' (the server). Within the signature argument list, the
field names indicate the order in which raw (unencoded) values are
included in the signature calculation. The A: or B: in column 1 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(Ra,Rb,Cb,{X}):{U}:{X}:{M}:{E}::
B: Mutual Response: PKL3:Sb(Rb,Ra,Ca,{X}):{U}:{X}:{E}::
B: Unilat. Status: { PKL4:E:: }
A: Mutual Status: { PKL4:E:: }
-----------------------------------------------------------------------
Figure 2. PKL Messages
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
Kemp draft-kemp-auth-pklogin-02.txt [Page 5]
Internet DRAFT Public Key Login November 26, 1996
5.2 Message Encoding Format
This document describes two message encoding formats, one ASCII and one
binary. 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
F1 (ASCII) 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 disjoint application areas, both
formats are optional. Implementations are expected to use the format
appropriate for their target environment.
5.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 of
this protocol, the authentication messages will travel over the same
channel as other application-layer data. Implementations may need to
scan a continuous datastream for message labels in order to locate and
process the authentication messages.
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 `-'.
Base64 encoding enables binary value data to be transported over ASCII-
only channels, and it implicitly includes the length of the value. Fields
are separated by colon characters `:', and the message terminator is
represented by adjacent colons `::'. An actual message would look like:
PKL1:K1:C0-cAQU5EUk:R-nZImJjnTNHJUtX3r::
Tags and message labels are ASCII constants and must be capitalized as
shown. Whitespace is not allowed within message labels or field tags or
between a tag and the following `-' character. Whitespace is allowed
within values as specified in [BASE64]. Implementations must limit
base64 values to lines of no more than 76 characters, and should break
full PKL messages into lines of no more than 76 characters each.
Kemp draft-kemp-auth-pklogin-02.txt [Page 6]
Internet DRAFT Public Key Login November 26, 1996
5.2.2 Binary Encoding
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).
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.3 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 any of the required methods. The
client may request preferred method(s) using the optional authentication
request message.
Kemp draft-kemp-auth-pklogin-02.txt [Page 7]
Internet DRAFT Public Key Login November 26, 1996
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; authentication messages 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 full certificate paths are contained
in messages PKL1 and PKL2. In addition to requiring a large
amount of data to be exchanged, this method potentially
requires the parties to agree at runtime on a path root (common
point of trust). This protocol does not define any method of
negotiating desired Certificate Authorities.
K4: The server's and client's full certificate paths and auxiliary
information (such as Certificate Revocation List (CRL) and
Compromised Key List (CKL)) are contained in messages PKL1 and
PKL2.
Client implementations must support methods K1 and K2. Server
implementations must support at a minimum either K1 or K2, and should
support both. Client and server implementations may support methods K3
and K4
5.4 Nonces
The Ra and Rb fields are non-repeating values generated by the client and
server respectively. The protocol definition does not specify the size or
content of these fields because such requirements are not necessary to
achieve interoperability. However, the security of the protocol depends
critically on the quality of the data in these fields. See the discussion
below under Security Considerations.
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 Retrieval
When using Key Access option K1, implementations use a handle to refer to
a public key or certificate. Certificates (X.509, SPKI, PGP, etc) 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-02.txt [Page 8]
Internet DRAFT Public Key Login November 26, 1996
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) [X500]. Because the DER
encoding is self-delimiting, multiple certificates may
simply be concatenated for use with the K3 and K4
(certificate path) Key Access options. The first certificate
must be that of the entity to be authenticated.
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 X2: - 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
X1 Diffie-Hellman key exchange information
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
Kemp draft-kemp-auth-pklogin-02.txt [Page 9]
Internet DRAFT Public Key Login November 26, 1996
this field except to guarantee it's integrity and authenticity. This
field might be used, for example, with a key establishment protocol to
bind a session key to authenticated endpoint identities. The tag X1: is
reserved for use with key agreement information such as Diffie-Hellman
values.
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
Digital signatures are calculated over the fields listed in the argument
list, in the specified order. For example `Sa(Ra,Rb,Cb,{X})' specifies
the following processing steps to be performed by A:
* Concatenate the required values Ra, Rb, and Cb in this order
* Append the optional signed data X#, if present in the message
* Calculate the digital signature, producing the value of the Sa field
To achieve interoperability, signatures must be calculated using the
specified argument order. Note: there is no particular significance to
the order in which nonces appear in the signed data - (Ra,Rb) in message
PKL2 vs. (Rb,Ra) in message PKL3; it is defined this way solely for
consistency with [ISO9798].
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 ("S")
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
Kemp draft-kemp-auth-pklogin-02.txt [Page 10]
Internet DRAFT Public Key Login November 26, 1996
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.
Implementations of the PKL protocol must support unilateral
authentication and should support mutual authentication.
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.
Kemp draft-kemp-auth-pklogin-02.txt [Page 11]
Internet DRAFT Public Key Login November 26, 1996
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.
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.
Kemp draft-kemp-auth-pklogin-02.txt [Page 12]
Internet DRAFT Public Key Login November 26, 1996
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.
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. 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::
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 IMAP4
authentication messages are encoded as single Base64 strings, it is
appropriate to use the PKL binary message format followed by Base64
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 PKL0:F2::
S: + xxxxxxxxxxxxxxxxxxxxxxx
C: yyyyyyyyyyyyyyyyyyyyyyy
S: A001 OK PKL authentication successful
Kemp draft-kemp-auth-pklogin-02.txt [Page 13]
Internet DRAFT Public Key Login November 26, 1996
8. Implementation Experience
A protocol similar to this one, the "Mosaic Authentication Protocol"
(MAP), has been in use since April 1994 to provide network and dial-up
access to computers at NSA, and has been commercialized in the
LOCKout(TM) product from Secure Computing Corporation. MAP was also the
basis for HTTP-Fortezza, a prototype demonstration of strong access
control for Web applications.
The PKL protocol is a generalization of MAP, designed to comply with the
NIST Public Key Authentication Standard [FIPS196] and to address
specific problems identified during operational use of MAP. No
implementations of PKL currently exist, but at least two are under
development. All U.S. Federal departments and agencies using challenge-
response public key authentication will be required to comply with FIPS
Pub 196 by April 6, 1997.
9. Security Considerations
9.1 Authentication, Integrity, and Confidentiality
The primary limitation of authentication-only protocols, including this
one, is that they provide no protection to the data exchanged over the
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 both
authentication and channel 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 User Interaction
Like the OTP and handheld token authentication methods, the Public Key
Login protocol is intended to be used on behalf of a human user. User
agent (client) software should only operate in response to a user-
initiated connection request, and should display the identity of the
server and request confirmation from the user before signing and sending
a response message. The client software should not respond to unsolicited
challenges.
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.
Kemp draft-kemp-auth-pklogin-02.txt [Page 14]
Internet DRAFT Public Key Login November 26, 1996
* Even environments which provide tightly-controlled clocks (using e.g.
NTP), the security of the authentication protocol depends on the secu-
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. If a single user authenticates to multiple
servers and the servers' clocks are not synchronized, then any time
component of a nonce does not contribute to replay protection for the
server with the later clock value. Therefore, implementations of this
protocol should construct nonces with a random component sufficiently
large to provide adequate protection without relying on a non-repeating
component.
It is recommended that nonces contain a minimum of 64 bits.
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 attach authorizations, either
explicitly, or implicitly by use of an entity name, 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.
Kemp draft-kemp-auth-pklogin-02.txt [Page 15]
Internet DRAFT Public Key Login November 26, 1996
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,
because that implies that the manual registration procedure was not used
to establish the authorizations applicable to a particular certificate.
For example, a user attempting to login with username "Bob" could present
a valid certificate for user "Fred" and a signature generated with Fred's
private key. After successfully verifying the signature, the server must
not log the user on to Bob's account.
9.6 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
[FTP] Internet RFC 959, "File Transfer Protocol", Section 4.2,
"FTP Replies", Postel & Reynolds, October 1985
Kemp draft-kemp-auth-pklogin-02.txt [Page 16]
Internet DRAFT Public Key Login November 26, 1996
[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
[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.500] ITU X.500, "The Directory"
[X.509] ISO 9594-8 / ITU X.509, "The Directory - Authentication
Framework", (1988 version: http://sunsite.doc.ic.ac.uk/
computing/ccitt/ccitt-standards/1992/X/x509_1.asc.gz)
11. Acknowledgments
Thanks to Hugh Harney of SPARTA, Inc., Dave Balenson of Trusted
Information Systems, and Dale Hapeman of Booz-Allen-Hamilton for their
reviews of this draft and many constructive suggestions. Thanks to Carl
Ellison of Cybercash for suggesting the ideas embodied in the
registration protocol. Special thanks to Jim Press of ICL for suggesting
several changes to make the protocol more usable in a real application.
Kemp draft-kemp-auth-pklogin-02.txt [Page 17]
Internet DRAFT Public Key Login November 26, 1996
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-02.txt [Page 18]