Subject: Re: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Jan 2006 15:08:58 -0500

It occurred to me that a couple of your comments might not have been 
answered, and I wanted to do so before we sent this document on.  I know 
Larry has responded to many of your comments which were more editorial in 
nature, and I hope you're satisfied with the result.

PKINIT-31 includes an improved introduction containing more information 
about the Kerberos protocol, including a diagram describing the basic 
exchange.  Hopefully this provides a better idea of what is going on.

It may also help to keep in mind that Kerberos is an authentication 
protocol, not an end application.  It provides a secure means for clients 
and application servers to prove their identities to each other, but does 
not make authorization or access control decisions.  In order to issue a 
Kerberos ticket, a KDC must have some way of verifying that the client 
principal name in that ticket correctly identifies the client to whom the 
ticket is being issued, but it does not make decisions about whether a 
particular client is permitted to use a particular application.

On Monday, December 12, 2005 10:15:19 PM -0800 Gregory M Lebovitz 
<[email-masked]> wrote:

>
> 3.1.1 - I'm assuming that crypto guys have already reviewed and advised
> that CTS is preferred over CBC or CTR?
>      - I assume you have a story or plan for how to make this adhere to
> the security ADs' recent mandate about cipher agility, given the horizon
> for SHA1?
>

>       - Interop Note, last sentence - for interop success, I recommend
> the SHOULD be changed to a MUST. But, if you have already hacked through
> this on the list, and this is the consensus, then just leave it.

The concern was that Kerberos implementors wanted to be able to use 
off-the-shelf CMS libraries, and were concerned that some such libraries 
could not be coerced into producing DER.  IIRC, someone came up with 
examples of libraries for which this was the case.  In any event, the issue 
of when DER would be REQUIRED and when BER would be permitted was a long 
and contentious one, which we have no desire to reopen.

> 3.2.1 - is this to be a bit-wise comparison of the entire DN in the cert
> (as opposed to some subset of DN that the kerberos system might use to
> match policy, e.g. a CN that equates to a group name, or an email address
> that is used to do a user lookup)? If so, best to explicitly state it.

I'm not sure what you're referring to here.  This section describes how to 
construct a message; there are no comparisons.

> 3.2.2, page 12, point 1 - This is a very tricky area. As it turns out, if
> you leave the text this general, you may get stuck with interop problems.

Larry commented on this, but I'll add some notes of my own.

First, note that we're not talking merely about "allowing access" here; a 
Kerberos KDC must be able to establish a mapping between the client's 
certificate and a specific Kerberos principal name, which is all that will 
be reported to application servers.  So, while making access control 
decisions based on wildcard patterns is highly useful for IKE, similar 
mechanisms are not so useful here.

Second, we expect that in most deployments, KDC's and the CA's they trust 
will be administratively fairly tightly coupled.  While it's plausible that 
KDC's will be configured to trust random client certs previously issued for 
use with other applications, I don't think that will be the common case.

Support for the KerberosPrincipalName SAN is required in all KDC's.  This 
provides a way for a CA to decide what Kerberos principal a certificate 
belongs to, eliminating the need for the KDC to do any mapping.  We allowed 
the possibility of having the KDC perform a more complex mapping based on 
policy, because it seemed likely that there would be people who wanted to 
deploy PKINIT in that way, particularly given the ways earlier versions of 
the spec have been used in Windows and PacketCable.

There was not support within the working group for mandating support for a 
specific form of mapping policy other than using a principal name provided 
in a KerberosPrincipalName SAN; in fact, folks seemed to want to leave this 
as open as possible.

>   - page 13 E/KU - ugghh. The EKU stuff can be really hard. Instead of
> trying to describe it all, I'm going to just point you to the text in our
> document about this stuff. But let me warn you, we've spent 1.5 years on
> this text, and you'll find as many PKI experts with different opinions on
> what to do with E/KU as you will find PKI experts. Good luck.
>          draft-ietf-pki4ipsec-ikecert-profile-06.txt , 4.1.3, 4.1.3.2,
> and 4.1.3.12.

Larry has already pointed out that most of the points you refer to are 
covered by 3280, and in fact, some are reiterated in PKINIT.  There is a 
fundamental difference in that while you (rightly, IMHO) recommend against 
using EKU's with IKE, we explcitly want a KDC to be able to require that a 
certificate was issued specifically for use with Kerberos, and not for 
random applications.  We feel that the nature and purpose of Kerberos 
justify this level of paranoia.

> 3.2.4 - saying "the KDC's X.509 certificate MUST be validated..." can be
> dangerous. Yes, we want to validate it in most production networks, but
> implementations almost always need to function in places where doing so
> is not convenient, e.g. trade shows, customer labs, interop tests,
> partner certification labs, etc. You may want to give implementors a hint
> that an override for validation is very helpful, and clarify that default
> behavior should be to validate.

