Subject: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman

From: Rick van Rein <[email-masked]>
Date: Sat, 11 Oct 2014 21:30:16 +0200

Hello,

I just posted a new I-D that introduces a DH subkey mechanism for Kerberos.
 * This enables Forward Secrecy between principals, and breaks the KDC’s decryption ability.
 * An upcoming I-D will use Kerberos5 for mutual auth, and DH for encryption, of TLS connection.
 * This work helps to reduce / bypass the need for replay caches.

The I-D text on the IETF datatracker:
   https://datatracker.ietf.org/doc/draft-vanrein-krb5-kdh/?include_text=1

Your expert feedback on this proposal is kindly appreciated.
It is available for adoption by Kitten, if so desired.

Cheers,

Rick van Rein
OpenFortress / InternetWide.org

---

From: Greg Hudson <[email-masked]>
Date: Fri, 17 Oct 2014 12:18:51 -0400

> I just posted a new I-D that introduces a DH subkey mechanism for Kerberos.

The MIT krb5 team has a strong interest in perfect forward secrecy
extensions for Kerberos, as well as paths away from the replay cache.
Here are my comments on this draft:

* This design uses new enctypes so that the subkey field of the AP-REQ
and AP-REP can be repurposed for DH negotiation.  This approach requires
the KDC to keep track of which servers support the new feature, and
makes secure opportunistic negotiation of DH impossible.  An alternative
design would use authorization data for the DH parameters--see RFC 4537
for an analog.  We might still want a ticket option as a hint, since
client implementations might be reluctant to add DH parameters to every
AP-REQ.  This design change also removes the need to abuse the RFC 3961
enctype number space, but might have a negative impact on the path away
from the replay cache.

* DH parameter negotiation as described in section 4.2 does not seem
workable.  The AP-REQ/AP-REP exchange does not allow multiple round trips.

* Derivation of the RFC 3961 key from the DH value seems unspecified.
PKINIT has to deal with this, so we shouldn't have to reinvent the wheel
(unless the PKINIT methodology doesn't work with ECDH for some reason).

* The draft uses a hybrid of ASN.1 and RFC 5246 notation for its formal
type specifications.  If we want to use TLS representations of DH
parameters, we should stick to its notation completely.  PKINIT uses
ASN.1 and CMS representations instead; for the moment I will reserve
judgment on which approach would be easier to implement.

* Section 5 says "When requesting a principal ticket, a supporting
implementation SHOULD send an KDC-REQ message including the have-kdh
ticket flag."  KDC-REQ messages do not contain ticket flags; they
contain KDC options, which are not protected in AS-REQs.  I see no
reason why the client should need to indicate support for DH for the KDC
to set the ticket flag, and what you describe here allows a trivial
downgrade attack against the AS exchange.  Editorially, the phrase
"principal ticket" does not mean anything to me, and this whole
discussion seems out of place in a section titled "Impact on GSS-API".

* Is there a compelling reason to specify DH as well as ECDH, or would
it be better to just specify ECDH?  My preference is to specify only ECDH.

* Is it better to allow the client to propose a wide range of ECDH
parameters, or only a specific narrow set?  My initial preference is to
allow only a narrow set, but I don't have a lot of implementation
experience backing that up.  I also don't know the current state of CFRG
recommendations on ECDH.

Editorial review is likely premature at this point, but I did notice the
following:

* "usecases" -> use cases
* "scenario's" -> scenarios
* "A new ticket flag signals if" -> whether
* "may include an optional subkey field" -> may include a subkey
* "To setup" -> set up
* "replay buffer" -> replay cache
* jeapourdise -> jeopardize (or jeopardise if this is UK English)
* inasfar -> insofar

---

From: Rick van Rein <[email-masked]>
Date: Mon, 20 Oct 2014 15:32:44 +0200

Hello Greg,

Thank you very much for your detailed feedback.  I agree with most, but
a few of your remarks are not immediately clear.

> and AP-REP can be repurposed for DH negotiation.

This is a surprise — you probably view my use of the subkey field as a
protocol squeezed into it, whereas I see it as (half) a key traveling in the
one field that seems to be destined for that purpose.  Am I wrong, or just
looking at the same thing in a different manner?

> This approach requires
> makes secure opportunistic negotiation of DH impossible.

Opportunism is possible; a client can just send an attempt and hope for
the best; but a MITM may reject it and cause the client to downgrade to
skip its PFS desire.  The have-kdh flag exists, and is stored along with
other ticket policy settings, to indicate that such a downgrade indicates
a problem.

I am open to suggestions to approach this in another way.  As long as
a MITM between client and server is not able to suppress PFS.

> An alternative

So, you are proposing to use the authorization-data as a generic “typed hole” ,
and ignore the name and descriptions that hint towards other uses.  I suppose
this largely depends on the view whether the proposal abuses the subkey field.

But I don’t see how this could work; authorization-data is part of the enc-part,
which is encrypted in a key known to KDC and the endpoint for which the
ticket is destined.  So it would not be possible for the client and service to
create a DH-based key between the two of them.

The subkey is located in the Authenticator, which is constructed by the client
and the service as part of the AP-REQ and AP-REP messaging.  This means
that a subkey may be set by these parties, without involving the KDC, and
that is the distribution of decryption power that I am hoping to establish.

Don’t hesitate to correct me if my reading of the specs is wrong!

> workable.  The AP-REQ/AP-REP exchange does not allow multiple round trips.

I didn’t realise.  Negotiation is a luxoury item, so it is no problem to remove
it.  TLS can do without it, so there ought to be no real inconvenience.

> (unless the PKINIT methodology doesn't work with ECDH for some reason).

Indeed.  I am still in the conceptual phase :) but will add this of course.
I agree that PKINIT is a good source for reuse.

> judgment on which approach would be easier to implement.

Yes; you caught the traces from my learning process, which started out from
the intention to create a TLS-KDH mode, and which made it logical to do
a similar thing in Kerberos itself.  In retrospect, I agree that this is not the
best description.  And, since TLS already has to deal with both
syntaxes / representations, that has no decisive impact; ASN.1 is probably
a good form for this indeed, as it overlaps Kerberos5 and TLS.  My one
concern is that all the private key variables that are available to both
Kerberos5 and TLS will be present.  I shall fix this.

> downgrade attack against the AS exchange.

I think I read that the KDC will never return flags that were not requested
as flags / options in the request.  Are you saying that the KDC should be
specified to always set the have-kdh ticket flag for supporting principals,
without being asked for it?

> Editorially, the phrase
> discussion seems out of place in a section titled "Impact on GSS-API”.

OK.

> it be better to just specify ECDH?  My preference is to specify only ECDH.

Hardly — I’m only trying to not force a decision.  If most of us want to
drop “Primal” DH then I’d love to go that way.

Playing around on keylength.com, the RFC 3766 requirements demand
256 bit sym.keys to be matched by 15489 bit Primal DH keys (other estimations
require 3000-ish bits).  I’m fairly certain nobody wants to send such keys
from their software.

Mind you, this is for protection up to the year 2245, which we’re not yet
zooming in on.  But if nobody pleas for Primal DH, then I agree it can go.

> experience backing that up.  I also don't know the current state of CFRG

Opinions are welcome.  I am hesitant to put down very specific
requirements in a document that may live for a long time.  Some things
are best left to the daily routine of building.  A mid-way could be to state
a few algorithms as “current” algorithms, that is at the time of publication.
The future should be free to develop any way it needs to, I think.

> Editorial review is likely premature at this point, but I did notice […]

Thank you!

Best wishes,
 -Rick

---

From: Greg Hudson <[email-masked]>
Date: Mon, 20 Oct 2014 12:12:24 -0400

> looking at the same thing in a different manner?

There's nothing objectively wrong with repurposing the subkey field, but
that is definitely what is going on.  "Half a key" (or more accurately,
material needed to negotiate a key via DH or ECDH) is not the same as an
RFC 3961 key.  For an example of the difference, note that in your
proposed protocol the AP-REP must be encrypted in the ticket session key
even though the AP-REQ contained a subkey field.

> other ticket policy settings, to indicate that such a downgrade indicates

As you say, trying it and downgrading is not secure--and is also
impossible since AP-REP/AP-REQ doesn't allow multiple round trips.
Relying on KDC configuration is not opportunistic.  Thus, secure
opportunistic negotiation is impossible under this proposal.

> this largely depends on the view whether the proposal abuses the subkey field.

RFC 4537 also uses authorization-data as a typed hole.  There is lots of
precedent for this in the Kerberos protocol, though more often with
padata than with authdata.

I am not making any argument from elegance; I am only discussing
deployment properties.  Requiring the KDC to keep track of server
software capabilities is not friendly to deployment.  (This requirement
is already present in Kerberos whenever a new RFC 3961 enctype is
introduced.  But we should not multiply the issue if we don't have to.)

> create a DH-based key between the two of them.

There is an authorization-data field in Authenticator.  It is used by
RFC 4537.

There is no authorization-data field in AP-REP or EncAPRepPart, so the
DH response would have to be shoehorned into subkey, or we would have to
extend EncAPRepPart with a new ASN.1 field.  I would prefer extending
the ASN.1 sequence, but there are arguments both ways.  We do have
precedent for extending an ASN.1 sequence with knowledge that the other
party supports the extension: we added encryped padata to EncKDCRepPart
in RFC 6806.  Regardless, at this point the server knows that the client
supports DH, so the choice does not affect any deployment properties.

> without being asked for it?

Short answer: yes, if we wind up using a have-kdc ticket flag in the
final protocol.

I am not sure what you read.  RFC 4120 section 2 states, "Most flags may
be requested by a client when the ticket is obtained; some are
automatically turned on and off by a Kerberos server as required."  This
flag would be in the latter category.  The same section states, "With
the exception of the INVALID flag, clients MUST ignore ticket flags that
are not recognized," so there is no compatibility issue with the KDC
setting a new flag without indication of client support.

> drop “Primal” DH then I’d love to go that way.

I have heard this called "Integer DH."  I have nothing to add to your
comments on this, except to note that NIST curves vs. Curve25519 and
similar may also become an issue.

While I am responding, I have more to say on the issue of reply cache
avoidance.  The initial proposal states that a server does not need to
use a replay cache if it sees an AP-REQ with a DH Authenticator, because
it knows that any server using that Authenticator cannot help but create
a unique subkey in its response.  Unfortunately, this is not enough; a
server also needs to know that any server using the Authenticator will
actually use the subkey to protect the data stream, and that it won't
accept messages from the client transmitted using the ticket session key.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Oct 2014 14:16:54 -0400 (EDT)

Are there any places where extension could put DH parameters other than
the subkey field and dedicated authdata?  It will be good to get forward
secrecy for kerberos, but we should make sure to do a full anaylsis before
we choose what path to follow.

Some minor things:

I would probably want to tweak the introduction a bit, regarding use cases
across the Internet being "extreme", and being used "mainly" on intranets.

I also understand that "Perfect Forward Secrecy" is something of a term of
art, but prefer just "Forward Secrecy" as being perhaps more accurate.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Mon, 20 Oct 2014 14:47:40 -0400

> we choose what path to follow.

There are no other fields which look appropriate, so I think the only
other option is extending the AP-REQ or Authenticator ASN.1
sequences--most likely Authenticator, so the attacker can't downgrade by
stripping out the extra field.  We generally do not extend RFC 4120
ASN.1 sequences without an indication of support by the other party;
those sequences are not marked as extensible, so an implementation is
within its rights to throw a decoding error--although I think existing
implementations tend to just ignore the extra fields.  Rick's proposal
does contain an indication of support, but since the indication of
support comes from a third party, we need to worry about graceful
recovery in case it's wrong.  Here's what happens in each of the three
options if the client tries to use it against an old server:

* Repurposed subkey: old servers won't recognize the new enctype and
will respond with an error (I think a generic error because the only
appropriate specific code is scoped to the KDC for some reason).

* Authenticator authdata in an IF-RELEVANT container: old servers will
ignore the authdata and will respond using the subkey (or ticket session
key if no subkey was specified) without doing DH.  The client can take
this as a secure indication that the server doesn't actually support DH.

* Extended ASN.1 sequence: theoretically, servers might throw a decoding
error and discard the request without an error response.  In practice,
servers will ignore the new field and will respond using the subkey or
ticket session key, which the client can take as a secure indication
that the server doesn't support DH (assuming it was the Authenticator
sequence which was extended).

As I mentioned previously, the last time we wanted to extend the AP-REQ
exchange (for enctype negotiation, RFC 4537), we used the authenticator
authdata.  I wasn't involved in that decision, but the reasoning seems
sound.

Extending Authenticator also poses some implementation issues for MIT
krb5.  When we added encrypted padata (RFC 6806), we extended the public
krb5_enc_kdc_rep_part structure because it didn't appear in any public
APIs.  krb5_authenticator does appear in a few public APIs; we might
still be able to get away with extending the structure, but it's less clear.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 21 Oct 2014 10:31:18 +0200

Hi,

> stripping out the extra field.

I am closing in on this option too, using AD-IF-RELEVANT as a signed
but easily ignored extension.  It means that opportunistic connection
attempts will work, and that no unsigned errors can be inserted by an
attacker to force a downgrade.

Pros:
 - opportunistic KRB5-KDH
 - no need for a ticket flag have-kdh
 - KDC does not need to change
 - administrator does not need to administer have-kdh flags

Cons:
 - perform a DH calculation on every outgoing attempt
 - possible complexity due to pregenerated DH and/or reuse of unused DH
 - still need to find a location for the DH response — subkey could work

> appropriate specific code is scoped to the KDC for some reason).

So this automatically leads to renegotiation, which isn’t possible, and so
to the have-kdh flag stored in the KDC; also because the error is not
signed and so not trustworthy.

> this as a secure indication that the server doesn't actually support DH.

Discussed above.

> sequence which was extended).

This one involves the most redefinition work, and provides the least
certainty of backward compatibility.

> authdata.  I wasn't involved in that decision, but the reasoning seems

Pragmatic, yes.

> still be able to get away with extending the structure, but it's less clear.

Sounds like a FUD scenario in getting it adopted; and we need both ends to
support DH to get it going.

My money is on the authorization_data in the AP-REQ authenticator, and
on the subkey in the AP-REP message.

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 21 Oct 2014 12:13:19 +0200

Hello Benjamin,

> across the Internet being "extreme", and being used "mainly" on intranets.

I removed these parts, as they don’t add much but fluff.  I changed it to:

<t>Kerberos5 lends itself well to infrastructure-supported mutual
authentication.  It also provides facilities to authenticate across realm
boundaries, in which case the control over the network infrastructure used
is often distributed.</t>

<t>In such distributed-control scenario's, it is attractive to…</t>

> art, but prefer just "Forward Secrecy" as being perhaps more accurate.

No problem, it’s the same AFAIK.  Will change in the next version.

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 21 Oct 2014 13:01:08 +0200

Hello Greg and others,

1. Replay cache avoidance
2. Security implications

> accept messages from the client transmitted using the ticket session key.

This was indeed specified; does the following text address your concern?

  <t>After both AP-REQ and AP-REP have been processed, and their joint meaning
  in the table above indicates that a shared secret can be constructed, then both
  parties MUST derive that shared secret and continue to communicate using that,
  employing the encryption type specified in the AP-REQ message's subkey field,
  notably the etype2 subtype.</t>

The one thing not covered here is replay of the AP-REP; but the will not yield the
same AP-REQ and not the same DH-session-key if the server generates a fresh
DH offer for each AP-REP, so the continued application protocol cannot be
replayed.  Therefore, I see no risk of falsely accepting a session.

The fact that an AP-REQ is produced for mutual authentication could have two
security drawbacks that I can see:

* The server might become an oracle of some kind; though nothing specific
can be asked; the ap-options seems to be open for variation but it hardly
seems interesting; the ticket is a variable spot, and perhaps multiple
requests with other tickets could be used to establish access for those
tickets.

* The server could become the target of a DoS attack on computational
power, by making it compute lots and lots of DH offers.  The permissible
time window for AP-REQ acceptance defines how long such an attack
could last; this time would also max out the distribution time in case of a
DDoS attack, which constrains that risk to tightly connected bots.  There is
no risk of an amplification-type attack on bandwidth because AP-REQ
is not (much) bigger than AP-REP; both include the DH offer.

-Rick

---

From: Greg Hudson <[email-masked]>
Date: Tue, 21 Oct 2014 22:49:48 -0400

On 10/21/2014 07:01 AM, Rick van Rein wrote:
>> Unfortunately, this is not enough; a

Not really.  There is no way for the library which implements
AP-REQ/AP-REP to know whether the caller is going to do anything useful
with the negotiated subsession key--or whether other server
implementations which receive the authenticator will do so.

If negotiating a unique key in an AP exchange were sufficient to do away
with replay caches, we would be able to do so without DH, since the
server can pick a unique subkey in an AP-REP already, and does so
whenever RFC 4121 is used.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 22 Oct 2014 13:59:29 -0400

>  - administrator does not need to administer have-kdh flags

We may still need a KDC indication of KDH support, for several reasons.

First, in the initial deployment, clients won't necessarily want to
offer KDH without a reason to believe it will yield a benefit.  Being
able to try opportunistically and downgrade securely is great, but it's
not always the best choice.

Second, some protocols (e.g. MIT Zephyr) are sensitive to the size of
the AP-REQ.  The KDC may need a way to advise clients not to use KDH for
those server principals.

Third, we cannot assume that our initial set of ECDH algorithms will be
good enough forever--at some point there will be a new set of
algorithms, and further new sets beyond that.  Clients will not be in a
great position to gracefully upgrade to new algorithms without advice
from the KDC--they would either have to make multiple KDH offers, or
risk trying an algorithm that is too new and falling back to not using
forward secrecy at all.

A single ticket flag isn't sufficient to handle the second and third
cases.  Since we don't want to be introducing lots of ticket flags, I
think the right vehicle is the encrypted padata field introduced in RFC
6806.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 24 Oct 2014 11:50:06 +0200

Hi,

…and I thought KRB5-KDH was going to be a trivial stepping stone
towards TLS-KDH ;-)

Really though, knowing the protocol that embeds an exchange turns
out to be a major advantage, so the TLS variation may actually be
simpler.  Well, that doesn’t reduce the potential value of KRB5-KDH
of course.

This sort of advantage is perhaps best resolved through flags on one
of the APIs, because the application can steer behaviour in a static
way.  This would also make it possible to enforce KDH protection if so
desired by an application.

> We may still need a KDC indication of KDH support, for several reasons.

Surprised… I was happy to have gotten rid of it.  But let’s consider.

> not always the best choice.

I suppose a setting on the cilent could be used to avoid the “wasteful”
aspect of opportunism in early phases.  But that would not be easy to
control centrally; so the KDC could send it; if it were just this one
thing, the solution might have been a global toggle in the KDC that
switches over the entire realm.

> the AP-REQ.  The KDC may need a way to advise clients not to use KDH for

This sounds awkward.  RFC 4120 clearly states "The encoding of Kerberos
protocol messages shall obey the Distinguished Encoding Rules (DER) of
ASN.1”, so how could it have such senstivities?  Is this in fact a bug in
Zephyr?  If it is, I think it should be localised rather than permitted to spread
into KDC settings and new specifications that build upon the definitions of
its predecessors — for instance, introduce an API flag to suppress KDH,
and cause a dependency between the app and the library version that
disables library replacement without application replacement.  Alternatively,
the library configuration could hold settings that flag down KDH behaviour
on buggy service names.

> risk trying an algorithm that is too new and falling back to not using

Pondering.  RFC 4537 provides a negotiation mechanism, but it doesn’t
introduce extra packets and so the client must still make its DH offers
as you describe.

Pondering.  There generally is overlap between old and new algorithms,
enabling a range of “safe” choices.  But if a server knows about the
retraction of the security status of algorithm A while a cilent is unaware,
we’ll be in trouble (that is, opportunism fails).

Pondering.  In such exceptional cases where unacceptable algorithms are
tried by a negligent client, it might be notified by the server and would
have to fetch a new ticket to try again.  This knowledge could not spread
though, or it would incur a risk of downgrade attack on the ciphers used.

Again, it feels best to have a list of permissible ciphers setup in the
library configuration, so the operator can modify these settings, in
response to security reports, which can suggest it as a quickfix.  And
when a new package is available, which is bound to occur soon for
security trouble, then it too can be installed.  Services failing to give
access would enforce this upgrading behaviour from local installations,
which is a pest, but that is just what security problems are… a pest.

There may of course be distribution mechanisms for configuration
information, to make deployment more reliable.  I am not sure if
the KDC should be taking up on that role.

> think the right vehicle is the encrypted padata field introduced in RFC

You mean a plain PA-DATA with encryption on its contents, so it is
validated?  Yes, the validation would be needed to avoid downgrade
attacks.  It is another “pragmatic solution” however, and adds to the
complexity of Kerberos — and it requires a KDC change.  I am not
a fan of that style.  Curious if the alternative approach above sounds
agreeable to the list.

Cheers,
 -Rick

---

From: Simo Sorce <[email-masked]>
Date: Fri, 24 Oct 2014 09:16:02 -0400

On Fri, 24 Oct 2014 11:50:06 +0200
Rick van Rein <[email-masked]> wrote:

> > offer KDH without a reason to believe it will yield a benefit.
> > Being able to try opportunistically and downgrade securely is
> > great, but it's not always the best choice.
> 
> I suppose a setting on the cilent could be used to avoid the
> “wasteful” aspect of opportunism in early phases.  But that would not
> be easy to control centrally; so the KDC could send it; if it were
> just this one thing, the solution might have been a global toggle in
> the KDC that switches over the entire realm.
> 
> > Second, some protocols (e.g. MIT Zephyr) are sensitive to the size
> > of the AP-REQ.  The KDC may need a way to advise clients not to use
> > KDH for those server principals.
> 
> This sounds awkward.  RFC 4120 clearly states "The encoding of
> Kerberos protocol messages shall obey the Distinguished Encoding
> Rules (DER) of ASN.1”, so how could it have such senstivities?  Is
> this in fact a bug in Zephyr?  If it is, I think it should be
> localised rather than permitted to spread into KDC settings and new
> specifications that build upon the definitions of its predecessors —
> for instance, introduce an API flag to suppress KDH, and cause a
> dependency between the app and the library version that disables
> library replacement without application replacement.  Alternatively,
> the library configuration could hold settings that flag down KDH
> behaviour on buggy service names.
> 
> > Third, we cannot assume that our initial set of ECDH algorithms
> > will be good enough forever--at some point there will be a new set
> > of algorithms, and further new sets beyond that.  Clients will not
> > be in a great position to gracefully upgrade to new algorithms
> > without advice from the KDC--they would either have to make
> > multiple KDH offers, or risk trying an algorithm that is too new
> > and falling back to not using forward secrecy at all.
> 
> introduce extra packets and so the client must still make its DH
> offers as you describe.
> 
> retraction of the security status of algorithm A while a cilent is
> unaware, we’ll be in trouble (that is, opportunism fails).
> 
> Pondering.  In such exceptional cases where unacceptable algorithms
> are tried by a negligent client, it might be notified by the server
> and would have to fetch a new ticket to try again.  This knowledge
> could not spread though, or it would incur a risk of downgrade attack
> on the ciphers used.
> 
> Again, it feels best to have a list of permissible ciphers setup in
> the library configuration, so the operator can modify these settings,
> in response to security reports, which can suggest it as a quickfix.
> And when a new package is available, which is bound to occur soon for
> security trouble, then it too can be installed.  Services failing to
> give access would enforce this upgrading behaviour from local
> installations, which is a pest, but that is just what security
> problems are… a pest.
> 
> > cases.  Since we don't want to be introducing lots of ticket flags,
> > I think the right vehicle is the encrypted padata field introduced
> > in RFC 6806.
> 

To me it seems the best outcome, traditionally the KDC assists in
dealing with algorithm agility, and it should do so in this case too.

Note that clients can still ignore what the KDC says and use
opportunistic methods that differ from advice received, but at least
they will have a chance of knowing what is expected of them if the
PA-DATA packet is available.

The only "issue" would be if client and server are upgraded but the KDC
is not notified of the new capablities, so that the KDC keeps sending
to the client advice to use "weaker" algorithms only, but that is no
different than having new clients and servers that can do AES today but
still giving them only DES keys.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Greg Hudson <[email-masked]>
Date: Fri, 24 Oct 2014 10:57:35 -0400

On 10/24/2014 05:50 AM, Rick van Rein wrote:
> validated?

No; please see RFC 6806 section 11.  This field is already
cryptographically protected and securely negotiated; all we would need
is a way to represent support for different KDH algorithms, or to
indicate that KDH is undesirable for space reasons.

> ASN.1”, so how could it have such senstivities?

It's about how the authenticator is transported.  In the case of Zephyr,
there is a limitation of 512 bytes on the packet header, and the more
space consumed by the ticket and authenticator, the less space there is
for other packet header fields.  Zephyr is not a particularly good
protocol, but it is not the only protocol which can be negatively
impacted by ticket or authenticator expansion.

> response to security reports, which can suggest it as a quickfix.

I don't understand this proposal.  If there are old KDH algorithms and
new ones, the client wants to use one of the new ones, but only if it
thinks the server will support that.  The client's library configuration
doesn't know anything about the server's capabilities.

It seems like you're suggesting that clients would continue to offer one
of the old algorithms until an advisory comes out demonstrating that it
is insecure, at which point administrators would blacklist the old
algorithm.  Delaying use of new algorithms until the old ones are
completely broken is not a good form of algorithm agility.

> the KDC should be taking up on that role.

The KDC is already responsible for negotiating RFC 3961 enctypes to the
server, since the ticket session key must be understood by both the
client and the server.  The client presents a supported enctype list to
the KDC, but the KDC simply has to know about the server's capabilities
as the server isn't a party to the AS or TGS exchange.

The MIT krb5 administrative tooling doesn't currently do a great job of
communicating server capabilities to the KDC.  And it can't do a perfect
job; there isn't always exactly one implementation of Kerberos on a
server, and keytabs aren't always administered from the server.  So this
responsibility of the KDC can sometimes be a bit painful--but it's not a
new job.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 24 Oct 2014 17:18:02 +0000

> 24 okt 2014 kl. 06:16 skrev Simo Sorce <[email-masked]>:
> 

For the same reason we got ETypeInfo in GSS we can have KDC assist, but it can't be required.

Love

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 16:33:37 -0500

> I just posted a new I-D that introduces a DH subkey mechanism for Kerberos.

IMO we should adopt a work item for this feature.

I'm not sure yet what's the best design.

My notes:

 - overloading enctype with DH is tempting, but we need to be careful to
   avoid a cartesian product of {DH curves} x {traditional enctypes}

 - if the KDC has the service's public DH key(s) then it can send it as
   the session key for the ticket when the client offers the
   corresponding enctype

 - if the KDC knows the services' supported DH curves but not its public
   keys then... we need to extend KDC-REP to convey this info

 - if the KDC knows the services' supported DH curves then it might as
   well know the service's public keys too!

 - knowing the service's supported DH enctypes the client can then
   use the subkey field in the Authenticator to convey its DH public
   key (but watch out for cartesian explosion)

 - the service can convey its public key (or a new one, if the KDC knew
   its long-term one) using the subkey field of the AP-REP

   (but again, cartesian explosion)

   BUT, if the service doesn't send its pubkey this way then we need to
   extend AP-REP.

 - for proper PFS we need one more message after the AP-REP

 - for proper PFS we need a DH exchange in the AP exchange; it's not
   enough that the KDC knows the service's DH public keys

 - just because we want proper PFS doesn't mean we must do a full DH
   exchange in every AP exchange: we could do something like TLS
   resumption: the service should return a short-lived Ticket (minted by
   the service)

   Let's call this "fast re-auth tickets".  Other uses include:

    - PAC/CAMMAC compression: the service caches the PAC/CAMMAC and
      returns a smaller Ticket for future AP exchanges.

    - Caching of service-side state (e.g., when the KDC-minted Ticket
      didn't have a PAC/CAMMAC and the service wanted one and doesn't
      want to cache it).  (IMO this is not a good idea.  It's the
      reverse of the previous item.)

 - fast re-auth tickets imply a need for extra round-trips for error
   recovery, but we needed this for other reasons anyways, so we might
   as well do it

 - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS

Clearly it'd be best to not overload subkey, and therefore not overload
enctype.

Clearly we need:

 - a three-message AP exchange option

 - an extra round-trip option

 - an AP-REP extension (like authz-data in Authenticator, but in the
   other direction)

 - a KDC-REP body enc-part extension (for conveying things like
   services' known DH public keys)

 - extensions to fit in the new slots to convey public DH keys, and an
   authz-data for the same purpose in the Authenticator

 - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 16:33:35 -0500

My notes:

Clearly we need:

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 16:58:21 -0500

> My notes:

A couple more points:

 - when PFS is not needed then we can still use a single round trip,
   even in the case that the KDC didn't know the service's public keys
   or supported curves:

   C->S: AP-REQ w/ client's DH pubkey(s) (for one or more curves) and
                   list of enctypes
   S->C: AP-REP w/ service's DH pubkey for the selected curve, + an
                   indication of which enctype was selected

   this way we also get fallback to not-DH if the service doesn't
   support it.

>    avoid a cartesian product of {DH curves} x {traditional enctypes}

That's what TLS does.  Let's not repeat that mistake.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Oct 2014 17:05:50 -0500

I should also add that having KDCs know services' public keys is not a
crazy idea.

I've been wanting to build a DH-based service keying system where the
KDC stores the services public keys and _caches_ the DH shared secret
keys in the principal database.  Services keep their private keys and
realms' public keys and _cache_ their DH shared secret keys.

I'm sure you can all see advantages to doing this...  For example,
recovery from KDC principal database compromise mostly involves
distributing new public keys for the compromised realm, at least for
service keys (client principal keying is another story, but PKINIT helps
there).

FYI, Roland Dowdeswell has a Kerberos administration system that uses DH
(ECDH) to key services, and even supports multi-party DH for keying
clusters (atomically!).  Storing service public keys in the KDC is not
very farfetched at all.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 27 Oct 2014 14:46:23 -0400

>    well know the service's public keys too!

I don't follow this step.  If the KDC knows the server's "DH public key"
(g^y for integer DH), that implies that the server is going to use the
same "DH private key" (y) for as long as the KDC is giving out that key.
 But forward secrecy depends on discarding private keys often enough
that a future compromise of either party doesn't give access to the
private key used for past exchanges.  You can reuse a private key for
multiple exchanges, but you can't keep using it for longer than you
generally expect sessions to last (i.e. at most hours, not days or weeks).

My understanding is that Rick's entire purpose here is to get forward
secrecy in AP exchanges.  Synchronizing public keys between servers and
KDCs would seem to harm that goal.  It's much easier (although still not
trivial) to keep the KDC informed of algorithm support than it is to
keep the KDC informed of a frequently-changing public key.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Oct 2014 15:13:46 -0400 (EDT)

Cherry-picking minor notes...

> IMO we should adopt a work item for this feature.

[Puts on chair hat]
Noted, thanks.
[takes off chair hat]

>    keys then... we need to extend KDC-REP to convey this info

I think it might be very complicated to try to manage this information in
the KDB.

>    Let's call this "fast re-auth tickets".  Other uses include:

This has the potential to be a pretty heavyweight protocol/code
modification.  I'm not sure that we have the collective energy to do so
(comparatively, TLS has a lot more effort focused on it).

>  - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS

forward secrecy relies on both parties discarding the ephemeral values;
I'm not sure that the GSSAPI will be able to effectively enforce that.
(Not that we shouldn't have a flag to request this sort of thing and
indicate that it was used, just that such a ret_flag may not be as strong
a guarantee as we want.)

-Ben

---

From: Simo Sorce <[email-masked]>
Date: Mon, 27 Oct 2014 16:03:32 -0400

On Mon, 27 Oct 2014 14:46:23 -0400
Greg Hudson <[email-masked]> wrote:

> >  - if the KDC knows the services' supported DH curves then it might
> > as well know the service's public keys too!
> 
> I don't follow this step.  If the KDC knows the server's "DH public
> key" (g^y for integer DH), that implies that the server is going to
> use the same "DH private key" (y) for as long as the KDC is giving
> out that key. But forward secrecy depends on discarding private keys
> often enough that a future compromise of either party doesn't give
> access to the private key used for past exchanges.  You can reuse a
> private key for multiple exchanges, but you can't keep using it for
> longer than you generally expect sessions to last (i.e. at most
> hours, not days or weeks).
> 
> secrecy in AP exchanges.  Synchronizing public keys between servers
> and KDCs would seem to harm that goal.  It's much easier (although
> still not trivial) to keep the KDC informed of algorithm support than
> it is to keep the KDC informed of a frequently-changing public key.

Same understanding here. Storing the keys in the KDB, not only would be
a problem management-wise it would strongly weaken the very feature we
are after (Forward Secrecy) by forcing the Service to keep private
keys stored somewhere as the service will now have to be able to
address the case where the service is restarted but the client has
already obtained the hint from the KDC.

Ideally a server running in a single server should be able to keep keys
only in memory and regenerate them when restarted.

Of course there needs to also be a way to store and even share among
peer services the same private key for those cases where clustering is
desired, but that's out of the scope of this ID I would think.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 15:45:26 -0500

> same "DH private key" (y) for as long as the KDC is giving out that key.

Indeed.

> private key used for past exchanges.  You can reuse a private key for

DH isn't only about forward secrecy, and it can be used both, with
ephemeral keys, and with long-term keys.

> generally expect sessions to last (i.e. at most hours, not days or weeks).

It'd be possible to have the KDC know a service's long-term public DH
key *and* for the service to also use an ephemeral public key in the AP
exchange to obtain PFS if either it or the initiator demand it.

Storing a public key would be useful for the other reasons that I gave.
But mostly I was exploring the design space in my comments.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 15:48:27 -0500

> I think it might be very complicated to try to manage this information in

It's hardly any worse than managing symmetric long-term keys.  Again, I
was exploring the design space.

> (comparatively, TLS has a lot more effort focused on it).

Perhaps.

> I'm not sure that the GSSAPI will be able to effectively enforce that.

Why not?

> indicate that it was used, just that such a ret_flag may not be as strong

Why not?

I mean, either the mechanism does what it was asked for and doesn't lie,
or it doesn't do what it was asked for and... doesn't lie.

A lying mechanism could lie about all sorts of things, and it'd just be
a bug, and therefore outside the scope of the spec.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Oct 2014 17:25:52 -0400 (EDT)

On Mon, 27 Oct 2014, Nico Williams wrote:

>  Again, I

Sure; I'm just saying what comes to mind as a result of that exploration
:)

> > I'm not sure that the GSSAPI will be able to effectively enforce that.

Thinking harder, the actual ephemeral values should not be needed after
security context establishment (just the derived keys), so okay, yes, the
implementations can guarantee that the ephemeral values are freed then.
Of course, the context's keys will need to remain around as long as the
context is valid, and if a sloppy long-running application fails to
destroy the security context, those keys used to encrypt actual messages
on the context might still be resident in memory if that machine got
hacked at some point in the future.  So, it's the "other endpoint might
fail to destroy the security context" bit that can't be enforced reliably.
"Maybe we should say 'forward secrecy', not 'perfect forward secrecy'."

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 16:31:32 -0500

On Mon, Oct 27, 2014 at 05:25:52PM -0400, Benjamin Kaduk wrote:
> > > forward secrecy relies on both parties discarding the ephemeral
> > > values; I'm not sure that the GSSAPI will be able to effectively
> > > enforce that.
> >
> > Why not?
> 
> Thinking harder, the actual ephemeral values should not be needed
> after security context establishment (just the derived keys), so okay,
> yes, the implementations can guarantee that the ephemeral values are
> freed then.  Of course, the context's keys will need to remain around
> as long as the context is valid, and if a sloppy long-running
> application fails to destroy the security context, those keys used to
> encrypt actual messages on the context might still be resident in
> memory if that machine got hacked at some point in the future.  So,
> it's the "other endpoint might fail to destroy the security context"
> bit that can't be enforced reliably.  "Maybe we should say 'forward
> secrecy', not 'perfect forward secrecy'."

Right.  Also, without re-keying we really depend on the app to re-key if
it wants to guarantee forward secrecy for some past communications.

(We could, perhaps, have PFS re-keying piggybacked on per-message
tokens.  It's doable, but I'm not sure that it's worth doing.  There are
many other things I'm certain are worth doing, and we have limited
energy.)

Note though that there is value is allowing what-should-be-
ephemeral keys to be re-used a few times -performance value- without
losing much in terms of protection.  But this requires a bit of care to
prevent accidental symmetric key re-use, something like a small
counter/nonce.

Nico
--