[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strawman Text for Section 3.5 of "IPSec/PKI Req'ts" draft
kunzinge@us.ibm.com wrote:
>
> This is the 2nd of two notes I though I sent out 2 days ago. I apologize
> if it is a duplicate.
>
> ****************************
>
> The current internet draft "PKI Requirements for IP Security"
> (draft-ietf-ipsec-pki-req-02e.txt) has a scetion 3.5 entitled "IKE
> PRocessing of Certificates", but as yet there is no text for this section.
> This contribution offers some draft text that may be appropriate for
> inclusion there. It will address issues such as: a) how does one use the
> Certifcate Request payload and the Certificate Payload in IKE, b) how does
> one do matching of IKE's Payload ID field with a certificate's subjects.
> The material here is simply one suggestion on how to handle these issues,
> and there certainly other strategies one could implement. Our goal is to
> simply offer a strawman approach for review and discussion by the IPSec
> Working Group, in the interests of reaching an informal consensus that will
> enhance the interoperability across IPSec/IKE implementations.
>
> Our strawman text for Section 3.5 is as follows:
>
> 3.5 IKE Processing of Certificates
>
> Digital certificates are used within the Internet Key Exchange (IKE)
> protocol's public-key-based Phase 1 exchange modes (Main Mode and
> Aggressive
> Mode) to validate the identities of the negotiating parties. Digital
> certificates are not used in any IKE Phase 2 exchanges, nor are they used
> in IKE's Phase 1 "preshared key" mode of authentication.
>
> Each party to the IKE negotiation MUST validate the IPSec Identification
> certificate of its peer. Then, depending on the particular method of
> authentication being used (that is, signatures or encryption), each
> party uses the other party's public key to either verify the peer's
> digital signature or decrypt the peer's encrypted data carried within the
> IKE payload.
>
> 3.5.1 Locally Stored PKI Information
>
> In order to properly handle digital certificates within the IKE flows, each
> IPSec-enabled device must:
>
> -Possess each of its own private keys and store each one securely.
> Depending on the IKE authentication modes that it supports, a device
> might have just a single "digital signature" key, a single "key
> encipherment" key, or both. Effectively, the device will need to
> securely store one private key for each digital certificate that has
> been issued to it.
>
> -Possess a copy of each of its IPSec Identification Certificate that it
> intends to use within the IKE Phase 1 negotiations. An IPSec device
> may
> have multiple digital certificates. For example, it may have obtained
> IPSec Identification certificates from multiple different CAs, or it
> may wish to support both signature-based and encryption-based modes of
> IKE authentication, thus requiring one digital certificate for each
> key usage mode.
>
> -The IPSec-device must have a copy of its certificates available to
> itself
> locally so that it can respond to any Certificate Request payloads
> that
> might occur during the IKE negotiations.
>
> -Possess a copy of a "trusted" CA Signing Certificate for each
> certification path that it may need to trace through. In general,
> the exact number of "trusted" CA Signing Certificates that an
> IPSec-capable device must store can not be specified until the
> details of the VPN (or VPNs) in which the device wishes to
> participate are known--that is, it is a matter of policy rather
> than a matter of protocol.
>
I'm not sure I agree that the above 2 paragraphs are requirements.
Imagine two devices in a corporate environment where the certificates
are available via a corporate LDAP server. Must each device obtain a
local copy
of its certificate chains, even though the device will never be responding
to a CERTREQ message?
I would be in favor of the above requirements if they were made conditional
by stating something like:
Unless an IPSec device is configured with specific knowledge that all
possible peers will never send CERTREQ messages (in other words, all
possible peers already have access to the keying materials for this
IPSec device), then....
If we state the above requirements for certificates, then I think that
a similar requirement should be stated for CRLs, something like:
Unless an is configured with specific knowledge that all
possible peers will never send CRL CERTREQ messages (in other words,
all possible peers already have access to the relevant revocation
status of the keying materials for this IPsec device), then
the IPsec device MUST have a copy of a current the CRL for
each CA Signing Certificate in all of the device's Identity
Certificate certificate chains.
> 3.5.2 How an IPSec Device Validates Its Peer's Claimed Identity
>
> Within the IKE Phase 1 message exchanges, each party announces to the other
> who it claims to be via the ID Payload in the IKE messages that it
> originates.
> The basic rule is relatively simple: the identity claimed by an
> IPSec-enabled
> device in its IKE "IP Payload" must match the subject(s) named in
> the associated IPSec Identification Certificate. If this criterion is
> not satisfied, then the certificate is not valid and theIKE negotiations
> MUST be aborted.
Failure of the identities match is an auditable event.
>
> This criterion says absolutely nothing about the contents of the IP
> header of the datagram in which the IKE messages flow. The only relevant
> information is the ID Payload field and named subject(s)in the IPSec
> Identification Certificate.
The relevant information also includes whatever is in the IPsec policy.
That is, the contents of the ID Payload (and, of course, certificate),
must be matched against the contents of the IPsec policy.
>
> The rules for determining declaring a match (or a mismatch) depend on
> the type of identity claimed in the ID Payload field. They are
> straightforward:
I'd suggest numbering these rules....
> -An ID Payload of type "IPv4 Address matches a certificate's
> subjectAltName that expresses an IPv4 address whenever the
> two IP addresses are exactly the same
I think that multiple IP addresses in SubjectAltName should be permitted.
There are cases, such as for security gateways, where a IPsec device may
have multiple "external" interfaces. I realize that the current draft
explicitly prohibits this. Perhaps this is an appropriate time to
discuss this constraint....
I propose:
3.5.2.1 An ID Payload of type "IPv4 Address" matches a certificate's
subjectAltName that expresses an IPv4 address whenever the
IPv4 address in the ID Payload is identical to any of the IP
addresses in subjectAltName.
> -An ID Payload of type "IPv6 Address" matches a certificate's
> subjectAltName that expresses an IPv6 address whenever the
> two IP addresses are exactly the same
Similarly:
3.5.2.2 An ID Payload of type "IPv6 Address" matches a certificate's
subjectAltName that expresses an IPv6 address whenever the
IPv6 address in the ID Payload is identical to any of the IP
addresses in subjectAltName.
> -An ID Payload of type "Fully Qualified Domain Name" matches a
> certificate's subjectAltName that contains an identical
> domain name. For example, if the fully qualified domain name in the
> ID Payload is "joe.raleigh.ibm.com", then the DNS name contained in
> the
> certificate's subjAltName extension must also be
> "joe.raleigh.ibm.com".
> -An ID Payload of type "User Fully Qualified Domain Name" (email
> address)
> matches a certificate's subjectAltName that contains an identical
> user name. For example, if the fully qualifed domain name in the
> ID Payload is "Joe@raleigh.ibm.com", then the DNS name contained in
> the
> must also be "joe@raleigh.ibm.com".
> -An ID Payload of type "DER-encoded ASN.1 Distinguished Name" matches
> a certificate's subject field that carries the same distinguished
> name.
Also, what about the other ID Payload types? I propose:
3.5.2.6 An ID Payload of type "DER-encoded ASN.1 GeneralName" matches a
certificate's subjectAltName whenever the GeneralName in the ID Payload
is identical to any of the GeneralNames in subjectAltName.
No other ID Payload type is to match the identity in an Identity
Certificate. Therefore, by definition, any other ID Payload type
will fail to match the certificate's subjectAltName.
>
> 3.5.3 Exchanging Certificates within the IKE Flows
>
> As an alternative to retriveing certificates from an LDAP directory using
> an "offline" process, the IKE protocols offer a way to exchange
> certificates
> "inline" during the IKE message flows using IKE's Certificate Request
> Payload and its Certificate ayload. Inclusion of a Certificate Request
> Payload in an IKE message is optional. But, if it is present, the
> recipient
> of the request MUST reply to it, using the Certificate Payload.
> To implement an "inline" exchange of certificates, the following rules are
> recommended, depending on the box's role as either IKE Initiator or IKE
> Responder:
>
> A) IKE INITIATIOR -- MAIN MODE
> 1) An IPsec device that is an IKE initiator will include
> a Certificate Payload in IKE Message 5, even if no Certificate Request
> has been received from the IKE responder. The IPSec Identification
> Certificate delivered to the IKE responder will contain the public key
> that the responder will use to verify the initiator's digital
> signature, which is also carried in IKE Message 5.
>
> 2) An IPSec device that is an IKE initiator will always include
> a Certificate Request in IKE Message 5. This assures that the
> IKE responder will deliver a suitable IPSec Identification Certificate
> to the initiator in IKE Message 6.
>
> B) IKE INITIATOR - AGGRESSIVE MODE
> 1)An IPSec device that is an IKE initiator will include a
> Certificate Payload in IKE Message 3. The IPSec Identification
> Certificate delivered to the IKE responder will contain the
> public key that the responder will use to verify the digital signature
> that the initiator includes in Message 3.
>
> 2) An IPSec device that is an IKE initiator will include a Certificate
> Request in IKE Message 1. This assures that the IKE responder will
> deliver a suitable IPSec Identification Certificate to the initiator
> in IKE Message 2.
>
> C) IKE RESPONDER - MAIN MODE
> 1) An IPSec device that is an IKE responder will include
> a Certificate Payload in IKE Message 6, even if no Certificate Request
> has been received from the IKE responder. The certificate delivered
> to the IKE initiator will be the one that carries the public key
> that the IKE initiator will use in verifying IKE responder's digital
> signature, which is also carried in IKE Message 6.
> 2) An IPSec device that is an IKE responder will always
> include a Certificate Request in IKE Message 4. This assures that the
> IKE initiator will deliver a suitable IPSec Identification Certificate
> to the responder in IKE Message 5.
>
> D) IKE RESPONDER - AGGRESSIVE MODE
> 1) An IPSec device that is an IKE responder will always include a
> Certificate Payload in IKE Message 2, even in the absence of a
> prior Certificate Request from the IKE initiator. The
> certificate delivered to the IKE initiator will be the one that
> carries the public key that the IKE initiator will use to verify
> the responder's digital signature, which is also carried in
> IKE Message 2.
> 2) An IPSec device that is an IKE responder will always include a
> Certificate Request in IKE Message 2. This assures that the IKE
> initiator will deliver a suitable IPSec Identification Certificate
> to the responder in IKE Message 3.
I think the above rules are overkill. Unfortunately, ISAKMP doesn't completely
spell out the semantics of the CERTREQ messages. I'm not sure that this draft
is the appropriate place to clarify this issue (perhaps DOI or the IKE draft
is?), but I believe the rules are thus (some of which are explicitly
stated in
ISAKMP, some of which I'm proposing):
1) If a device wants to receive keying materials from a peer, the device
MUST send a CERTREQ message. In other words, a device that does
not receive a CERTREQ message is not obligated to send any CERT
messages.
2) In response to a CERTREQ message of any of the non-X.509
certificate types,
a device MUST respond with CERT message of identical type ("cert encoding").
For all of the X.509 certificate types ("PKCS#7 wrapped X.509
cert",
"X.509 cert - signature", "X.509 cert - key exchange", and "CRL"),
a device
MAY respond with either CERT message(s) of identical type, or with
CERT message(s) of type "PKCS#7 wrapped X.509 cert". Rather than sending
multiple X.509 CERT messages, a device MAY combine the
certificates and/or
CRLs from those messages into a CERT message(s) of type "PKCS#7 wrapped
X.509 cert". Conversely, rather than sending a CERT message of type
"PKCS#7 wrapped X.509 cert" that contains multiple certs and/or
CRLs,
a device MAY send multiple CERT messages. However, a device MUST NOT
send a non-signature certificate in a "X.509 cert - signature" CERT
message and MUST NOT send a non-key-exchange certificate in a
"X.509 cert - key exchange" message. Any type of certificate
is permitted in a CERT message of type "PKCS#7 wrapped X.509 cert".
3) Devices MUST must be able to receive CERT messages in all of the
combinations implied by (2).
4) In response to a CERTREQ message of one of the X.509 "certificate"
types ("PKCS#7 wrapped X.509 cert", "X.509 cert - signature", and
"X.509 cert - key exchange"), a device SHOULD NOT send CRLs (unless
CRLs were also requested in a separate CERTREQ message).
Similarly,
in response to CERTREQ message of type CRL, a device SHOULD NOT
send certificates (unless certificates were also requested in a
separate CERTREQ message). In other words, if a device wants to
receive both certs and CRLs, the device MUST send a CERTREQ
messages
that requests certificates and another that requests CRLs.
5) In response to a CERTREQ message, a device MUST send CERT messages
for all of the keying materials (of the requested type) that
are "below" the CA that is identified in the CERTREQ message. Note,
for CRL CERTREQ messages, the CRL of the identified CA is considered
"below" that CA, as are the CRLs of all the CAs "beneath" the
identified CA.
6) As a result of (5), a device SHOULD construct a CERTREQ message by
including the identity of the "lowest" CA in the hierarchy for which
the device already has available the associated keying materials.
7) In response to a CERTREQ message that does not contain a
Certificate
Authority field, a device with multiple Identity Certificates
MAY respond with any of its identities. However, devices SHOULD
implement local heuristics to determine which identity to send,
rather than picking an identity at random. In response to
multiple, *related* CERTREQ messages (such as one requesting
certificates and one requesting CRLs), a device MUST respond
with related keying materials. That is, in this situation, it is
incorrect for a device to respond with a certificate hierarchy
of one CA but the CRL(s) from a different hierarchy.
8) A device MAY send multiple CERTREQ messages containing different
Certificate Authories in order to express that any of those CAs
is acceptable. In response to these multiple CERTREQ messages,
the device MAY respond with any local identity that matches one
of the CERTREQ messsages.
9) Devices MUST support receiving multiple CERT messages in response to
to each CERTREQ message that was sent.
10) Devices MUST support receiving CERT messages without ever having sent
a CERTREQ message.
11) Devices MAY elect not to use keying materials contained
in CERT messages, if preferable keying materials are
available to the device. For instance, the device may
already have a CRL which is newer than one that was received
from the peer.
>
> ____________________________
> Charles A Kunzinger (kunzinge@us.ibm.com)
> Network Security Product Development, Dept JEUA,, RTP
> Phone: Tie 8-444-4142 , External 1-919-254-4142
> Fax: Tie 8-444-6243, External 1-919-254-6243
References: