A Generalized Framework for Kerberos Pre-Authentication
draft-ietf-krb-wg-preauth-framework-17

[Ballot comment]
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/

[Ballot discuss]
I liked this specification, it was very well and carefully written.
I did have a few observations about the text that should probably
be dealt with somehow -- look at my comments.

I also had one bigger issue that I wanted to discuss before recommending
the approval of the specification. Is there some kind of mandatory-to-
implement mechanism/factor set? Wouldn't this be necessary to ensure
interoperability?

[Ballot comment]
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/

[Ballot 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.

[Ballot 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?

[Ballot comment]
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/?

[Ballot comment]
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?

[Ballot comment]
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."

[Ballot comment]
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)

[Ballot comment]
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?

[Ballot comment]
Please consider clarifying the first paragraph of 4.4 (particularly the sentence starting "Not 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?

[Ballot comment]
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/

[Ballot comment]
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.

IANA questions/comments:


Questions:

- A number of registrations have no reference. How/where are they
defined? Shouldn't every registration have a reference (or refer to
this document)?

- Many of the references in Action 1 are not clear about which
document is referred to. E.g. entries like (sam/opt), (referrals),
MS-KILE, etc are non-normative. Can you be more explicit about your
references?

- Pleave verify that the new items in Section 7 get added to the
private Kerberos registries, which IANA does not maintain at this
time.


Action 1 (section 8.1):

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml

Registry Name: PreAuthentication and Typed Data
Allocation Procedures: Expert Review and IETF Review

Expert review for pre-authentication mechanisms designed to
authenticate users, KDCs, or establish the reply key. The expert
first determines that the purpose of the method is to authenticate
clients, KDCs, or to establish the reply key. If so, expert review
is appropriate. The expert evaluates the security and
interoperability of the specification.

IETF review is required if the expert believes that the pre-
authentication method is broader than these three areas.

Initial contents of this sub-registry will be:

Type Value Reference
----------------------------------------------------------------------
PA-TGS-REQ 1 RFC 4120
PA-ENC-TIMESTAMP 2 RFC 4120
PA-PW-SALT 3 RFC 4120
[reserved] 4
PA-ENC-UNIX-TIME 5 (deprecated)
PA-SANDIA-SECUREID 6
PA-SESAME 7
PA-OSF-DCE 8
PA-CYBERSAFE-SECUREID 9
PA-AFS3-SALT 10
PA-ETYPE-INFO 11 RFC 4120
PA-SAM-CHALLENGE 12 (sam/otp)
PA-SAM-RESPONSE 13 (sam/otp)
PA-PK-AS-REQ_OLD 14 draft-ietf-cat-kerberos-pk-init-09
PA-PK-AS-REP_OLD 15 draft-ietf-cat-kerberos-pk-init-09
PA-PK-AS-REQ 16 RFC 4556
PA-PK-AS-REP 17 RFC 4556
PA-PK-OCSP-RESPONSE 18 RFC 4557
PA-ETYPE-INFO2 19 RFC 4120
PA-USE-SPECIFIED-KVNO 20
PA-SVR-REFERRAL-INFO 20 (referrals)
PA-SAM-REDIRECT 21 (sam/otp)
PA-GET-FROM-TYPED-DATA 22 (embedded in typed data)
TD-PADATA 22 (embeds padata)
PA-SAM-ETYPE-INFO 23 (sam/otp)
PA-ALT-PRINC 24 (crawdad@fnal.gov)
PA-SERVER-REFERRAL 25 (referrals)
PA-SAM-CHALLENGE2 30 (kenh@pobox.com)
PA-SAM-RESPONSE2 31 (kenh@pobox.com)
PA-EXTRA-TGT 41 Reserved extra TGT
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
TD-KRB-PRINCIPAL 102 PrincipalName
TD-KRB-REALM 103 Realm
TD-TRUSTED-CERTIFIERS 104 PKINIT
TD-CERTIFICATE-INDEX 105 PKINIT
TD-APP-DEFINED-ERROR 106 Application specific
TD-REQ-NONCE 107 INTEGER
TD-REQ-SEQ 108 INTEGER
PA-PAC-REQUEST 128 MS-KILE
PA-FOR_USER 129 MS-KILE
PA-FOR-X509-USER 130 MS-KILE
PA-FOR-CHECK_DUPS 131 MS-KILE
PA-AS-CHECKSUM 132 MS-KILE
PA-FX-COOKIE 133 draft-ietf-krb-wg-preauth-framework
PA-AUTHENTICATION-SET 134 draft-ietf-krb-wg-preauth-framework
PA-AUTH-SET-SELECTED 135 draft-ietf-krb-wg-preauth-framework
PA-FX-FAST 136 draft-ietf-krb-wg-preauth-framework
PA-FX-ERROR 137 draft-ietf-krb-wg-preauth-framework
PA-ENCRYPTED-CHALLENGE 138 draft-ietf-krb-wg-preauth-framework
PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com)
PA-OTP-REQUEST 142 (gareth.richards@rsa.com)
PA-OTP-CONFIRM 143 (gareth.richards@rsa.com)
PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com)
PA-EPAK-AS-REQ 145 (sshock@gmail.com)
PA-EPAK-AS-REP 146 (sshock@gmail.com>)
PA_PKINIT_KX 147 draft-ietf-krb-wg-anon
PA_PKU2U_NAME 148 draft-zhu-pku2u
PA-SUPPORTED-ETYPES 165 MS-KILE
PA-EXTENDED_ERROR 166 MS-KILE


Action 2 (section 8.2):

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml

Registry Name: Fast Armor Types
Registration Procedures: Standards Action
Initial contents of this registry will be:

Type Name Description Reference
------------------------------------------------------------ --------
0 Reserved.
[RFC-krb-wg-preauth-framework-15]
1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req.
[RFC-krb-wg-preauth-framework-15]


Action 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml

Registry Name: Fast Options
Registration Procedures: Standards Action
Initial contents of this registry will be:

Type Name Description Reference
------------------------------------------------------------------- ---------
0 RESERVED Reserved for future expansion of this
[RFC-krb-wg-preauth-framework-15]
field.
1 hide-client-names Requesting the KDC to hide client
[RFC-krb-wg-preauth-framework-15]
names in the KDC response
16 kdc-follow-referrals reserved
[RFC-krb-wg-preauth-framework-15]


We understand the above to be the only IANA Actions for this document.

This is a request to the IESG to approve publication of
"A Generalized Framework for Kerberos Pre-Authentication",
draft-ietf-krb-wg-preauth-framework-15.txt, as a Standards-Track RFC.
This document is a product of the Kerberos Working Group.

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

      >> The Document Shepherd for this document is Jeffrey Hutzelman,
      >> .  I have reviewed this document, and I believe
      >> it is ready for IETF-wide review and publication as a
      >> Proposed Standard.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

      >> This document has received review both within the working group
      >> and from key experts outside the working group.  Any issues raised
      >> have been resolved.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

      >> I don't believe any particular outside review is required.
      >> Of course, more review is always welcome.

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.  Has an IPR disclosure related to this document
      been filed?  If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

      >> I have no concerns.
      >> No IPR disclosures related to this document have been filed.

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

      >> There is concensus within the working group to publish this
      >> document on the standards track.  I believe there is strong
      >> consensus for the preauthentication model and framework
      >> described in this document.
      >>
      >> The FAST mechanism described in section 6.4 is conceptually
      >> separable from the rest of the document, and so I discuss
      >> it separately here.  There is consensus in the working group
      >> to publish this mechanism, and on the details of its design,
      >> at least among those who have contributed to or reviewed it.
      >> There is a somewhat rougher consensus to place this mechanism
      >> on the standards track and to require its implementation by
      >> Kerberos implementations conforming to the preauth framework.
      >>
      >> It is worth noting that a partial overlap exists between the
      >> functionality of the FAST mechanism, which provides an encrypted
      >> tunnel to protect exchange of preauthentication data between
      >> a client and KDC, and that of the Kerberos STARTTLS extension,
      >> draft-josefsson-kerberos5-starttls-07.txt, which is also a
      >> document of this working group.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

      >> There have been no expressions of discontent.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

      >> This document has been run through the idnits tool, and was
      >> reviewed manually for compliance with requirements not checked
      >> by the automatic tool.  No additional formal review criteria
      >> apply to this document.
      >>
      >> In addition to RFC2119 requirements language, this document
      >> contains numerous uses of lowercase "may", "should", and
      >> "required", which are not intended to carry the RFC2119
      >> meanings of the uppercase terms.  These are used in contexts
      >> where requirements language is neither intended or appropriate,
      >> such as advice to the reader or to future pre-authentication
      >> mechanism designers, when discussing scenarios which provide
      >> background for a design decision or requirement, or when
      >> discussion potential constraints imposed by policy rather
      >> than by the protocol.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

      >> References have been split appropriately.
      >> This document contains a normative reference to
      >> draft-ietf-krb-wg-anon, which is awaiting a new WGLC

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggest a
      reasonable name for the new registry?  See [RFC2434].  If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

      >> This document creates three new registries, for Kerberos
      >> preauthentication and typed-data types, for FAST armor types,
      >> and for FAST options.  The first creates an IANA registry
      >> for a namespace previously managed directly by the Kerberos
      >> working group; the others are new namespaces created by this
      >> document.  In all three cases, suitable names are suggested,
      >> initial contents included, and an appropriate registration
      >> policy is specified.

      >> The current maintainer of the PA-DATA/TYPED-DATA registry,
      >> which this document turns over to IANA, is in the process of
      >> reconciling the initial IANA registry contents contained in
      >> this document with his existing records.  We expect this will
      >> result in minor changes to the initial registry contents by
      >> the time the final document is published.

      >> This document allocates new values in several namespaces which
      >> are currently managed directly by the Kerberos working group
      >> rather than as IANA registries.  Transferring these registries
      >> to IANA control is a work in progress but is not the subject
      >> of this document.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

      >> This document contains an ASN.1 module, which in the current
      >> version does not compile.  Corrections have been made in the
      >> author's copy and will be included the next update (presumably,
      >> along with changes to address any issues raised during IETF
      >> Last Call).

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Write-Up?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:


Technical Summary

  Kerberos is a protocol for verifying the identity of principals
  (e.g., a workstation user or a network server) on an open network.
  The Kerberos protocol provides a mechanism called pre-authentication
  for proving the identity of a principal and for better protecting the
  long-term secrets of the principal.

  This document describes a model for Kerberos pre-authentication
  mechanisms.  The model describes what state in the Kerberos request a
  pre-authentication mechanism is likely to change.  It also describes
  how multiple pre-authentication mechanisms used in the same request
  will interact.

  This document also provides common tools needed by multiple pre-
  authentication mechanisms.  One of these tools is a secure channel
  between the client and the KDC with a reply key strengthening
  mechanism; this secure channel can be used to protect the
  authentication exchange thus eliminate offline dictionary attacks.
  With these tools, it is relatively straightforward to chain multiple
  authentication mechanisms, utilize a different key management system,
  or support a new key agreement algorithm.


Working Group Summary

  This document represents the consensus of the Kerberos Working Group.


Document Quality

  Multiple vendors have indicated that they plan to implement and ship
  the extensions described in this document or have already begun to
  do so.


Personnel

  The Document Shepherd for this document is Jeffrey Hutzelman.
  The responsible Area Director is Tim Polk.