[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEV2: Issue #4 Revised Identity
On Wed, 12 Feb 2003, Theodore Ts'o wrote:
: > The revised identity can solve the problem of defining what the ID
: > actually is and when not to send certificates.
:
: Well, the revised identity draft does solve the problem, essentially
: be eliminating the ID and CERT payloads altogether, conflating the
: IKEv1 concept of identity and certificate, and instead always
: requiring both sides to send a certificate, which *is* the identity.
:
The revised identity draft effectively creates same payloads but named
differently. We already have those but only their definition has been
sloppy. It would seem simple to just fix where we have gone wrong instead
of replacing them. I know what I wrote is much the same pki-profile has,
except for the specific points I tried to make:
: 3.3.8.1. Specifying Certificate Authorities
: Upon receipt of a CERTREQ where the Certificate Type is either "X.509
: Certificate - Signature" or "X.509 Certificate - Key Exchange",
: implementations MUST respond by sending each certificate in the chain
: from the end entity certificate to the certificate whose Issuer Name
: matches the name specified in the Certificate Authority field. Imple-
: mentations MAY send other certificates from the chain.
:
: The IKEv1 interoperability problems arose because IKEv1 underspecified
: how the payloads should be used.
:
If the CA in CR is wrong, then it's probable that implementation will not
reply with any cert. If you have never connected with remote, don't know
who it trusts, and only thing you want is to just probe (or connect
opportunisticly) to get the remote's cert so that you can make the
decision whether you trust it or not (say, ask it from user), would not
work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty
CR.
For IKEv1 we agreed several times over the years that receiving empty CR
means sending all your local certs, or what ever your local policy happens
to dictate. This is very good since it allows to get remote's certificate
regardless whether or not you know who it trusts, but the problem was that
it was never written down anywhere. I'd like very much to see the MUST
NOT lifted from IKEv2 and specify that if empty CR is received the
receiver SHOULD send local cert(s). The section 3.3.8.2 in pki-profile
"maybe or maybe not" allows this with "non-conformant" implementations.
I think it should be either it's not allowed or it's allowed and it's
correct behavior. Now it's like, "ok, you can't really do this, but, hey
if you do it work with it anyway"...
The second point was the ability to check whether cached cert is correct
or not. This is very simple to do just by allowing the CR payload (by
adding new cert encoding type) to have the cert information (subject,
hash, what ever) in the CR data. OTOH, same feature could work with
revised identity draft too (in either TrustedRoot or IDAccepted)...
Pekka
___________________________________________________________________________
Pekka Riikonen | Email: priikone@iki.fi
SILC - http://silcnet.org/ | http://iki.fi/priikone/
Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio
PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc