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

ikev2-13 CERTREQ processing still needs work

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are two problems described in this mail:

1. security problem. The current text wording "MUST" allows a
malicious responder to "bleed" certs from the initiator by including
many CERTREQ payloads or different CERTREQ payloads. This should not
be allowed.

2. operational problem or rather an IKE interop problem with properly
deployed PKIs. The current text "MUST" does not support successful
negotiation under a variety of PKI trust topologies and policy
systems, namely those involving cross-certification, and where
certificate types are needed to authorize or will successfully chain
only for specific purposes. I think the intent though is to support
cases where authentication can succeed if possible.

Current Text:

"If a certificate exists which satisfies the criteria specified in
the Certificate Request Payload, the certificate MUST be sent back to
the certificate requestor. If no certificates exist then the
Certificate Request Payload is ignored. This is not an error
condition of the protocol. There may be cases where there is a
preferred CA, but an alternate might be acceptable (perhaps after
prompting a human operator)."


       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni   -->

                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]


1. Security: Clearly the initiator is disadvantaged by the current
MUST which requires it to provide any cert the unauthenticated
responder requests. The initiator's local policy governing the
initiation, if specified, should be considered authoritative for what
certs can be provided, not the CERTREQ. For example, why should a web
search site be able to get my bank certificate ?

2. Operationally, requesting the right thing (what to accept) and
selecting the right thing (what to offer) are independent decisions
and necessarily complicated because PKI is complicated. They are
independent because PKI trust may be deployed to succeed in one
direction (I trust you) and fail in the other (you don't trust me),
or to be broad in one direction (I trust many) and narrow in the
other (I only trust a few). In fact, the CERTREQ payload definition
itself needs to be changed to allow it to be more specific in what it
can request. Why should you fail a negotiation when there exist certs
that you could have selected if you only knew to look for those types
? If we ignore this issue, vendors will both have problems with RFC
compliant interop (or solve it with vendor ID enabled behaviors), and
limit the compatible PKI topologies and cert types useful for IKEv2.
My experience says that customers will not re-architect their PKIs
just to accommodate a short-sighted specification of cert processing
in IKE. Their PKIs are already used for many other purposes. Vendors
will have to make the changes in their IKE products to accommodate
full and proper PKIX PKI deployments at their customers, as well as
probably deal with inappropriately deployed PKIs. But we can't do
much about the latter.

This current text below is a recipe for more cert interop nightmares
for vendors who want to support the new cert types:

"values other than certificates are defined in a "Certificate"
   payload and requests for those values can be present in a
Certificate
   Request Payload. The syntax of the Certificate Request payload in
   such cases is not defined in this document"

Assuming there were really good reasons to include those cert types,
let's not make it any harder to use them.


Proposed text, fixing security and operation problems above:

"If an end-entity certificate exists which satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if:
- - the recipient of the CRP is configured to use certificate
authentication, and
- - the recipient is allowed to send a CERT payload, and
- - the recipient has matching CA trust policy governing the current
negotiation, and
- - has at least one time-wise and usage appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.

Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic. The
intent is not to prevent communication through the strict adherence
of selection of a certificate based on CERTREQ, when an alternate
certificate could be selected by the sender which would still enable
the recipient to successfully validate and trust it through trust
conveyed by cross-certification, CTLs or other out-of-band configured
means. Thus the processing of a CERTREQ CA name should be seen as a
suggestion for a certificate to select, not a mandated one. If no
certificates exist then the CERTREQ is ignored. This is not an error
condition of the protocol. There may be cases where there is a
preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator)."

More generally, the Security Considerations section needs to address
what the malicious initiator can discover about the responder.
Likewise, what a malicious responder can discover about the
initiator.

The specification of how to construct a CERTREQ for each of the
supported cert types needs to be done. I'll save space here and not
do it.

As a detailed reference, see the implemented behavior of Windows
Server 2003 certificate selection and acceptance logic found in
section "General certificate authentication considerations" in
Chapter 6 Deploying IPsec of the Windows Server 2003 Deployment Kit:

http://www.microsoft.com/downloads/details.aspx?FamilyID=d91065ee-e618
- -4810-a036-de633f79872e

cheers,
Wm

V6 Security, Inc.
http://www.v6security.com

This message is provided "AS IS" without any warranty express or
implied as to it's accuracy or fitness for a particular purpose.


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQG0F1XeaysMUl8VcEQJIHQCg0WJeiMD8bJlGXEJXV+u66wGKEy4AnArA
KWIGYi772QaSu6AObGRUsUl9
=jhBh
-----END PGP SIGNATURE-----