[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-ipsec-pki-req-01.txt
Rodney,
Had a chance to review your draft. Nice and informative. Below are a
few comments on the draft.
1. Certificate verification storage requirements
In section 2.2, you say the IPsec device MUST support at least 8
signing certificates. Is the requirement necessary? Either you
know to verify the signature or you dont. How does the number 8
help?
Also, I believe, you neednt make the assumption that the IPSec
device (that supports IKE) MUST do the signature verification by
itself. It might take recourse of a CA to do the signature
verification. Then, it becomes the head-ache of the CA to verify
the entire certificate chain.
2. EKU field requirement
In section 3.1.1, you state that an EKU entry MUST be set to
IKEEnd or IKEIntermidate. Later on, in section 3.4.3, you say
this field should be validated, if present. Likewise, in section
4.3 you make requirement for this field, a SHOULD. Clearly, these
seem like inconsistencies in the draft.
Personally, I dont see a reason for requiring this.
Why should you have to create a cert just for IPsec? Are you
saying that a certificate created otherwise (for use originally
in non-IPsec applications) may not be valid for use by IPsec in
some circumstances? How so?
3. SubjectAltName field requirement.
In section 3.1.1, you say this is a MUST. Section 3.4.3 states this
as a MAY. Section 4.0 (first paragraph) states this field as a
required field for IPsec. Section 4.2 states that a Certificate
request SHOULD contain this field. Once again, inconsistencies in
the requirement terminology.
Personally, I think, this is a SHOULD requirement, not a MUST.
Here's why.
An IKE initiator should be able to obtain peer's IP address from the
certificate, in order to initiate a session. Clealry, SubjectAltName
field in the cert (with an IP address value) is a requirement here.
On the other hand, IKE responder needs to verify its peers's ID
by retrieving a certificate of the peer and validating its authenticity.
This time, however, the requirement is simply for a certificate that
mateches the peer's ID. If the peer's ID happened to be an X.500 DN,
which is the SubjectNAme of Certificate, thats all that is needed.
Nothing else is required in SubjectAltName field.
In other words, IKE initiator requires the peer's Cert to contain
SubjctAltName (peer's IP address, really), whereas the responder
does not require this always.
5. SubjectAltName values
In Section 4.1.2, you state that this field should contain exactly
one of IP address or DNS-Name or RFC-822 name. What is the problem
in assigning multiple of these values? You will need to assign
multiple values, many times. Example: a FQDN-name and an IP address,
possibly multiple IP addresses.
Also, you state that the DNS-name and RFC-822 names must be checked
for their validity. Who should do this? Is this the PKI service
provider who is issuing the Certificate? If so, are you suggesting
that a secure-DNS and/or Spam-detection techniques are requirements
for the CA?
6. Retrieval of a Certificate from PKI service provider
(Section 3.2)
There is no recommendation of a protocol or an automated
means to retrieve certificates from CA. Also, Is there is a way to
request a CA to validate a certificate signature chain?
7. Definition of "IPsec Usage Certificate"
In section 4.3, your definition of "IPsec Usage certificate" mandates
a public key component in a certificate. Are you saying certificates
are not an appropriate infrastructure for PSK based IKE authentication?
In a PSK based authentication, IKE responder might try to authenticate
initiator's ID, by contacting a CA to obtain initiator's certificate.
However, only a pre-shared key (not a public key) is required in the
certificate.
Thanks. Have a nice day.
cheers,
suresh