It sounds like you're considering situations where a user might want to 
talk to an ad-hoc service set up by someone on a temporary basis.  That 
makes sense for a random application service, where you might be fine with 
skipping validation of the certificate for joes-demo-server.joe.example 
(though if you are, then why bother using PKI at all?).

Kerberos is infrastructure, not a standalone application, and a good part 
of its security depends on knowing for certain that the KDC is genuine.  I 
don't think we're interested in weakening that.

>          - re: EKU - I'm going to defer to Russ Housley and Sam on this,
> but I'm not sure in this day and age if it is better to assume you can
> use a cert offered to you during an application exchange unless the cert
> explicitly marks its applicability as limited, or if it is better to
> specify via e/ku's the finite set of uses for cert. (I believe the former
> is better for interop cert usability, but others believe the opposite).

Again, while that's true in the general case, Kerberos as an authentication 
protocol has stronger-than-usual security requirements, and we deliberately 
chose to require a KDC certificate to be specifically issued for that 
purpose.  You don't _want_ to be able to use the same certificate for a KDC 
that you use for your web server; that means whoever breaks into your web 
server with the PHP-bug-of-the-week or whatever has compromised the 
security of your entire site.

The subject of EKU handling was the subject of long and contentious 
discussion, more so for KDC certs even than for client certs, and not one 
we should be revisiting without a strong indication there is a problem.

>          - para 6 - how do you propose that one verify that the KDC
> cert's issuing CA is authorized to issue KDC certs for the target realm?
> This seems an essential point of the security model, and you offer only
> cursory recommendations. This probably ought to be a section in the
> document, not just in security considerations, no?  I think the answer
> lies back in my opening remark about the "magic wand". In reality, the
> client will likely need a configuration package which downloads and
> installs into the kerberized app the appropriate CA cert for the KDC's
> issuer. Recommend you give more concrete direction to the PKI deployer on
> this point, and keep it based in reality, not PKI "could be someday"s.

>          - 1st para on page 25 - If we expect the admins to "ensure the
> KDC certificates are only issued to KDC's and that clients can ascertain
> this using their local policy" then you need to provide direction as to
> the local policy levers and knobs that the implementors need to use so
> that orgs can ensure it. What are the configuration options that will be
> needed? Provide some best-common-practice-type information and examples
> for implementors to follow, otherwise the industry will take 5 - 7 years
> to figure it out the hard way.

These are matters of local policy, not something we can specify.  Ensuring 
that KDC certs are issued only to KDC's essentially requires that clients 
not be configured to trust CA's which cannot be expected to behave in a 
reasonable way.  The same is true for all use of certificate authorities, 
of course, but especially so in the case of CA's used to authenticate a 
authentication service.

There was considerable discussion in the WG as to how much advice to give 
to implementors, CA operators, and Kerberos operators in this area, and 
there was not support for stronger statements than what is currently in the 
document, or for describing a particular approach to this problem, aside 
from the details in appendix C on the behavior of Windows.

>          - 2nd para on pg 25, last sentence - not only "inappropriate"
> but will not conform to certain industry-mandated standards, like FIPS
> 140.

Not to mention RFC3766, to which we refer.  Do you think a stronger 
statement is needed than is currently in the document?

>          - on "return routability" - there is a way to address this.
> IKEv2 uses a cookie mechanism in message 2. The responder signals to the
> initiator to essentially resend the stuff that was sent in the first
> message so that responder (a) doesn't have to keep state on first, and
> possiblly forged, packets, and (b) so that the initiator has to be able
> to receive, process and respond to a message, thus provining itself
> reachable, and not a spoofed address. Would you guys want to consider
> plugging this vulnerability at this late stage with a like mechanism?

I'm not sure how, in that model, the responder doesn't have to keep state 
on the first message so that it knows the second message is in fact part of 
the same transaction.  Kerberos KDC's are generally stateless, and normal 
transactions involve only a single round trip.

I think return routatbility testing is something we could consider adding 
to Kerberos, but it would have to be done in a backward-compatible way, and 
I think it's far too late to introduce a requirement that all PKINIT 
clients support some newly-defined return-routability test mechanism.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Jan 2006 17:06:26 -0500

[ Note:  The document we're discussing is one we've asked Sam to take
  to the IESG.  Last I checked, he was still evaluating it.  However,
  that does not mean we can't continue to discuss these issues and get
  them resolved.  -- Jeff]

On Wednesday, January 18, 2006 09:06:16 AM -0800 Gregory M Lebovitz 
<[email-masked]> wrote:

> IMHO, the more access control and auth you can put into the
> app, and the less you rely on the PKI to do that for you, the more
> control you have over speed, quality and  thoroughness of implementation.

Entirely agree.  It is a key part of the philosophy of Kerberos that the 
authentication system should be responsible for authentication only, and 
leave authorization decisions to individual applications.

>>> the security ADs' recent mandate about cipher agility, given the horizon

I meant to reply to this before, but skipped past and forgot to go back.
We do in fact have a plan for negotiating the use of other hash algorithms, 
and though it is not yet on our charter, I would expect to see an update 
document in the near future which specifies the negotiation mechanism and 
adds SHA-256 as a supported hash.

>>> match policy, e.g. a CN that equates to a group name, or an email
>>> address that is used to do a user lookup)? If so, best to explicitly
>>> state it.
>>
>> I'm not sure what you're referring to here.  This section describes how
>> to  construct a message; there are no comparisons.
>
> here is the text:
>
>   -- The information contained in the
>                     -- trustedCertifiers SHOULD be used by the KDC as
>                     -- hints to guide its selection of an appropriate
>                     -- certificate chain to return to the client.
>
> What information are you referring to here that should be used as
> "hints"? What attributes or portions do you look at to do a local policy
> lookup in the KDC?

trustedCertifiers is the client's indication to the KDC of what certifiers 
are trusted by the client; it's a list of DN's issuerAndSerial, and/or key 
identifiers of signers the client trusts.  The idea is to help a KDC that 
has multiple certificates to pick one that the client will actually be able 
to verify.

>>> 3.2.2, page 12, point 1 - This is a very tricky area. As it turns out,
>>> if you leave the text this general, you may get stuck with interop
>>> problems.
>>
>> First, note that we're not talking merely about "allowing access" here;
>> a  Kerberos KDC must be able to establish a mapping between the client's
>> certificate and a specific Kerberos principal name,
>
> What in the client's certifcate exactly will the application parse out
> and use as a string to compare against a Kerberos principal name? Is
> there a Kerberos principal name attribute in the cert? If not what
> attribute specifically should that app look at to compare?

PKINIT is used only to obtain Kerberos TGT's, which are used to obtain 
other tickets from the KDC's.  Applications never see the certificate; they 
see a Kerberos principal name.

PKINIT clients tell the KDC what principal name they want to be, and the 
KDC issues a ticket only if the request matches the cert.  There was some 
discussion of allowing the client to omit the principal name, such that the 
KDC would derive one entirely from the certificate, but we ended up 
deciding that was too complicated to specify.

A client's certificate can contain a KerberosPrincipalName SAN, which is a 
principal name.  Note that principal names are not simple strings, but a 
collection of components.

If a client certificate does not contain such a SAN, then the determination 
as to what principal name can be used is entirely up to KDC policy.  There 
was some discussion of specifying alternate mapping policies, but we were 
unable to reach consensus on one.

I understand your concern, I think, but I'm not sure what to do about it.
You said this sounds similar to discussions IKE had years ago.  How did 
that turn out?  It seems to me like our choices are either to spend another 
several months arguing about name mapping policy or leave it open and wait 
to see what the market does.  If there's another choice, I'd like to hear 
about it...

>> That makes sense for a random application service, where you might be
>> fine  with skipping validation of the certificate for
>> joes-demo-server.joe.example (though if you are, then why bother using
>> PKI  at all?).
>
> maybe you are in a stage of the deployment where you haven't bolted on
> the CA yet? Or maybe you are trying to prove a specific portion of the
> system in isloation, reducing total variables at play, etc.

OK.  I think giving the client a copy of the KDC's self-signed certificate 
take care of that class of uses.  In fact, I wouldn't be surprised to see 
that method used in production.  It's not ideal, but a lot of operators 
won't see much point to creating a CA that's only ever going to issue one 
cert.

>> Kerberos is infrastructure, not a standalone application, and a good
>> part  of its security depends on knowing for certain that the KDC is
>> genuine.  I  don't think we're interested in weakening that.
>
> Giving people an option is not weakening it. From lots of experience with
> this stuff in the field, QA lab, certification labs, magazine tests,
> demos, etc. I'm STRONGLY ENCOURAGING you to leverage my scars. The
> end-production-network is a last stage in the whole
> dev/marketing/sales/implementation cycle. You (and all the support and
> SEs and app engineers and marketers, etc.) will wish in those instances
> that you had the flexibility.

I see your point, and if the WG wants to change MUST to SHOULD here, I 
won't object.  My concern is that we'll get into the situation we have 
today with the WWW, where if a certificate doesn't validate the client will 
pop up a dialog box and the user will say "yeah, sure, whatever".  Or 
worse, the situation we have with email applications, which frequently 
don't bother to validate certificates at all.

>>> issuer. Recommend you give more concrete direction to the PKI deployer
>>> on this point, and keep it based in reality, not PKI "could be
>>> someday"s.
>>
>> These are matters of local policy, not something we can specify.
>
> You don't specify the policy, you specify the fields that each side MUST
> support (conservative in what you send and liberal in what you can
> receive) in order to accomplish the range of policies that you foresee
> people wanting to locally specify. See the difference?
>
>> Ensuring that KDC certs are issued only to KDC's essentially requires
>> that  clients not be configured to trust CA's which cannot be expected
>> to behave  in a reasonable way.  The same is true for all use of
>> certificate  authorities, of course, but especially so in the case of
>> CA's used to  authenticate a authentication service.
>>
>> There was considerable discussion in the WG as to how much advice to
>> give  to implementors, CA operators, and Kerberos operators in this
>> area, and  there was not support for stronger statements than what is
>> currently in  the document, or for describing a particular approach to
>> this problem,  aside from the details in appendix C on the behavior of
>> Windows.
>
> Advice on WHAT POLICY TO BUILD is very different than specifying the
> TOOLS that must be present in an implementation by which users build
> policies that can interoperate. Example: is policy says:
>    FIELD_A must contain STRING_A
>          AND
>    FIELD_S must contain STRING_S
>
> but implementation 2 does not contain the ability to configure a policy
> with FIELD_S then you are hosed. You need to specify clearly which POLICY
> BUILDING BLOCKS MUST be supported to sending and receiving.
>
> Is this more clear?

I'm not sure, but I think we might be talking past each other here.
What I think the text is trying to say is basically "CA's shouldn't issue 
KDC certificates to people who aren't KDC's, and clients shouldn't use CA's 
that do as trust anchors".

In the deployments I'm familiar with, a verifier's trust anchors are set 
explicitly, rather than based on rules, and a CA's policies about who it 
will issue certificates to, especially for a rule like "don't issue KDC 
certs to people who aren't KDC's", are implemented largely by humans rather 
than machines.

So while I can believe there is something missing, I don't understand what 
it is...

> Yes, that's what I meant. Be supper explicit so people know how important
> it is.

OK.  Someone want to propose text?

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 19 Jan 2006 01:17:17 -0500

> OK.  Someone want to propose text?

How about?

"Using such keys to wrap data encrypted under stronger conventional
cryptosystems does not conform to the best current practices outlined
in RFC3766."

Jeffrey Altman

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 02:03:09 -0800

Jeffrey Altman wrote:

First, I do not understand why it is inappropriate to wrap data
encrypted in stronger symmetric keys, it is no worse than sending it in
clear, right?

Secondly, RFC3766 does not say it is inappropriate to protect strong
symmetric keys with weak public keys, it just says the overall strength
of the system is no stronger than the weakest keys.

Thirdly I dislike the word "conventional".

So how about "When using such weak asymmetric keys to protect/exchange
stronger symmetric
Keys, the attack resistant strength of the overall system is no better
than that of these weak keys [RFC3276]."

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Wednesday, January 18, 2006 10:17 PM
To: Jeffrey Hutzelman
Cc: Gregory M Lebovitz; Liqiang(Larry) Zhu; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Sam Hartman
Subject: Re: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

Jeffrey Hutzelman wrote:

>>>> but will not conform to certain industry-mandated standards, like 
>>>> FIPS 140.
>>>
>> Yes, that's what I meant. Be supper explicit so people know how 
>> important it is.
> 

How about?

"Using such keys to wrap data encrypted under stronger conventional
cryptosystems does not conform to the best current practices outlined in
RFC3766."

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 15:24:44 -0500

> of the system is no stronger than the weakest keys.

True and true.  I'm not sure, but I think what Gregory was going for here 
was a reference to FIPS 140; we already have an RFC3766 reference.

> Thirdly I dislike the word "conventional".

Me too; 'symmetric' is better.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 12:29:43 -0800

Jeffrey Hutzelman wrote:
> but I think what Gregory was going for here was a reference to FIPS
140; we already have an RFC3766 reference.

Greg can you provide the specific text in FIPS 140?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Monday, January 23, 2006 12:25 PM
To: Liqiang(Larry) Zhu; Jeffrey Altman
Cc: Gregory M Lebovitz; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Sam Hartman
Subject: RE: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

On Monday, January 23, 2006 02:03:09 AM -0800 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> encrypted in stronger symmetric keys, it is no worse than sending it 
> in clear, right?
>
> symmetric keys with weak public keys, it just says the overall 
> strength of the system is no stronger than the weakest keys.

True and true.  I'm not sure, but I think what Gregory was going for
here was a reference to FIPS 140; we already have an RFC3766 reference.