Subject: [Ietf-krb-wg] [Russ Housley] DISCUSS and COMMENT: draft-ietf-krb-wg-preauth-framework

From: Sam Hartman <[email-masked]>
Date: Sat, 15 May 2010 12:51:47 -0400

Subject: DISCUSS and COMMENT: draft-ietf-krb-wg-preauth-framework
From: Russ Housley <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 8 Apr 2010 08:04:43 -0700 (PDT)

Discuss:

  Section 5.1 says:
  >
  > New mechanisms MUST NOT be hard-wired to use a specific algorithm.
  >
  While I am a strong supported of algorithm agility, I can imagine a
  pre-authentication mechanism that is not algorithm agile.  Given the
  type fields in the protocol, many of the reasons for a MUST NOT
  statement are already addressed.  Would it be appropriate for two
  pre-auth mechanism to be defined that use ZKPP techniques, one that
  makes use for discrete log and another that makes use of elliptic
  curve?

Comment:

  I find the Abstract quite difficult to understand.  I had to read the
  Introduction in order to understand it.  The middle paragraph is not
  useful without a lot of context.

  The Introduction uses "padata type" with no explanation.  It should be
  expanded, and a reference to the base Kerberos specification with a
  section number would help the reader.

  Someone without detailed knowledge of Kerberos will be confused by the
  use of AS and KDC in the first two sentences of Section 3.  Perhaps
  the audience of this document is Kerberos experts, but I suspect that
  an additional sentence here could avoid a lot of confusion.

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

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 16 May 2010 23:06:03 -0500

>   makes use for discrete log and another that makes use of elliptic

Not only that, but also, if you can negotiate mechanisms then why
encourage multi-layer negotiations?  Multi-layer negotiations are
fraught with danger, which is why we do not allow the use of SPNEGO in
the SASL GS2 framework, and why we did hard-wire SCRAM to use a single
hash function (if we need to switch to a new hash function we'll just
introduce a new mechanism name for SCRAM using that hash function).

Therefore, I'd in fact go the opposite route and say that pre-auth
mechanisms MUST be hard-wired to use specific cryptographic algorithms.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 May 2010 08:30:55 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Sat, May 15, 2010 at 12:51:47PM -0400, Sam Hartman wrote:
    >> While I am a strong supported of algorithm agility, I can imagine
    >> a pre-authentication mechanism that is not algorithm agile.
    >> Given the type fields in the protocol, many of the reasons for a
    >> MUST NOT statement are already addressed.  Would it be
    >> appropriate for two pre-auth mechanism to be defined that use
    >> ZKPP techniques, one that makes use for discrete log and another
    >> that makes use of elliptic curve?

    Nicolas> Not only that, but also, if you can negotiate mechanisms
    Nicolas> then why encourage multi-layer negotiations?  Multi-layer
    Nicolas> negotiations are fraught with danger, which is why we do
    Nicolas> not allow the use of SPNEGO in the SASL GS2 framework, and
    Nicolas> why we did hard-wire SCRAM to use a single hash function
    Nicolas> (if we need to switch to a new hash function we'll just
    Nicolas> introduce a new mechanism name for SCRAM using that hash
    Nicolas> function).

    Nicolas> Therefore, I'd in fact go the opposite route and say that
    Nicolas> pre-auth mechanisms MUST be hard-wired to use specific

This is not the strategy we've taken with pkinit.  Also, I don't think
that it is the right strategy if your mechanism contains other
mechanisms.  I am much hhappier with my proposed text than either MUST
or MUST NOT hard wire.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 09:50:03 -0500

> This is not the strategy we've taken with pkinit.  Also, I don't think

PKINIT long pre-dates (by over a decade) our recent aversion for multi-
layer negotiation, and, in any case, until recently there wasn't much
for Kerberos pre-auth to negotiate, thus making the multi-layer
negotiation problem pre-pre-auth framework a non-problem for Kerberos.

> mechanisms.  I am much hhappier with my proposed text than either MUST

A "mechanism that contains other mechanisms" is either one with a "name"
for specific combinations or one that negotiates specific combinations.
If the former, then you need a negotiation mechanism layered above; if
the latter, you already have a negotiation mechanism.  Now if each
mechanism then further negotiates algorithms and what not, then I think
we have a multi-layer negotiation issue.

Put differently: what makes the pre-auth framework so different from
SASL that the approach we chose for SCRAM cannot be taken here?

Put yet differently: what harm might come from having FAST factor
mechanisms that do not negotiate cryptographic algorithms?  After all,
the pre-auth framework will be able to negotiate amongst such
mechanisms.  If we cannot identify such a harm then your MUST is too
strong.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 May 2010 13:34:13 -0400

--On Sunday, May 16, 2010 11:06:03 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> encourage multi-layer negotiations?

Mostly, we shoudln't.  However...

> mechanisms MUST be hard-wired to use specific cryptographic algorithms.

This is not the answer either.

In Kerberos, we have a means of enctype negotiation as part of the AS 
exchange, so that by the time it sends its first response, the KDC knows 
which enctypes it and the client have in common and can select one. 
Whenever possible, extensions should use the RFC3961 abstraction with the 
negotiated enctype and its associated cksumtype, rather than hardcoding use 
of a particular algorithm.

In the long run, this may require us to extend RFC3961 such that in 
addition to having an associated cksumtype, enctypes also have an 
associated unkey hash and possibly other algorithms.  However, such 
extension is not essential to the present document nor, I think, to any 
mechanisms we are currently contemplating.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 12:40:15 -0500

On Mon, May 17, 2010 at 01:34:13PM -0400, Jeffrey Hutzelman wrote:
> In Kerberos, we have a means of enctype negotiation as part of the
> AS exchange, so that by the time it sends its first response, the
> KDC knows which enctypes it and the client have in common and can
> select one. Whenever possible, extensions should use the RFC3961
> abstraction with the negotiated enctype and its associated
> cksumtype, rather than hardcoding use of a particular algorithm.

That's [almost] fine.  But that's not what the sentence in question
says.  I say "almost" because krb5 enctypes don't include, for example,
plain hash functions, public key algorithms (for PKINIT, ZKPP, etc.).
For anything beyond plain hash functions I think it gets ugly, quickly.
I'd rather take the SCRAM approach, but modified to indicate that
mechanisms must use RFC3961 with the negotiated enctype for all
symmertric crypto.

> associated unkey hash and possibly other algorithms.  However, such

Yes.

> extension is not essential to the present document nor, I think, to
> any mechanisms we are currently contemplating.

The MUST in question is rather strong given that we don't have the
ability to negotiate all crypto algs that a mechanism's going to need.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 May 2010 15:31:48 -0400

I'll ask you the same question I asked Nico: Is the text I actually
proposed in my reply to Russ acceptable?  Both you and nico seem to be
going down the path of opening up a lot more than I'm comfortable with
at this stage in the document.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 May 2010 14:34:18 -0500

> at this stage in the document.

Yes, I'm OK with that text, since it basically says: do whatever's best,
which is good advice to future mechanism designers :)

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 May 2010 15:54:54 -0400

> at this stage in the document.

As I understand it, your proposed change simply deletes the requirement and 
says nothing more about the problem.  In context, this is probably OK; the 
paragraph after the deleted one RECOMMENDs using 3961 primitives and 
explains both that this provides algorithm agility and why that is an 
advantage.

However, you also make another change, which is to replace the requirement 
for a checksum of the entire conversation with what I think turns out to be 
a weaker requirement.  In particular, unless done carefully (and I'm pretty 
sure FAST gets this right), a message-at-a-time MAC may fail to protect 
against message reordering and partial replay attacks.

I do agree with the approach of requiring that the mechanism provide 
certain properties rather than prescribing a specific way of getting those 
properties.  Among other things, this makes it clear on exactly which of 
these properties other parts of the system may depend, which improves 
modularity and makes analysis easier.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 May 2010 16:49:46 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> However, you also make another change, which is to replace
    Jeffrey> the requirement for a checksum of the entire conversation
    Jeffrey> with what I think turns out to be a weaker requirement.  In
    Jeffrey> particular, unless done carefully (and I'm pretty sure FAST
    Jeffrey> gets this right), a message-at-a-time MAC may fail to
    Jeffrey> protect against message reordering and partial replay
    Jeffrey> attacks.

Do you want to suggest a change to cover this?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 12:50:30 -0400

> Do you want to suggest a change to cover this?

OLD:
   If there is more than one round trip for an authentication exchange,
   mechanism designers need to allow either the client or the KDC to
   provide a checksum of all the messages exchanged on the wire in the
   conversation, and the checksum is then verified by the receiver.

YOUR PROPOSAL:
   Mechanisms MUST guarantee that by the end of a successful
   authentication exchange, both the client and the KDC have verified
   all the plaintext sent by the other party. Strategies for
   accomplishing this include using message authentication codes (MACs) to
   protect the plaintext as it is sent or exchanging a MAC of the entire
   conversation after a key is established. Mechanism designers need to
   provide a strategy for updating cryptographic algorithms, such as
   providing negotiation of the algorithm within the mechanism or
   defining a new pre-authentication type for the new algorithm.

NEW:

   Mechanisms MUST guarantee that by the end of a successful
   authentication exchange, both the client and the KDC have verified
   all the plaintext sent by the other party.  If there is more than
   one round trip in the exchange, mechanisms MUST additionally guarantee
   that no individual messages were reordered or replayed from a previous
   exchange.  Strategies for accomplishing this include using message
   authentication codes (MACs) to protect the plaintext as it is sent,
   including some form of nonce or cookie to allow for the chaining of
   state from one message to the next, or exchanging a MAC of the entire
   conversation after a key is established.

   Mechanism designers need to provide a strategy for updating
   cryptographic algorithms, such as defining a new pre-authentication
   type for each algorithm or providing algorithm negotiation within
   the mechanism.  When providing in-mechanism algorithm negotiation,
   mechanism designers should attempt to avoid creating a multi-layer
   negotiation problem such as described in section 14 of [GS2].  One
   way to accomplish this might be to include a list of supported
   algorithms in the mechanism's padata-value to be used with the
   KDC_ERR_PREAUTH_REQUIRED error and in the pa-hint to be included in
   authentication sets as described in section 6.3.

GS2 => draft-ietf-sasl-gs2-20.txt

Note that I have included a new piece of advice relating to avoiding 
multi-level negotiation issues.  This adds an informative reference to GS2, 
which is already in the RFC-Editor queue.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 13:26:48 -0400

I'm not entirely sure that our thinking about multi-layer negotiation
has been entirely correct.  This is based on a conversation that you and
I had about multi-layer negotiation in Moonshot.  I've been thinking
more generally since that conversation and have been wondering if
perhaps our view on the topic is more simplistic than it should be.
So, for that reason, I'd prefer to avoid a reference to the multi-layer
negotiation argument.

How about the following:

Jeff:

New:
NEW:

  Mechanism designers need to provide a strategy for updating
  cryptographic algorithms, such as defining a new pre-authentication
  type for each algorithm or taking advantage of the client's list of
  supported RFC 3961 encryption types to indicate the client's support
  for cryptographic algorithms.

Basically I remove the text suggesting in-mechanism negotiation should
be used at all; I rarely think it will be the right approach for
preauth.  Are you OK with this?  If so, can I issue a new draft in the
hopes that it satisfies Russ?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 13:33:09 -0400

> hopes that it satisfies Russ?

I'm OK with removing the text suggesting in-mechanism negotiation.  I'm 
inclined to agree with you that it's rarely going to be the right approach, 
though it does turn out to be what we did in PKINIT.

Note that I did not mention use of 3961 algorithms because the paragraph 
following the one we're editing already discusses that.  I'm fine with your 
new text with or without the 3961 mention.

Feel free to issue a new draft when you think we've resolved this.

-- Jeff