[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CERT_REQ_PAYLOAD usage
Scott Fanning writes:
> RFC 2408 states
>
> The Certificate Request Payload provides a means to request
> certificates via ISAKMP and can appear in any message. Certificate
> Request payloads SHOULD be included in an exchange whenever an
> appropriate directory service (e.g. Secure DNS [DNSSEC]) is not
> available to distribute certificates.
>
> and
>
> If multiple certificates are required,
> then multiple Certificate Request payloads SHOULD be transmitted.
The RFC 2408 also says:
----------------------------------------------------------------------
3.9 Certificate Payload
...
Certificate payload MUST be accepted at any point during an exchange.
Figure 10 shows the format of the Certificate Payload.
...
----------------------------------------------------------------------
> The behaviour I saw was one of the following.
> 1) Initiator sends CRP per cert required, and responder replies with
> the appropriate certificates.
This is propably the best approach.
> 2) Initiator sends 1 CRP, and the responder sends all certs.
This is same as case 1, except the responder also choose to send some
extra certificates that it think might be usefull for the initiator.
There are some usages for this, for example it might send encryption
capable certificate also in signature authentication just to preload
that certificate to initiator, so the initiator can use rsa encryption
next time.
> 3) Initiator does not send CRP, but wants all certs because RSA was
> negotiated.
This I think is bad. If you dont send certificate request payload at
all that should mean that you don't want to have any certificates, you
think you already have the ones needed. The responder might still send
you a certificate just in case in some cases. For example the
responder might send it certificate to you if it just enrolled new one
and is going to use that one instead of the old one that the initiator
has.
> I am sure there are others. I would like to recommend that option 1
> is the best option, and the simplest. This has caused many interop
> issues, and the vague wording does not help. I would like to tighten
> up the rules if possible.
I would think the rules will be:
1) If you absolutely need certificates from the other side for
the authentication to work, you MUST send certificate request
payload.
2) If the authentication can succeed without the other end
sending certificates (you have some certificate for the other
end, or you can fetch the certificate from the certificate
repository), you MAY send certificate request.
3) If you just want any certificate without specifying the CA
root, send certificate request having empty CA name.
4) When you receive certificate request you MUST send your own
certificate for that CA.
5) If you receive empty certificate request you MUST send the
certificate you are going use in the authentication. If you
have multiple certificates for the same private key, you
SHOULD send all of them.
6) If you do not receive certificate request, you SHOULD NOT
send any certificates, unless you have reason to belive that
the other end has wrong certificate for you (for example you
have enrolled a new certificate recently).
7) You MAY include extra certificates, CRLs etc if you have
them available (I.e include your other certificates also
(certificate pre-loading), include sub-CA certificates,
include CRLs etc.
--
kivinen@ssh.fi Work : +358 303 9870
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: