Subject: [Ietf-krb-wg] draft-ietf-krb-wg-preauth-framework-12 comments

From: [email-masked]
Date: Mon, 15 Jun 2009 14:32:43 -0400 (EDT)

I have reviewed FAST draft 12.  I have no new comments of interest,
except for an editorial comment regarding section 1:

   FAST provides a protected channel between the client and the KDC,
   and it can optionally deliver a reply key within the protected
   channel.

This should perhaps say "strengthen the" instead of "deliver a" to
reflect the change to use a strengthening key in section 6.5.3.

On March 23 I submitted some editorial comments privately to the
authors.  Most have not been addressed; they are:

* Section 3.2: KDC_ERR_MORE_PREAUTH_DATA_NEEDED is gratuitously
  inconsistent with KDC_ERR_PREAUTH_REQUIRED ("needed" and "required"
  having the same English meaning).

* Section 5: "protected against authentication" doesn't make any
  sense; perhaps "protected against alteration" was intended.

* Section 6.1: The definition of KRB-FX-CF2 is inconsistent in its use
  of "->" notation.

* Section 6.3: "and not including a cooking" should say "cookie".

* Section 6.4: PA-AUTHENTICATION-SET and PA-AUTH-SET-SELECTED are
  gratuitously inconsistent in whether they abbreviate the word
  "authentication".

* Section 6.5.6: run-on sentence: "The client sends a padata of type
  PA-ENCRYPTED-CHALLENGE the corresponding padata-value...".

* The name "encrypted challenge" is confusing to me since no challenge
  is involved.  Both sides prove knowledge of a key derived from the
  armor and long-term keys by encrypting timestamps; when I saw the
  word "challenge" was expecting something more along the lines of the
  KDC asking the client to encrypt a specified nonce.  I have no issue
  with the semantics of the mechanism, only its name.

It is probably too late to fix the naming inconsistency problems
without pain, but the other editorial notes could be addressed easily.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Jun 2009 15:52:32 -0400

Sorry about dropping the ball on your editorial comments.

In general I agree with your proposed changes except:
* Section 3.2: KDC_ERR_MORE_PREAUTH_DATA_NEEDED is gratuitously
  inconsistent with KDC_ERR_PREAUTH_REQUIRED ("needed" and "required"
  having the same English meaning).

I personally don't see a problem here but am happy to make the change.
If people do like the current text they should speak up.

I agree encrypted challenge is not a great name for this mechanism,
but don't have a better one, and don't think this is worth fixing at
this point.  Using challenge rather than timestamp refers to the fact
that the data encrypted need not be the current time.  If the client
is too far off, then the KDC will send a skew error that the client
can use to update its idea of what the KDC wants.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Mon, 15 Jun 2009 20:08:01 +0000

>> Greg wrote:

> If people do like the current text they should speak up.

Same here. I do not see why we need to make a change for this, but I do not object to changing the symbolic name of this error code to say KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, if that makes it easier to understand and if it is more self-consistent.

--Larry

---

From: Larry Zhu <[email-masked]>
Date: Mon, 15 Jun 2009 20:20:17 +0000

> can use to update its idea of what the KDC wants.

It might be helpful to explain this so the naming makes sense, i.e. why the word "challenge" is used instead of "timestamp" because it is not really a time stamp from the client's perspective. This fast factor essentially relaxes the loose-clock-synchronization requirement for the Kerberos client. The exact aspect is in practice done in the implementation, but this is the attempt to make it clear in the specification based on the deployment experience.

--Larry

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Jun 2009 16:45:06 -0400

I'm happy to add an explanation.

--Sam