[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-pki-req-01.txt
Steve,
Thanks for your responses. My comments below.
>
> 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.
How does mandating support for a minimum of 8 root CAs help an IKE node
in being able to validate a certificate signature chain? I dont
understand the logic here.
>
> > 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.
>
Signature verification is an independent process. I dont see why you
should mandate that this be an integral part of IKE. Vendors will have
to make that choice.
FYI, Many remote access systems (not based on IPsec) today use an external
authentication mechanism. They dont have large disk space and would rather
keep the authentication intelligence in a secure, stand-alone device.
> >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.
I think we are in agreement here. Certs may be specific to IPsec. But,
that is not necessarily a requirement.
> 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.
>
Well, I dont see why EKU field should be made mandatory. What does it
matter whether the EKU field is IKEEnd or IKEIntermediate. The IPsec
SA attributes (phase II) identify whether the encapsulation mode to
be tunnel mode or a transport mode. Why should this have to be verified
as part of ISAKMP authentication?
> >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.
>
That is why the mobile user contacts the edge router and not the other
way around, I believe. Can you give me an example where an IKE initiator
does not need to know the peer's IP address, no matter what type of ID
is used to identify the peer?
> > 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.
>
Well, IDs of the peers neednt be of the same type. IKE initiator could
identify itself with X.500 DN, whereas IKE responder could identify
itself with an IP address. Right?
The only requirement is that the policy that triggers the IKE initiator
to initiate a session with IKE peer ought to be based on an ID of the peer
that translates itself into an IP address. Otherwise, the initiator
would not be able to contact the peer with just it's ID.
> > 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.
>
I dont see the need for mandating that SubjectAltName be assigned a
single value. Why do you say that issuing multiple certs, one for each
interface of a node makes it simpler? Isnt it simpler and more flexible
to allow assigning multiple SubjectAltName values? What is the complexity
you are concerned about?
> > 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.
>
I agree with your first sentence.
Section 3.3 states that this is a requirement for certificate validation
entity. Section 4.1.2 doesnt explicitly state who should do the checking.
But, I interpreted this to mean that the author is refering to the
Certtificate issuing authority (i.e., CA) here.
In any case, if the author is mandating secure-DNS and anti-spam
techniques on the CA or the verification entity, I would like to see
these or other alternate techniques stated explicitly.
> >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.
>
I would suggest including certificate signature chain validation as
a required task for a CA. It should be rather straight forward for
a CA to do this.
> >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).
>
I guess, what I am saying is that the authentication databases used for
PSK cannot be based on X.509 certificates.
> Steve
>
cheers,
suresh
References: