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

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



(I'm adding comments to the various points here, perhaps
we should split this as the conversation continues...)

>From: suresh@livingston.com (Pyda Srisuresh)

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

The '8 roots' number came from a desire to declare we should be
building implementations that support more than one root.  I chose 8
because it seemed like a reasonable number (at least two public PKI service
providers, at least two internal CA's, double it for expansion gives 8.)

As an additional effect, if you mandate the implementation be able to
support at leat 8 signing certificates (they don't actually have to all
be roots, i.e. the tops of hierarchies), then you will have enough
(space for signing certs) to handle chains of that length.  In other words, if
you only allow one root, you'll never be able to handle any chains.

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

I believe the intent of the requirement is that the IKE component
be able to believe the signature is valid.  If the IKE component
does the crypto operations itself, that is easy.  If local crypto
assistance devices, such as the kind that provide signature checking
capabilities, then that's still "within the IKE component" for protocol
purposes.  Once you go to some other component you introduce yet another
protocol exchange, in some sense, and I don't think we want to go there...

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

>> (from Steve Kent...)

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

The idea of the EKU was that it was present, but not necessarily the ONLY
EKU OID present.  So it would identify the cert as being valid for IPSec.
Marking the cert as valid for other things (TLS, S/MIME, etc.) is certainly
intended to be allowed in the format.

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

The idea of the EKU was that the certificate would indicate whether
or not the IPSec device had been 'certified' to be used as an intermediate
node.  After all, it has the role of translating encrypted data into
clear-text data.  At the gathering in Binghampton some people didn't like
this,
'because that's policy and we're not supposed to put policy in the cert'
(I'm assuming the advocates of this viewpoint are listening)
The point here is that the certificate can be used to indicate that
this device is supposed to be doing IPSec.  You don't want your
notebook PC masquerading as a router just because it has a cert that
allows it to do IPSec.

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

DHCP.  Wandering users who change ISP's as they move from City to City.

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

Eh?  I thought the requirement was that the IKE peers have to exchange
ID's that are acceptable to the other side.  So if I want to send an
ID with a Distinguished Name to the other side, and the other side is
willing to accept that, it's fine.  No IP address checking required.

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

The responder's cert has to contain some identification information
that is acceptable to the initiator.  That may or may not be IP address.

>> >
>> >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 personally find multiple altnames in a cert to be rather ugly.  If I
have a huge router with 32 interfaces, I'd rather have one IP address
(or DNS name, or DN) be used as the identity of that device.  BUT, the
device having 32 certs (or 3200) and using different certs under
different circumstances seems completely valid to me.  I think we have
to allow the idea of one cert with 32 IP addresses in the subjectAltName
field, to handle the case where the key pair identity is really to be bound
to all 32 of those addresses as a set.



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

Parsing certs is a massive pain in the (implementation.)  Adding
more fields to the cert makes it more complicated, and I don't think it
adds value.  Processing multiple (simpler) certs seems like a better idea
to me.  Other people have other views.  That's
why both styles of formats are allowed.

We already have people complaining about how much code it takes to parse
these things in embedded devices.

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

I pulled this out of later drafts.  I don't agree, but many people
told me they didn't like the idea of having to check these things.
Allowing someone to specify a bogus DNS name, or, a name that isn't
really associated with the proper person, didn't seem right to me, but
the rough consensus is that this should not be mandated.

>
>> >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 point out I used the term "PKI Service Provider".  This may well
be some entity that provides PKIX protocols, such as OCSP, for 
certificate validity checking.  It might be a CA, it might be
something (more) than a CA.

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

Why should the CA 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).

It's _NOT_ X.509.  It's PKIX.  X.509 is a fascinating CCITT/ITU template.
We're not doing this in the ITU, we're doing this in the IETF.  Pre-shared
key (I assume PSK=Pre-shared key, our baroque way of saying "passwords")
doesn't use certificates of any form.