Hi all
The promised rough draft:
Initial Draft about OpenPGP Server-side Signed E-mail (OPSS e-mail)
Intent: To provide a method for server to server SMTP transmission that
allows both
a) encryption
b) rejection before transmission of a message sent by an unauthenticated
server
Throughout this work we will use “server” as the SMTP server intending
to receive e-mail and “client” as the SMTP server trying to send a message.
How it works:
It will work as a standard, plaintext SMTP communication: client starts
SMTP communication with HELO or EHLO. If client starts with HELO, server
MUST assume that the client is not capable of authentication, but this
is not the end of the protocol. If client starts with EHLO, server MUST
announce OPSS as an available extension, then wait for client to confirm
its usage. For a OPSS-enabled EHLO client, second command MUST be OPSS
INIT. If it is, server will try to authenticate client, else server MUST
assume that the client is not capable of authentication, but this is not
the end of the protocol.
If a client is not capable of authentication, server MUST try to match
HELO or EHLO node name with its internal list of known parties. If the
match succeeds, it means that the server knows that the client hloud be
able to do OPSS so server will reject the message with a 554 error
before the message if transmitted and close connection.
If a client gives the OPSS INIT command, server will answer with 250 OK
OPSS CHALLENGE and a printable random string. Client MUST give the OPSS
RESPONSE command adding the ASCII-armored OpenPGP signature of the
random string. Failure to do so means that server will reject the
message with a 554 error before the message if transmitted and close
connection. After OPSS RESPONSE server will opss-verify the signature
(see procedure below) and if it is correct will follow the “Add host to
known parties list” procedure (explained below) and answer with 250 OK
OPSS OK announcing willingness to receive a message, while if the
signature is not opss-verified server MUST reject the message with a 554
error before the message if transmitted and close connection.
On this point a client MAY request the server's OpenPGP key (procedure
below).
Now the client MUST do one of the following: MAY use the STARTTLS
procedures, or MAY issue the OPSS ENCRYPT command. This command will be
answered by a 250 OK message, after which point the entire commands and
replies will be OpenPGP encrypted and signed.
How the client knows the server's OpenPGP key
There are four ways for doing this:
a) It is preloaded by the Administrator
b) It is downloaded from an OpenPGP keyserver before starting the
communication
c) It is present on a DNS record for the server (this method is not
covered by this document)
d) It is requested by the client on the fly
For requesting a key on the fly the client uses OPSS KEY command, which
MUST be answered by the server with a 250 OK OPSS KEY answer and its own
ASCII-armored OpenPGP key.
How the server knows the client's OpenPGP key
There are three ways for doing this:
a) It is preloaded by the Administrator
b) It is downloaded from an OpenPGP keyserver, out of band, while
crafting, sending, receiving and checking the challenge-response.
c) It is present on a DNS record for the client (this method is not
covered by this document) which is checked out of band while crafting,
sending, receiving and checking the challenge-response.
Signature opss-verification procedure
Once the server has the signed response to the challenge, it will
perform a standard OpenPGP verification (OpenPGP verification is one
step of OPSS verification). If this fails, the verification fails. If it
succeeds, server will match the EHLO node name againts its known parties
list.
If it is found as “verified”, server will check the key also stored
there against the one used for the response, and if they match,
verification succeeds and message will be accepted, otherwise
verification fails and message will not be accepted.
If it is found as “non-verified”, server MAY update the key from an
OpenPGP keyserver in order to check if further signatures on it makes it
verified. Anycase verification succeeds and message will be accepted.
Server MAY also check the key also stored in the known parties list
against the one used for the response, and add a
X-OPSS-Signature-not-verified header to the message before delivering it.
Key update from a keyserver may also bring as revoked a previously
verified signature, or may bring a different key for the same client.
Known parties list maintenance
Administrator can add pairs of EHLO node name-OpenPGP key to the list by
hand. Also, any new key detected from OPSS RESPONSE commands will be
added to the list together with the corresponding EHLO node name by
using the “Add host to known parties list” procedure (explained below).
If the server tries to update a key from a keyserver and finds a new
key, this will be added as well, together with the corresponding EHLO
node name.
A node name-key pair can have one of two statuses: verified and
non-verified. Verified means that the server administrator manually
choosed this, or that the trust on the keys signing it justifies to do so.
A node with a verified key can appear only once on the known parties
list, but a node can have several non-verified keys on it, all of them
valid.
Add host to known parties list procedure
When a server receives an OPSS RESPONSE command, it must check its
correpsonding node name on the known parties list. If found as
“Verified”, it does nothing. If found as “non-verified”, server adds the
pair node name-key to the list without removing the already present
pair. If not found, it just adds the pair node name-key to the list.
Web of Trust
The administrator can manually assign a trust level to each key, even
keys that have an empty node name. Procedures for this are standard
OpenPGP. If the configured amount of keys with the correct trust level
are signing a key, that key will be considered verified without manual
administrator intervention. Security note: An administrator should only
assign trust to keys belonging to people or server he positively knows
are conscious of the security implications of signing a key.
Key format
Keys will be standard OpenPGP keys with a corresponding e-mail address
of OPSS_e-mail@[nodename]
X-OPSS-Signature-not-verified header
A server MAY add this header for a non-verified signature. Format is one of:
X-OPSS-Signature-not-verified: Not found [nodename]
X-OPSS-Signature-not-verified: Key found for [nodename], [key]
X-OPSS-Signature-not-verified: Several keys found for [nodename], [key used]
These can be used for MUA spam checking.
Regards
Noel
er Envite
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
