[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "PKIX Profile for IKE"--Is it really a profile?
In Greg Carter's posting of 10/26/99, the following exchange
took place:
> what are the normative rules for matching a
>certificate?s subject to IKE?s ID Payload fields,
>>That's a good question. Many companies have told me that they never
>>intend to match the subject to the IKE initiator. I find that scary,
>>but it's what many people want. I would prefer statements in this
>>profile that say you SHOULD (maybe MUST) match the subject, but
>>that's open for debate.
>>>Then they don't understand the security implications
>>>and this is something that should be explained in the doc. The
>>>DOI mentions that if the ID payload is used for policy decisions
>>>then the ID SHOULD be contained in the certificate. If they use
>>>the ID in the ID payload for policy lookups but don't verify that
>>>ID than they have serious security problems. Perhaps one of the
>>>reasons this isn't pointed out is it was thought to be obvious.
>>>I can substitute any ID I want, my signature will still verify
>>>because I have sent you my cert. If they do not use the ID in
>>>the ID payload to look up policy and instead use the ID contained
>>>in the certificate then there is not a problem.
I asked the first question (>), Paul Hoffman responded (>>),
and Greg Carter (>>>) replied to Paul. I think we definitely need
explicit matching rules. But I disagree with Greg about its being OK
to make policy lookups that are not based on the contents of ID Payload.
And I'd like to see a "mismatch" rule, rather than a "match" rule as
Paul had suggested.
I believe that the ID Payload MUST be used. Here's my rationale:
1) In IKE exchanges, ID Payloads must be present, but certificate
payloads are only optionally present.
2) The IKE authentication process uses contents of the ID Payloads
as inputs to the hash that is used to authenticate the negotiating
parties.
3) Certificate subject fields play no role in authenticating the
negotiating parties.
4) Why would one authenticate two parties, and then use unauthnticated
information to look up policy? This seems to me to be a very big
security hole, which we should strongly disallow.
Also, consider a situation where the optional CERT and CERT REQ
payloads are not used. Party #1 sends Party #2 an ID payload
identifying itself as (say ) "JOE". The party #2 has to find
a certificate to learn the appropriate public key for party #1.
Would Party #2 make (for example) an LDAP query asking for
"HARRY"s certificate? Of course not, since Party #1 has just
said that he is "JOE". So, if a CERT Payload naming HARRY
is present in an exchange where the ID field names the negotiator
as "JOE", why would an implementation want to use the public key
in HARRY's certificate?
My recommendation for the "PKIX Profile for IKE" is to add text
that imposes the following "mismatch" requirement:
"If identity offered by an IKE peer in its ID Payload field
does not match in both identity type (e.g., ip address, FQDN,
etc.) and value with at least one of the identities included
in the certificate's subject field or subjAltName extension
fields, then that certificate MUST NOT be used by IKE for
the purpose of authenticating the IKE peer."
I'd also add another statement for information purposes, to
make it clear that local security polciy can include other
requirements beyond a match between certificate subjects and I
D payload contents. Perhaps something like:
"A match between ID payload contents and at least one
of the subject(s) named in a certificate is necessary if that
certificate is to be used in the IKE authentication processes.
In addition , as a matter of local security policy, an IKE
implementation MAY impose further requirements. For example,
local policy might restrict the identity formats to only IPv4
addresses, or it might require there be a match between a
domain name and the associated DNS A record, etc. The presence
or absence of any such additional checks are otuside the scope
of this profile."
"Note that this profile prohibits the use of "mismatched"
certificates as part of the IKE authentication process. It does
not constrain in any way the use of "mismatched" certificates for
other purposes."
...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