Subject: [Ietf-krb-wg] krb5starttls SAN-vs-EKU

From: Simon Josefsson <[email-masked]>
Date: Fri, 25 Sep 2009 13:38:46 +0200

There were earlier discussions around SAN vs EKU in krb5starttls but the
discussion died off.  The document was updated to clarify some aspects.
Jeff asked me to resolve this question before he can proceed with a
WGLC.  So, this is a request for text changes to the document if anyone
feels strongly about making it say anything other than what it currently
says.

I have agreed to use document status Informational because the chairs
said this would speed up publication of the document.  Some WG comments
made earlier about certificate validation may have been made under the
assumption that krb5starttls would be a standards track document.  So
please consider whether your preference also applies to an Informational
document.

I feel strongly about three aspects of certificate validation in
krb5starttls:

1) Server certificate validation must be optional, for the reasons
explained in the document.

2) There shouldn't be a normative reference to the PKINIT document.

3) If an attacker compromise the PKINIT credentials for a realm, the
credentials should not necessarily always be usable as a KRB5STARTTLS
credential, and vice versa.  The reason is that admins should be able to
setup separate PKINIT and KRB5STARTTLS front-ends to their KDCs and not
having the security of each protocol depend on the other security of the
other protocol without any way to de-couple the credentials.

Thanks,
/Simon
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 28 Sep 2009 15:34:40 -0700

I have no opinion on SAN vs EKU.

I'm pretty sure I never said anything that would depend on info- vice  
standards-track.  I also do not recall any objections that would be  
stronger for info- vice standards-track, but others are probably  
tracking that better than I am.

> explained in the document.

I think I might want it mandatory IF this were standards-track.  I  
agree with the reason given for an informational RFC.  (Did I just  
prove I can be inconsistent? ;-)

> 2) There shouldn't be a normative reference to the PKINIT document.

OK.

> other protocol without any way to de-couple the credentials.

Strongly agree, though it should also be possible to use the same  
cred's if you want.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Sep 2009 09:31:36 +0200

> tracking that better than I am.

Thanks.

> Strongly agree, though it should also be possible to use the same

Agreed, and that should be possible with the current approach: put all
the SAN/EKUs needed in the same certificate.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Sep 2009 11:59:58 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> There were earlier discussions around SAN vs EKU in krb5starttls but the
    Simon> discussion died off.  The document was updated to clarify some aspects.
    Simon> Jeff asked me to resolve this question before he can proceed with a
    Simon> WGLC.  So, this is a request for text changes to the document if anyone
    Simon> feels strongly about making it say anything other than what it currently
    Simon> says.

As I've repeatedly said--and I'm not complaining at Simon here, but
more at the fact we have not published this already (which is not his
fault), I'm happy with basically any version of starttls from the last
couple of years going forward as informational.  That's true of the
current version.

    Simon> I have agreed to use document status Informational because the chairs
    Simon> said this would speed up publication of the document.  Some WG comments
    Simon> made earlier about certificate validation may have been made under the
    Simon> assumption that krb5starttls would be a standards track document.  So
    Simon> please consider whether your preferenc
I listed things I thought needed to be fixed for the most recent
version of starttls to go to standards track.  The main item on that
list was in fact certificate validation.  My list of required changes
for informational is empty.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Sep 2009 12:55:42 -0400

--On Tuesday, September 29, 2009 11:59:58 AM -0400 Sam Hartman 
<[email-masked]> wrote:

>     Simon> I have agreed to use document status Informational because the
> chairs     Simon> said this would speed up publication of the document.
> Some WG comments     Simon> made earlier about certificate validation may
> have been made under the     Simon> assumption that krb5starttls would be
> a standards track document.  So     Simon> please consider whether your
> preferenc

*** speaking as chair...

Just to reiterate...

I believe the question of intended status is resolved.
I believe the question of what level of certificate validation is needed is 
resolved, at least as long as this is informational.
I believe the current document reflects those.

The outstanding question is the question as to whether valid certificates 
are identified as usable for krb5starttls by the presence of a particular 
SAN, or by the presence of a particular EKU.  As far as I know, that is the 
_only_ outstanding question.

I don't see a consensus on this question; in fact, the only people involved 
in the discussion to date have been Simon, Nico, and myself.  So long as 
the situation is that Simon takes one position, I and one other participant 
take another, and no one else speaks up, then I am unwilling to declare 
consensus, rough or otherwise.  If Nico and Simon can come to some 
agreement, and there are no other objections, then we can move forward on 
that basis.

If things get more complicated, then I may have to ask Larry to judge 
consensus on this particular issue (and I will do that anyway, if anyone 
thinks it's necessary).

*** speaking as an individual...

Simon says he wants it to be possible to have separate certificates for 
PKINIT and STARTTLS services for the same realm.  I still don't understand 
why, but that's not important -- I don't think anyone objects to that goal.

I want it to be possible to have a single certificate which is usable for 
both PKINIT and STARTTLS in a given realm.  I also want it to be possible 
to have a certificate which can be used for a web server but _not_ for 
PKINIT or STARTTLS service for a realm with the same name as the web server.

It is important here to understand how the EKU extension works.  The 
presence of this extension means a certificate can be used _only_ for the 
purposes listed in the extension, period.  It is primarily a mechanism to 
allow the issuer of a certificate to restrict its use to a specific set of 
purposes.  PKINIT defines an EKU for PKINIT KDC certificates, which allows 
a certificate to be restricted for use _only_ with PKINIT.

A _secondary_ use of the EKU extension is to allow particularly sensitive 
applications to accept only certificates specifically designated for use 
with that application.  PKINIT does this also, by requiring that PKINIT KDC 
certificates contain the EKU designated for that purpose, except under 
specific circumstances in which a client can choose not to enforce that 
requirement.

PKIX defines a special EKU which means "any purpose, except one which 
requires presence of a specific EKU".  This allows one to, for example, 
enable a certificate to be used with PKINIT without preventing it from 
being used for other uses.  However, this is all or nothing -- the only way 
to allow a certificate to be used for specific purposes _and no others_ is 
to list the EKU for each of the desired purposes, which requires that each 
such purpose _have_ an EKU.

The way to assert that a certificate MUST NOT be used for PKINIT is to 
include the EKU extension listing some other purpose, but not that of 
PKINIT.  This means the way to assert a certificate is usable for STARTTLS 
but MUST NOT be used for PKINIT is to include an EKU extension that 
includes an EKU for STARTTLS, but not one for PKINIT.

The way to assert that a certificate can be used for PKINIT is to include 
the EKU extension listing PKINIT.  But this prevents the certificate from 
being used for anything else, unless it also lists other purposes.

So, if we want to have a certificate that is usable for both PKINIT and 
STARTTLS, it must either include the PKINIT EKU and a STARTTLS EKU, or the 
PKINIT EKU and the any-purpose EKU.  If we want to have a certificate that 
is usable for PKINIT and STARTTLS but nothing else, it must include the 
PKINIT EKU and a STARTTLS EKU, and nothing else.

Finally, if we want to prevent web server certificates from being used for 
STARTTLS, then there must be some property which STARTTLS certificates must 
have but which web server certificates do not have.  The mechanism PKIX 
provides for this is the extended key usage extension.

FWIW, if it helps, I am certainly willing to relax the requirement in the 
same way that PKINIT does -- define an EKU which must be present in 
STARTTLS certificates, but allow the client to waive that requirement when 
it knows a priori that the certificate belongs to the KDC it is looking 
for.  This has the effect of requiring the extension when RFC5280 path 
validation happens, but not when the client has a copy of the required 
certificate in a local data store.

PKINIT actually goes a step further, which is also acceptable to me -- if 
the KDC certificate contains a KRB5PrincipalName SAN naming a TGS, then the 
EKU requirement is dropped.  Note, however, that even in this case, PKIX 
requires that, if an EKU extension _is_ present, the certificate can be 
used _only_ for the named purposes.

Comments?
Does anyone else want to speak up on this issue, so maybe we can get it 
resolved one way or the other?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Sep 2009 12:20:16 -0500

> agreement, and there are no other objections, then we can move forward on 

Thanks for summarizing this.  I forget what my earlier position was,
but it seems clear that you want to use an EKU for this, if you really
think we need to distinguish between StartTLS and PKINIT server certs.
I suspect that was my position before, therefore my position has not
changed.

> why, but that's not important -- I don't think anyone objects to that goal.

I don't think that should be necessary either, but I don't object.  The
reason it's not necessary is simple: compromise of either credential is
equally bad, and isolation doesn't seem to mitigate compromise in any
way.  Moreover, implementors/deployers that are very concerned about
securing private keys will put the private keys in hardware tokens,
which means that to compromise one key would be to compromise the token,
which would mean compromise of both keys.

Of course, the TGS key remains the most interesting key, and it does not
follow that compromise of one of the private keys will lead to TGS key
compromise, or KDB and master key compromise.  Therefore it makes a lot
of sense to implement privilege separation of most of a KDC
implementation from the parts that deal with creating Tickets and KDB
entry decryption.  But privilege separation of StartTLS and PKINIT code
makes a lot less sense.

> PKINIT or STARTTLS service for a realm with the same name as the web server.

That is my position as well.

> [EKU explanation elided.]
> 

+1

> certificate in a local data store.

+1

> used _only_ for the named purposes.

+1

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Sep 2009 13:57:47 -0400

I agree with Jeff and Nico on the EKU vs SAN issue.  I'm surprised I
never spoke up before on this: I guess I thought my point had beenmade
by others.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Sep 2009 20:13:12 +0200 (MEST)

That description is inconsisten with:

> being used for other uses.

In X.509v3 term, EKU is just another extension like certificate
policies and other crap.  Unless it is marked critical, it will get
ignored by a lot, if not most of the software.

Unless a particular application requires the use of a particular EKU,
the presence or absence of a non-critical EKU with arbitrary OIDs
is entirely irrelevant.

If there is a use that does not have a EKU defined, it will not be
affected by a non-critical EKU presence in a cert.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Sep 2009 15:32:19 -0400

--On Tuesday, September 29, 2009 08:13:12 PM +0200 Martin Rex 
<[email-masked]> wrote:

>> presence of this extension means a certificate can be used _only_ for
>> the  purposes listed in the extension, period.  It is primarily a
>> mechanism to  allow the issuer of a certificate to restrict its use to a
>> specific set of  purposes.  PKINIT defines an EKU for PKINIT KDC
>> certificates, which allows  a certificate to be restricted for use
>> _only_ with PKINIT.
>

No, it's not.  Perhaps when I wrote "PKIX", you read "PKINIT"?  But I meant 
"PKIX", aka RFC5280, which is the standard that defines the EKU extension 
and specifies its semantics.  See section 4.2.1.12 in that document.  I 
believe it is quite unambiguous on this point:

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.

It doesn't say "SHOULD", or "only if the extension is critical", or "only 
if you feel like it".  In fact, it _did_ say "If the extension is flagged 
critical", in RFC2459; that changed to "If the extension is present" in 
RFC3280.

> ignored by a lot, if not most of the software.

True.  The EKU extension is somewhat useless unless critical and signed.

> the presence or absence of a non-critical EKU with arbitrary OIDs

Not true.  A non-critical extension may be ignored _by software that 
doesn't understand it_.  Software that implements the EKU extension won't 
necessarily ignore the restriction it implies just because the extension is 
not marked critical.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Sep 2009 23:17:42 +0200 (MEST)

> critical", in RFC2459; that changed to "If the extension is present" in 

You're correct, I'm sorry for the confusion.

rfc3280/rfc5280 do in fact say that.

I can think of reasons for that change, but since the change is backwards
incompatible with rfc2459 and the underlying X.509v3 spec, it seems to
be a really dumb move to make that change and

  - NOT provide any indication of that bachwards incompatible change
  - NOT provide a rationale for the backwards incompatible change
  - NOT provide a indication what and what not older implementations
    will do instead.

in section "Extended Key Usage" (4.2.1.2 in rfc5280).

The problem with marking the extension critical is that it will
reliably prevent the entire installed base of older PKI software
from accepting such certificates and require one to update all
software prior to being able to use the feature (and mark it critical).

The now chosen approach will allow older software to continue to
run, and just silently not perform the expected EKU check.

When adding such funcationality as part of a mere software patch
to an installed base, you will have to add a switch that defaults
to the old behaviour in order not to break an installed base that
may still be running with inappropriate certificates.

Lacking the rationale, readers of the spec might get a wrong
expectation about the real prerequisites for that part of the
spec (rfc3280/rfc5280) to actually apply.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Sep 2009 16:21:26 -0500

> may still be running with inappropriate certificates.

Well, no, not if certificates are being used consistently with their
EKUs.  An update that changes validation behavior to enforce what was
once optional will then help catch misuses of certificates.

I think that would be the argument for why this was not, in fact, a
backwards-incompatible change.  It'd be the argument that I'd make to
justify such a change.

Nico

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Sep 2009 00:01:54 +0200 (MEST)

> once optional will then help catch misuses of certificates.

The concept of non-critical EKUs of rfc3280/rfc5280 is an unnatural
restriction that is not present in X.509v3.

If a software change can break an installed base that previously
worked, it can not be delivered as part of a patch, but MUST be
postponed to a software update -- that will require careful testing
before being deployed and may require administrative overhead to
fix/adjust configuration of PKI personalization that may have
been wrong from the beginning but did work anyway.

Unplanned downtimes can be VERY expensive for mission critical
software.  And re-personalizing software components with
X.509 certificates may involve a huge administrative overhead
(and sometimes require a reconfiguration of replacement of
 a companies CA software...).

The EKU MUSTs in rfc3280/rfc5280 are **MUCH** weaker than
the one in rfc-2459, which did require the extension to be
marked critical for a MUST.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Sep 2009 17:08:04 -0500

> marked critical for a MUST.

Not having been there for this change in RFC3280, I can't really say how
likely the change in question was, _back then_ to result in outages on
software updates.  Supposing that EKUs had practically zero deployment
at the time that RFC3280 was being worked on, I'd say the risk was near
zero and the change was worthwhile.  Of course, the future risk of
outage on update was always going to be related to how careful deployers
were going to be about EKU usage.  I suspect that most certs out there
still have no EKUs at all, else the anyEKU, and I suspect it was clear
that this was going to be remain the case for a long time.

But I'm supposing a lot of things, most of which I can't really know
without doing some research...  Which brings me to: RFCs 3280 and 5280
have been published, and quite a while back too, so why are we arguing
about whether this one change in RFC3280 was OK?  Why now, why here?
How is that issue remotely relevant to Simon's StartTLS proposal?

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Sep 2009 18:59:54 -0400

> about whether this one change in RFC3280 was OK?  Why now, why here?

We are not.  The change is there, it's done, over 7 years ago, by another 
working group.  The questions of whether the change should have happened, 
why, what justification should have been given, and/or what should have 
been done differently in RFC3280 are out of scope.

The fact is, krb5starttls will refer to RFC5280, and we know what that 
says.  PKINIT refers to RFC3280, and we knew what it said when we 
established the rules set down in the PKINIT specification.  Neither 
specification is unclear, and neither is in danger of experiencing 
interoperability problems due this issue.

-- Jeff