[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest ipsec-pki-req-04.txt



Paul Hoffman writes:
> Should any old cert be useful for IKE identification? If not, is there 
> something between "any" and "IKE only" that makes sense?

I would say that any certificate is ok, if it doesn't have extended
key usage extension. If it has extended key usage extension, then it
means that CA wanted to restricts the use of certificate, thus we
should respect that, and check that iKEIntermediate is inside that
list.

So if CA wants to create certificate that can be used for any use,
just create it without extended key usage extension. If CA wants to
limit the use to only IKE and email, then it will create certificate
that contains exteneded key usage extension having emailProtection and
iKEIntermediate.

> >6.1 Signature-based authentication
> >Main Mode - Certificate Request
> >I would much prefer that we specify only which parts of the exchange where
> >it does not make sense to send these payloads rather than trying to restrict
> >where they are sent.  To me it makes perfect sense to send a cert request in
> >2(responder), 3(initiator), 4(responder) or 5(initiator).  Since after the
> >SA is agree you will know if you want a cert.
> 
> But doing so in messages 2, 3, and 4 are not described in the message 
> formats in the IKE document. The ISAKMP document says it's OK to put them 

The pictures in the IKE documents are ONLY EXAMPLES. They are not
supposed to be complete and they are much of other legal ways to put
the payloads together (Examples of this is the payload ordering and
the optional payloads (certificate, certificate request, notify etc).

> there (and in step 1, for that matter), but IKE only has slots for them in 
> 5 and 6. What you're proposing is that we change IKE. I think that's fine, 
> but we have to do it somewhere other than the PKI document.

IKE does not say that you can only have certificate payloads in
messages 5 and 6. In the examples it only shows those payloads in
those messages, because they normally appear there, but it does not
mean that it is not allowed to send them any other messages.

The only restriction IKE makes is that it does NOT allow you to send
certificate request payload in a way which would extended the
exchange, i.e. in the 6th message of main mode or in the 3rd message
of the aggressive mode. 

> >6.3 Content of Certificate payloads
> >"If a responding device is not offering a certificate that will chain to
> >the certificate authority named in the Certificate Request payload, the
> >Certificate payload offered in response to a Certificate Request
> >payload MUST specify a certificate encoding of type NONE."
> >
> >This is completely new behavior.  And not very flexible.
> 
> Disagree. Agree.

I haven't seen that kind of description before. Is somebody really
doing that?

> What you're asking for is that both sides, when given a certificate request 
> for a root that they do not know, should guess and send a bunch of certs 
> that weren't requested. There is no way for the responder to the request to 
> know whether the request might have cross-certs with any of its roots, or 
> any of its intermediate certs, for that matter. I propose that this is a 
> bad solution that will cause IKE to fail more often due to much longer 
> responses.

Usually the device has only 1 or 2 certificates for itself. If it
doesn't know how to build the chain from its certificates to the CA
the other end provided, why not send those 1 or 2 certificates to the
other end and see if he can make the chain.

There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE
notifications that can be used. 

> Your problem is real, but it is not common (one might say "extremely rare 
> except for Entrust customers"). I think what is proposed here is OK 
> *except* for the case of cross-certification, and that if we want to deal 
> with that problem, we need a solution specific to cross-certs.

No, I think sending information you have to the other end to see if he
can make sense of it, is the best way to do it. It will allow two
parties to communicate if either one of parties have extra information
that allows him to build the completele path. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


Follow-Ups: References: