[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP: Fixes to certificate discovery protocol
Hi,
As Germano Caronni pointed out, the certificate discovery protocol described
in the most recent SKIP draft is "botched". We would like to propose this
as the replacement to the Certificate Discovery Protocol. If there are
no problems with it, we will replace the text in the next round of
draft.
--tom
4.3 Certificate Discovery Protocol
An optional protocol is described to enable communicating IP-nodes to
discover each other's certificate(s). This obviates the need for an on-
line certificate directory server.
A number of certificate types currently exist, for example, X.509, PGP
DNS-SIG, Unsigned DH pub value. This protocol allows for all of these
types. Also note, that a particular IP-node may have more than one
certificate. A node could have the same Diffie-Hellman public value in
different certificate formats, or have multiple Diffie-Hellman public
values each in a separate certificate or have the same Diffie-Hellman
public value certified by different Certifying Authorities, and so on.
In all these possible certificates the identity of the node remains
constant. An algorithm for choosing a particular certificate
(essentially a Diffie-Hellman public value) when more than one exist is
described later.
All certificate discovery protocol communication use the User Datagram
Protocol (UDP). The initiator binds to port skip-cert-send (6456) and
sends a certificate request to port skip-cert-recv (6455). The
responder binds to port skip-cert-recv and sends the response to port
skip-cert-send. Two separate ports are used to allow for multiple
certificate requests to be made without waiting for the response to be
received, (that means, one port is used to simply send requests out and
the other port is used to receive responses). A simple cache of the
Master Key-ID and the IP address to which the request was sent is all
that is required to manage outstanding certificate requests.
Implementation Note: Considering that a node may be pre-configured to
allow only encrypted communication with any other node, a certificate
request would be rejected. It is suggested that the two ports (skip-
cert-send and skip-cert-recv) be treated as a "by-pass" channel for
encryption. As only certificates requests are satisfied on these ports
the window for vulnerability is limited.
The certificate discovery packet:
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERS |ACTION | STATUS | NUMBER-OF-CERTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Master Key-ID of certificate ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT-TYPE | NSID |CERT-LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERTIFICATE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT-TYPE | NSID |CERT-LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERTIFICATE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
VERS indicates protocol version #. VERS = 1 for this protocol.
ACTION indicates the type of message. Possible values are:
1 (Request) - request for remote parties certificate(s).
2 (Response) - response to a certificate request.
STATUS is used only in responses (i.e. ACTION = 2). Possible values are:
0 (OK) - process the certificates sent. NUMBER-OF-CERTS must not
be zero.
1 (Unknown Error) - an error has occurred.
2 (Unknown Master Key-ID) - no certificates for the requested Master
Key-ID can be found in the local certificate
database.
NUMBER-OF-CERTS - if 0 then no certificates are present in the message
and the message is simply a request for all certificates
for the specified Master Key-ID or a response where the
STATUS octet indicates an error.
Master Key-ID - this is the identifier as described in the section on
Master Key-IDs. It's length is dependent on the value
of the NSID field. It is only used when requesting
certificates with a specific master key-id from another
entity. The requester may set this to zero (0) in which
case the receiver should consider the request for ALL
certificates. The responder should always set this
field to zero (0).
Each public key or certificate will be returned with the following
information present.
CERT-TYPE - specifies the certificate type of the certificate that
is to follow. Some well known types have been assigned
values below in the Assigned Numbers section.
NSID - identifies the namespace that the Key-ID belongs to.
The values of this field are described in the assigned
numbers portion of this document.
CERT-LENGTH - specifies the length of the certificate in bytes
CERTIFICATE - the actual certificate.
Note that this allows for the initiator to request all certificates or
just certificates for a particular Master Key-ID. It also allows the
requester to send in the same message all the certificates it has.
As certificates have the subjects identity (i.e. specifies the
certificate owner), this information does not have to be sent to
other party.
The Certificate Discovery Protocol allows certificate requests to be
made to any arbitrary IP-node. This feature allows the initiator to send
requests to, say, an IP-node which is acting as a DNS or NFS server (and
hence would have many certificates stored in its local certificate
database).
--tom