A Generalized Framework for Kerberos Pre-Authentication
RFC 6113

A couple of trival things to look at...

Please expand acronyms on first use. For example KDC in the Abstract

---

"padata" is used in section 1 before it is explained in section 2.

---

Section 3

   When a Kerberos client wishes to obtain a ticket using the
   authentication server, it sends an initial Authentication Service
   (AS) request.  If pre-authentication is required but not being used,
   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.

Unless this is defining existing behavior (in which case you should
include a reference) you should substitute /will/MUST/

In Section 3.2:
>   The KDC SHOULD NOT send data that is encrypted in

"encrypted with"?

>   the long-term
>   password-based key of the principal.

In Section 5.1:

>   New mechanisms MUST NOT be hard-wired to use a specific algorithm.

What kind of algorithm?


In Section 6.4.2:

>   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
>   authentication padata.  The corresponding padata-value field
>   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
>   REQUEST.  As with all pre-authentication types, the KDC SHOULD
>   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
>   advertisement of PA-FX-FAST with an empty pa-value.  Clients MUST
>   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
>   error.

Did you mean KDC_ERR_PREAUTH_REQUIRED above? (In 2 places)


In Section 8.1:

I suggest deleting the table of registered values from this section before the document is published as an RFC. This would avoid confusion if the corresponding IANA registry becomes out of sync with this table.

Section 1:

   Also, problems like combining a key with the long-term secrets or
   proving the identity of the user are common to multiple mechanisms.

Editorial -- proving the identity is not a problem. Maybe this sentence
needs to be reformulated.

Section 1:

   The PA-DATA typed hole may be used to carry
   extensions to Kerberos that have nothing to do with proving the
   identity of the user or establishing a reply key.

Wouldn't an applicability note be appropriate here to specify
what kinds of extensions are appropriate?

Section 3.1:

   The following information is maintained by the client and KDC as each
   request is being processed:

   o  ...
   o  How strongly the identity of the client has been authenticated

Isn't there also the need to store the identity that was used in
pre-authentication, in case the client has several suitable
identities? Also, I suspect that the client does not really know
"how strongly" it has been authenticated. It might be better to say
"o  What authentication mechanism and identities were used to 
authenticate the client." Finally, later in the document you talk
about optional mechanisms that can indicate successful authentication
of the client's identity. Do you need to maintain a record of
both what authentication was used and what indication was gotten?

Section 3.1:

   If a mechanism
   indicates that the reply is not verified then the client
   implementation MUST return an error unless a subsequent mechanism
   verifies the reply.  The KDC needs to track this state so it can
   avoid generating a reply that is not verified.

Who is the client returning an error to, the user, or the KDC? How
does the client know that a subsequent mechanism might be verifying
something, i.e., when do you know you have failed verification?

Section 3.1:

   The KDC SHOULD NOT send data that is encrypted in the long-term
   password-based key of the principal.  Doing so has the same security
   exposures as the Kerberos protocol without pre-authentication.  There
   are few situations where the KDC needs to expose cipher text
   encrypted in a weak key before the client has proven knowledge of
   that key, and pre-authentication is desirable.

There are few situations, and this is not one of them? What does the
text part ", and pre-authentication is desirable" mean above? I'm not
sure I understand...

Section 3.3:

   If a client
   chooses to ignore a padata it MUST NOT process the padata, allow the
   padata to affect the pre-authentication state, nor respond to the
   padata.

I.e., if the client chooses to ignore padata then it must ignore padata?

Section 4:

   In order to avoid this problem,
   extensions that change core semantics are typically divided into two
   parts.  The first part proposes a change to the core semantic--for
   example proposes a new reply key.  The second part acknowledges that
   the extension is understood and that the change takes effect.

Shouldn't this be formulated as a requirement?

Section 4.3:

   In the case of this facility
   it will likely be the case for both sides to know that the facility
   is available by the time that the new key is available to be used.

Only likely, not certain? Perhaps you should explain the conditions
under which this works correctly.

Section 5.1:

   An early design goal of Kerberos
   Version 5 [RFC4120] was to avoid encrypting more of the
   authentication exchange that was required.

Should this be s/more ... that/more ... than/?

Section 6.4.2:

   This checksum MUST
   be a keyed checksume and it is included in order to bind the FAST
   padata to the outer request. 

s/checksume/checksum/

Please consider clarifying the first paragraph of 4.4 (particularly the sentence starting "Note that the client machine").

Also consider additional clarity around "clients MUST be prepared for tokens somewhat larger than the size of all messages in conversation". Does that mean all the messages in _this_ conversation so far? If so, is it the maximum or sum of previous messages? Or was the intent simply to tell implementers to slightly more than double the size of the buffers they were previously allocating?

  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.

In section 9, I couldn't parse 1st sentence of 2nd paragraph (maybe the "to" is extraneous): "Regarding to the facilities provided by the Encrypted Challenge FAST factor, the challenge key "

In section 6.4.1.1 and 9: r/fast factor/FAST factor (x5)