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

Re: Comments on draft-ietf-ipsec-pki-req-01.txt



Pyda ,

>
>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?

It's not that simple. This aspect of the proposal focuses on how many root
CAs are supported.  One might reduce this to one with appropriate use of
locally generated cross certs, but for now this represents an easy way for
folks to think about how to support multiple top level CAs.

>   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.

I disagree.  Adding another component to the system creates another failure
point.  IPsec is a realtime communication security technology that ought to
minimize its dependence on additional servers, etc., so as to reduce the
likelihood that a DoS attack on these servers can deny service for the
users of IPsec. This is one of the motivations for IKE to support exchange
of certs and CRLs.

>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?

Certs for use with IPsec ought to match the name spaces in which we perform
access control, since the primary use of authentication here is as an input
to access control.  Thus certs with IP addresses, DNS names, and RFC 822
names are especially appropriate.  This may well mean that certs are
specific to an application like IPsec, though that is not necessarily true.
Also, certs in IKE are used only for auth, not key exchange,
non-repudiation, etc., which may mean that the key usage fields would be
inconsistent with other apps.

>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.

Sometimes ID forms other than an Ip address are appropriate, depending on
context.  For example, an IP address may not be very useful as a means to
identify a mobile user who has been assigned a temporary address.

>   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.

Both peers want to verify the others' ID.  Not sure why you state this in
an aysmmetric fashion.  IPsec is not a client/server protocol, like SSL.

>   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.

It becomes confusing when we have multiple altnames in a cert, e.g., when
dealing with name constraints.  why would we need to assign multiple IP
addresses in a single cert?  a router has multiple addresses, but it can
have one cert per interface; certs can be cheap in this context. if we can
keep this simple for now, let's do it.

>   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?

It is always the responsibility of a CA to verify ANY name form it puts in
certificate.  But, is that the context of this requirement?  I don't have
the doc in front of me right now.

>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?

CA's do not normally perform this service; it is not part of the definition
of a CA.  However, I would suggest that retrieval should specifiy the use
of PKIX cert management protocols, if we can wait for these to be finalized.

>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.

What?  I was assuming that we were talking about X.509 certs here, since
this is an IETF standards activity and for now, the only cert types being
standardized by the IETF are X.509 (SPKI having passed on).  X.509 certs
contain public keys, if they contain keys at all (X.509 attribute certs are
linked to public key certs and the former do not contain keys).

Steve


Follow-Ups: