The PGP authentication type has been specified in the form of a RFC draft document. The main text includes extractions from this draft. It is included here just as a short-form reference.
Asgaut Eng
Request for Comments: DRAFT
October 1995
Telnet Authentication: PGP
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
The PGP authentication uses the Telnet Authentication Option framework,
as documented in RFC 1416.
This authentication scheme is based on public key cryptography as
implemented in PGP (Phil Zimmermann's "Pretty Good Privacy" program).
1. Command Names and Codes
Authentication Types
PGP XX
Suboption Commands
CHALLENGE 0
AUTH 1
REJECT 2
ACCEPT 3
QUERYPUBKEY 4
PUBKEY 5
2. Command Meanings
The suboption commands may be sent by both the client and the server.
In the descriptions below, IS/REPLY are specified as the AUTHENTICATION
subcommand. The client uses the IS command, while the server uses the
REPLY command.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> CHALLENGE
<challenge> IAC SE
This is used to send the <challenge> information to the party we
want to authenticate. The first byte of the <authentication-type-pair>
is PGP to indicate that this is PGP authentication information.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> AUTH
<pgp-authentication-information> IAC SE
This is used to pass authentication information to the other party.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> QUERYPUBKEY
IAC SE
This is used when one of the sides do not know or wants an updated
version of the PGP public key of the other party.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> PUBKEY
<pgp-public-key> IAC SE
This command sends the public key to the remote end.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> ACCEPT IAC SE
This command indicates that the authentication was successful.
IAC SB AUTHENTICATION IS/REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE
This command indicates that the authentication was not successful,
and if there is any more data in the sub-option, it is an ASCII text
message of the reason for the rejection.
3. Implementation Rules
If one of the sides do not have the PGP public key of the other,
the response to the AUTH command will be QUERYPUBKEY. The receiver of
QUERYPUBKEY must then send its PGP public key, in a PUBKEY command.
When a PGP public-key is received the key can optionally be added to
the local pubring.pgp file. It is recommended that this is done
only when the key is accepted as valid.
When the public key of the other party is known, the communication will
be as below.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_CLIENT_TO_SERVER, then the server sends the initial
CHALLENGE command, and the client sends back a AUTH. The server then
responds with ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, and the
server responds with ACCEPT, then the client must send a CHALLENGE to the
server. The server must then send an AUTH command to authenticate
itself to the client. The client responds to this with ACCEPT or REJECT.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_SERVER_TO_CLIENT, then the tasks of the client and
server in the previous paragraph just are swapped.
4. Examples
In this example a client, user Bob, wants to log in on a server. The
server does not have the PGP public-key of the client, and will ask
for it. The client already has the public key of the server on his
public key ring.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
PGP CLIENT|ONE_WAY
PGP CLIENT|MUTUAL
IAC SE
[ The server has requested one-way client to server PGP
authentication. If this authentication type is not supported,
then the server is willing to do mutual authentication.
The client will now respond with the name of the user that it
wants to log in as, and the authentication type chosen. ]
IAC SB AUTHENTICATION NAME
"bob" IAC SE
IAC SB AUTHENTICATION IS
PGP CLIENT|ONE_WAY
IAC SE
[ The server responds with a CHALLENGE message. ]
IAC SB AUTHENTICATION REPLY
PGP CLIENT|ONE_WAY CHALLENGE
<challenge>
IAC SE
[ The client now has the information it needs to create the PGP
authentication information. ]
IAC SB AUTHENTICATION IS
PGP CLIENT|ONE_WAY AUTH
<pgp-authentication-information>
IAC SE
[ The server responds with a QUERYPUBKEY to ask the client to
send its (hopefully) signed public key since the server did
not know the clients public key. ]
IAC SB AUTHENTICATION REPLY
PGP CLIENT|MUTUAL QUERYPUBKEY
IAC SE
[ The client responds with a PUBKEY message.]
IAC SB AUTHENTICATION REPLY
PGP CLIENT|MUTUAL PUBKEY
<pgp-public-key>
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful (it accepted at least one of
the signatures on the key, and the owner of the key is grantet
access). ]
IAC SB AUTHENTICATION REPLY
PGP CLIENT|MUTUAL ACCEPT
IAC SE
Security Considerations
The ability to negotiate a common authentication mechanism between
client and server is a feature of the authentication option that
should be used with caution. When the negotiation is performed, no
authentication has yet occurred. Therefore, each system has no way
of knowing whether or not it is talking to the system it intends. An
intruder could attempt to negotiate the use of an authentication
system which is either weak, or already compromised by the intruder.
Author's Address
Asgaut Eng
email: asgaut@pvv.unit.no