[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"PKIX Profile for IKE"--Is it really a profile?
Comments below apply to draft-ietf-ipsec-pki-req-03.txt,
"A PKIX Profile for IKE".
1. This draft's purpose is to provide a definitive profile
for a specific way that IKE and PKIX will interoperate. We need
a clear statement that defines what it means to comply with this
draft, versus what it means to comply with the underlying IPSec
and PKIX documents.
Suggested text to accomplish this would go in a "Requirements
Terminology" section which would say:
"The key words "MUST", "SHALL", REQUIRED", SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119."
"This document defines a particular method of using IKE which is more
restrictive than is necessary for compliance with RFC 2459, RFC 2408
and RFC 2409. It defines a PKIX profile that is more restrictive
than is necessary for compliance with RFC 2459. Additional requirements
levied in this document apply only to implementations that wish to
claim compliance with the profile described in this document. It is
possible for an implementation comply with RFC 2408 and RFC 2409, but
not comply with this document. Similarly, it is possible for a PKI
implementation to comply with RFC 2459 but not comply with this
document. An implementation is said to "comply" with the profile given
in this document when it satisfies all mandatory requirements ("MUST"
and "MUST NOT") enumerated in this document."
2. The current draft offers no definitive, unambiguous requirements
for the profile. In general, it concentrates on high level statements
of what MUST or MUST NOT be done, but it offers no detailed methods for
accomplishing these tasks. In reviewing this document, I find that
there are only 6 ?MUSTs? (summarized below), and that none of them
nail down any details. Without details, we have no stake in the
ground on which to base interoperability claims.
The current "MUSTs" are:
· MUST check revocation status of certificates on
which an IKE implementation relies
· MUST have a method for receiving up-to-date revocation information
· MUST support a signing hierarchy
· MUST delete SAs corresponding to certificates that have become invalid
· EKU MUST contain only object identifier iKEIntermedate
· MUST examine notAfter time in certificates
Note also that some of the important details about the operation of IKE
are not addressed in this profile, even though in many cases the existing
IKE specs leave the details open to interpretation. For example,
there is no normative text to outline a profile-specific
method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST
payloads, there is no normative text to describe certificate
validation in IKE (e.g., what if an evaluating system does not trust
its peer's root CA, what are the normative rules for matching a
certificate?s subject to IKE?s ID Payload fields, can a given IKE
implementation recognize more than one root CA, what validation steps
are needed for CA certificates of CAs located on a certification
chain, can there be multiple certification chains between an end
entity and its root CA(s), , etc.
In the interest of having focused discussions, I will separately post
suggested text that will address some of these issues.
...Charlie Kunzinger
____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
Network Security Product Development (JEUA/502), RTP
Phone: Tie 8-444-4142 , External 919-254-4142
Fax: Tie 8-441-7288, External 919-543-7288
Follow-Ups: