[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some possible discussion items on "PKI Requirements"
In reviewing the draft "PKI Requirements for IP Security" and trying to
relate
its contents to the associatedated IKE and PKI specs, I discovered several
areas that
seem unclear and/or inconsistent with other related IETF documents. Since
a discussion of digital certificates is on the agenda for next week, I'm
listing
our concerns as "food for thought"--I'm not sure myself what the best
answers are to some
of these concerns.
1. The "IPSec DOI" (RFC 2407) allows several formats for the "ID Payload"
carried
in IKE messages. However, "PKI Requirements for IP Security" permits only
three
of the formats (ipAddress, dNSName, and rFC822Name) to be carried in the
subjectAltName of the corresponding digital certificate. It further
restricts
the "ipAddress" to handle carry only single IPv4 addresses, excluding for
example
subnet addresses and IPv6 addresses.
On the other hand, the underlying PKI spec ("PKIX-1" will denote
draft-ietf-pkix-ipki-part1-09.txt, section 4.2.1.7) allows the use of IPv6
addresses
in the subjectAltName field.
This raises two questions: a) Why is the use of IPv6 addresses outlawed by
the "PKI Requirements for IPSec" document, and b) should our drafts state
explicitly that the "unmentioned" formats allowed by "DOI" for ID Payloads
can not be used in digital
certificates (these formats, from the "DOI", are ID_IPV4_ADDR_SUBNET,
ID_IPv6_ADDR, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE,
ID_KEY_ID, ID_DER_ASN1_GN,
and ID_DER_ASN1_DN).
2. I'd expect ID_DER_ASN1_DN formatted names to appear in the subject field
of the digital certificate. Yet, "PKI Requirements for IP Security" states
in
section 4.1.2 that "For IPSec devices, the actual name of the subject is
stored in the subjectAltName field"--but the format ID_DER_ASN1_DN is not
allowed by "PKI Requirements
for IP Security" to be used in the subjectAltName field. Should there be
additional text stating that when distinguished names are used to identify
the subject, they can appear
in the "subject" field of the digital certificate? Should we also add text
to state
that the subject of the certificate can appear in either the subject field
and/or the subjectAltName field, in order to be consistent with "PKIX-1"
wording in its section
4.1.2.6?
3. "PKIX-1" states in its section 4.1.2.6 that "If subject naming
information is present
only in the subjectAltName extension...then the subject name shall be an
empty sequence
and the subjectAltName extension shall be critical". "PKI Requirements for
IP Security"
states in its section 3.4.3 that "subjectName SHOULD be non-empty" and also
that "subjectAltName MAY contain a relevant and valid name". Yet in
section 3.1.1, "PKI Requirements..." says that in the certifcate request
message subjectALtName MUST be set
to an appropriate value: and that "the certificate generated by the PKI
service provider
MUST contain the subjectAltName specified and MAY NOT be changed".
This set of statements raises several questions: a) given that "PKIX-1"
explicitly allows
an empty subject field, what is the rationale for IPSec certificates to
require a non-empty one? and b) is there a recommendation as to what should
be placed in the "non-empty" subject field (since whatever it is will be
associated with the public key carried in the certificate)? and c) is the
use of subjectAltName field a "MUST", "SHOULD", or "MAY" in the context of
"PKI Requirements..."?
4. "DOI" (RFC 2407) states in its section 4.6.2.1 that "When an IKE
exchange is
authenticated using certificates (of any format), any ID's used for input
to local
policy decisions SHOULD be contained in the certificate used in the
authentication of the exchange". This wording says to me that a IKE
negotiator SHOULD check that at least
one entry in the certificate's "subject" or "subjectAltName" fields matches
the contents carried in the ID Payload of the IKE message. Yet, "PKI
Requirements..." seems to be
much more lenient, saying in its section 3.3 that "The subjectAltName MAY
be checked for consistency". However, it never explicitly states the thing
against which consistency
should be checked. Since the ID Payload is mandatory in the Phase 1 IKE
exchanges, should
we be more explicit and state that the contents of the ID Payload and at
least one of the names in the "subject" or "subjectAltName" field must
match.
5. "PKIX-1" in section 4.2.1.7 seems to imply that multiple identities can
be carried in
the subjectAltName extension. At the recent Interoperability WOrkshop, we
spoke briefly
about the possibility of IKE allowing multiple identities to be carried in
this field. Do
we intend to update "PKI Requirements" to allow mulitple identities to be
carried within a single digital certificate?
____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
TCP/IP Technology Management, JDGA/501, RTP
Phone: Tie 8-444-4142 , External 1-919-254-4142
Fax: Tie 8-444-6243, External 1-919-254-6243
VM: IBMUSM27(KUNZINGE)