[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Strawman Text for Section 3.5 of "IPSec/PKI Req'ts" draft
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.
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.
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 rules for determining declaring a match (or a mismatch) depend on
the type of identity claimed in the ID Payload field. They are
straightforward:
-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
-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
-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.
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.
____________________________
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
Follow-Ups: