Subject: [Ietf-krb-wg] PROTO review of draft-ietf-krb-wg-preauth-framework-14.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 Sep 2009 21:01:15 -0400

The following are comments arising from my review of the preauth framework 
document, before sending it to the IESG.  I had a total of 23 comments; 
they're numbered starting at 16 to avoid conflicts with an existing list I 
was using to track last-call issues.

Most of these are substantive, and I'd like to see responses to all of 
them, but none are very serious.  Overall, I believe this is a very good 
document.

-- Jeff

[JTH.16] (Section 3.1) This could use subsection numbering

[JTH.17] (Section 3.1) wrt KDC selecting one of client's enctypes...
         Is there anything to provide enctype downgrade protection?
         Arguably, protected negotiation is not good enough, since
         the battle is already lost if an attacker can convince either
         side to use a weaker enctype than necessary, especially with
         keys derived from passwords.

[JTH.18] (Section 3.1) If the reply key is replaced, knowledge of the
         reply key is not sufficient to authenticate the client.  But
         what about a mechanism like PKINIT, which may derive a new
         reply key using an authenticated DH exchange?  That mech has
         authenticated the client _and_ established a reply key which
         only a real client knows.  Similarly for verifying the KDC
         reply.

[JTH.19] (Section 3.3) Clients SHOULD process padata unrelated to this
         framework.  It seems that that depends on what the padata in
         question is for; this is a _very_ strong statement to make
         about unspecified future protocol extensions unrelated to the
         present document.  I Suggest changing this to MAY.

[JTH.20] (Section 6.1) KRB-FX-CF1 combines pass-phrases by simple
         concatenation.  This means that KRB-FX-CF1("foobar", "baz")
         is the same as KRB-FX-CF1("foo", "barbaz").  Wouldn't it be
         better to use a construction which eliminates this collision?

[JTH.21] (Section 6.1) "The pseudo-random() operation is specified by
         the enctype of the protocol key."  Does this need a RFC3961
         reference?  Perhaps something like the following:

            Here the counter value 1, 2, 3, and so on are encoded as
            a one-octet integer; PRF+() uses the counter to generate
            enough bits as needed by the random-to-key() function for
            the encryption type specified for the resulting key;
            unneeded bits are removed from the tail.  Unless otherwise
            specified, the resulting encryption type of KRB-FX-CF2 is
            the encryption type of K1.

            The pseudo-random() function is as specified for the
            encryption type of each input key, and the random-to-key()
            function is as specified for the encryption type specified
            for the resulting key.  These operations are as described
            in RFC3961.

[JTH.22] (Section 6.2) This looks more like requirements than a tool.
         Perhaps it belongs in Section 5?

[JTH.23] (Section 6.3) The implementation-specific PA-FX-COOKIE format
         needs to consider replay, both within a conversation and across
         conversations.

[JTH.24] (Section 6.3) Why does a KDC have to include a cookie with
         KDC_ERR_PREAUTH_REQUIRED, even when it has no state?  If
         optimistic preauth is going to work, it has to be possible
         to start with the message the client would send after the
         PREAUTH_REQUIRED, and with no PA-FX-COOKIE.

[JTH.25] (Section 6.3) "When FAST is used...".  It seems to me that once
         a cookie is seen, a client can assume that absence of a cookie
         means the KDC is terminating the conversation.  The use of FAST
         is not relevant here.

[JTH.26] (Section 6.3) "if cookies nor FAST are used..."
         I think you mean "if _neither_ cookies nor FAST are used..."

[JTH.27] (Section 6.4) PA-AUTH-SET-SELECTED includes the hints and
         value from the selected authentication set.  This is fine,
         but since at least some of this information is presumably
         freshly generated by the KDC, a cached authentication set
         may "correspond" to one a KDC would offer without matching
         it exactly.  Is this useful?

[JTH.28] (Section 6.5) This sentence looks garbled:
         FAST also provides solutions to common problems for pre-
         authentication mechanisms such as binding of the request
         and the reply, freshness guarantee of the authentication.

[JTH.29] (Section 6.5) This has been a matter of some discussion at
         various points in time.  This section contains the statement
         "Conforming implementations MUST support Kerberos FAST padata".
         This has the effect of making FAST mandatory-to-implement for
         any implementation which supports the preauth framework.  Is
         that what we intend?

[JTH.30] (Section 6.5.1.1) The last statement in this section, "Only
         implicit armors are allowed in the TGS at this time", seems
         to be given out of context.  Reading the document, I cannot
         tell what this statement is supposed to mean.  I suspect it
         is intended to mean that, for a TGS request, the only possible
         means of selecting the armor key are those described in the
         bullet point at the bottom of page 27, in which the 'armor'
         element of KrbFastArmoredReq is omitted.  If this is the case,
         perhaps this statement belongs at the end of that paragraph,
         instead of in section 6.5.1.1.

[JTH.31] (Section 6.5.2) "FAST is not expected to be used in an
         authentication set: clients will typically use FAST padata
         if available and this decision should not depend on what
         other pre-authentication methods are available."
         In other words, FAST itself is _not_ a preauth mechanism
         conforming to the framework defined in the present document,
         though it is a tool which may, among other things, be used
         to build such a mechanism.

[JTH.32] (Section 6.5.2) I'm questioning, again, the assignment of
         the kdc-follow-referrals option in this document.  Since
         this will fairly clearly progress sooner than referrals,
         wouldn't it make more sense to include that assignment in
         referrals?

[JTH.33] (Section 6.5.3) "The Kerberos client who does not receive a
         PA-FX-FAST-REPLY in the KDC response MUST support a local
         poplicy that rejects the response".  So, I don't have to
         implement that feature until someone sends me such a message?
         :-)

[JTH.34] (Section 6.5.3) "Unless otherwise specified, the KDC MUST
         include any padata that is otherwise in the outer KDC-REP
         structure into this [KrbFastResponse.padata] field".  This
         is fine, except won't most PA-FX-FAST-REPLY messages be
         carried in KRB-ERROR, rather than KDC-REP?

[JTH.35] (Section 6.5.3) "The client need not confirm that the
         timestamp returned is within allowable clock skew".  Perhaps
         this should say "SHOULD NOT" instead of "need not", if we
         want ensure that clients don't start doing unnecessary time
         skew checks and thereby break things.

[JTH.36] (Section 6.5.3) "When FAST padata is included, the PA-FX-COOKIE
         padata... MUST be included...".  Just to be doubly clear, this
         means that when FAST is used, the cookie is in the inner padata
         list, rather than the outer, correct?

[JTH.37] (Section 6.5.6)  The use of PA-ENC-TS-ENC might benefit from
         a reference to RFC4120 section 5.2.7.2.

[JTH.38] (Section 6.6) Surely AD-authentication-strength need only
         include a list of the preauth mechanisms used, and not the
         complete PA-AUTHENTICATION-SET data including hints and values?

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2009 08:47:36 -0400

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

    Jeffrey> [JTH.35] (Section 6.5.3) "The client need not confirm that the
    Jeffrey>         timestamp returned is within allowable clock skew".  Perhaps
    Jeffrey>         this should say "SHOULD NOT" instead of "need not", if we
    Jeffrey>         want ensure that clients don't start doing unnecessary time
    Jeffrey>         skew checks and thereby break things.

I'd support this change, but I want to see explicit support from someone else before making a requirement.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2009 08:53:39 -0400

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

    Jeffrey> [JTH.20] (Section 6.1) KRB-FX-CF1 combines pass-phrases by simple
    Jeffrey>         concatenation.  This means that KRB-FX-CF1("foobar", "baz")
    Jeffrey>         is the same as KRB-FX-CF1("foo", "barbaz").  Wouldn't it be
    Jeffrey>         better to use a construction which eliminates this collision?

I agree this would be an improvement.  However I think there is a
presumption of consensus behind the current text because while it
could be improved it's not broken and because it has made it past
WGLC.  So, we'd need to see support from the WG for this change.  This
is particularly true because it would be a non-interoperable change in
an area where there is no negotiation mechanism.

If we're going to make a change here, I wonder whether the right
change would be to drop the mechanism entirely.  So far it's not being
used.

Thoughts?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2009 09:10:39 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
    Jeffrey> [JTH.19] (Section 3.3) Clients SHOULD process padata unrelated to this
    Jeffrey>         framework.  It seems that that depends on what the padata in
    Jeffrey>         question is for; this is a _very_ strong statement to make
    Jeffrey>         about unspecified future protocol extensions unrelated to the
    Jeffrey>         present document.  I Suggest changing this to MAY.

I think that there may be a wording problem here.

Consider what happens in a KDC with a plugin interface.  The main KDC
code doesn't understand any of the padata types.  It has plugins to
call for each of them though.

The question is which plugins should you call.  The initial answer in
my mind was roughly all of them.  Turns out that's a bad idea.  You
don't for example want to do encrypted timestamp and pkinit at the
same time.

Looking more into this, you basically don't want to do more than one
authentication set of padata intended to authenticate the user.

What we're trying to say above is that such a KDC follows the rules in
the framework for which padata within the framework to process, and
should call the plugin for any non-framework padata type.  Presumably
when plugins register they would indicate whether they are part of the
framework.  (For example in the MIT code this is similar to the
PA_INFO flag, although that's not quite the same).

Now, I'm horribly implementation specific above.

However there is some general concept under that which the spec is
trying to capture.

Another thing to think about is what it means to process something.  I
think it would be reasonable for a KDC to process a non-framework
padata by examining the padata and deciding that for local policy
reasons the requested extension should not be honored.  By process I
roughly mean run the standard code associated with that padata item.

So, I definitely think the wording could be improved here.  The fact
that we're having this discussion calls into question whether the WG
understood the intent here enough to have an informed consensus.  My
personal opinion is that once we clarify the wording, SHOULD is the
right requirement level.

I don't want to block for ever on this.  If we can't find better
wording my preference would be to keep what we have rather than reduce
the requirement level or remove the text.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Sep 2009 11:05:14 -0400

> else before making a requirement.

Me too.  Anyone?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Sep 2009 11:08:36 -0400

> WGLC.  So, we'd need to see support from the WG for this change.

True.

> This

This holds limited weight with me, for a presently-unused feature described 
in an internet-draft.

> change would be to drop the mechanism entirely.  So far it's not being

Anyone?  Unless I see support for either changing this or removing it 
entirely, we'll leave it as-is.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Sep 2009 11:21:53 -0400

--On Wednesday, September 23, 2009 09:10:39 AM -0400 Sam Hartman 
<[email-masked]> wrote:

> ...

Yes, I think you're right.  The goal here, as I understand it, is to make 
it clear that the framework specifies handling only for framework padata, 
and that other things should be processed as usual.

How about something like this...

OLD:
   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
   client MAY ignore any padata it chooses unless doing so violates a
   specification to which the client conforms.  Clients conforming to
   this specification MUST NOT ignore the padata defined in Section 6.3.
   Clients SHOULD process padata unrelated to this framework or other
   means of authenticating the user.  Clients SHOULD choose one
   authentication set or mechanism that could lead to authenticating the
   user and ignore the rest....

NEW:
   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
   client MAY ignore any padata it chooses unless doing so violates a
   specification to which the client conforms.  Clients conforming to
   this specification MUST NOT ignore the padata defined in Section 6.3.
   Clients SHOULD choose one authentication set or mechanism that could
   lead to authenticating the user and ignore other such mechanisms.
   However, this rule does not affect processing of padata unrelated to
   this framework; clients SHOULD process such padata normally.

I'm a bit stuck on what to say instead of "normally", which doesn't really 
carry any content.  I tried "as they would in the absence of this 
framework", but that doesn't really work; there could be a dependency 
involved, and anyway, we hope the framework is eventually always there.

Comments?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Sep 2009 10:19:33 -0400

Jeff, I think your change is an improvement.  I'd like to make it.
How much additional support (if any) do I need?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Sep 2009 15:39:11 -0400

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

    Jeffrey> The following are comments arising from my review of the preauth
    Jeffrey> framework document, before sending it to the IESG.  I had a total of
    Jeffrey> [JTH.16] (Section 3.1) This could use subsection numbering
That's kind of tricky based on how I'm using xml2rfc.
Also, I'd really rather  people actually read all of 3.1 at once.

However you do have a point that it has gotten kind of long.  I'd
definitely consider any concrete suggestions here, especially from
people who take a look at how to implement them in xml2rfc.

    Jeffrey> [JTH.17] (Section 3.1) wrt KDC selecting one of client's enctypes...
    Jeffrey>         Is there anything to provide enctype downgrade protection?
    Jeffrey>         Arguably, protected negotiation is not good enough, since
    Jeffrey>         the battle is already lost if an attacker can convince either
    Jeffrey>         side to use a weaker enctype than necessary, especially with
    Jeffrey>         keys derived from passwords.
FAST provides this once you're using FAST.  Larry's proposal for
negotiating FAST tries to address this for selecting FAST and for
protecting the process used to do that including the initial AS-req
enctype selection.  He doesn't do better than integrity protection
after the fact, but I think that is better than you give it credit
for.  Anyway, within the scope of this draft, use FAST for that
protection.  Deciding how to negotiate FAST is out of scope here.  I
don't think text changes are required.

    Jeffrey> [JTH.18] (Section 3.1) If the reply key is replaced, knowledge of the
    Jeffrey>         reply key is not sufficient to authenticate the client.  But
    Jeffrey>         what about a mechanism like PKINIT, which may derive a new
    Jeffrey>         reply key using an authenticated DH exchange?  That mech has
    Jeffrey>         authenticated the client _and_ established a reply key which
    Jeffrey>         only a real client knows.  Similarly for verifying the KDC

Pkinit implements replace reply key, client auth, and kdc

verification.  You've described true statements about pkinit, but as
far as I can tell not pointed out a defect in the spec in this issue.
I'm assuming you were trying to confirm your understanding, which I
believe is correct.

We have a thread we tried to start on this.

same here.

    Jeffrey> [JTH.21] (Section 6.1) "The pseudo-random() operation is specified by
    Jeffrey>         the enctype of the protocol key."  Does this need a RFC3961
    Jeffrey>         reference?  Perhaps something like the following:

    Jeffrey>            Here the counter value 1, 2, 3, and so on are encoded as
    Jeffrey>            a one-octet integer; PRF+() uses the counter to generate
    Jeffrey>            enough bits as needed by the random-to-key() function for
    Jeffrey>            the encryption type specified for the resulting key;
    Jeffrey>            unneeded bits are removed from the tail.  Unless otherwise
    Jeffrey>            specified, the resulting encryption type of KRB-FX-CF2 is
    Jeffrey>            the encryption type of K1.

    Jeffrey>            The pseudo-random() function is as specified for the
    Jeffrey>            encryption type of each input key, and the random-to-key()
    Jeffrey>            function is as specified for the encryption type specified
    Jeffrey>            for the resulting key.  These operations are as described
    Jeffrey>            in RFC3961.

Seems like a good change.
Sign me up for making it.

    Jeffrey> [JTH.22] (Section 6.2) This looks more like requirements than a tool.
    Jeffrey>         Perhaps it belongs in Section 5?

I'll move to section 5.

    Jeffrey> [JTH.23] (Section 6.3) The implementation-specific PA-FX-COOKIE format
    Jeffrey>         needs to consider replay, both within a conversation and across
    Jeffrey>         conversations.

Sure does.
Pointing this out sounds good.

    Jeffrey> [JTH.24] (Section 6.3) Why does a KDC have to include a cookie with
    Jeffrey>         KDC_ERR_PREAUTH_REQUIRED, even when it has no state?  

Because that's how the WG discussion came out.  We fiddled around with
this going back and forth on what a conversation was and ended up with
this text.  It's been tested, and it is one of the trickier parts to
get right in an implementation.  I don't think that the particular
solution we arrived at makes it more or less tricky: I think the
problem of a stateful client and stateless KDC is inherently tricky.
So, while there are many other things that we could have done, I think
making a decision here and sticking with it is the right approach.

    Jeffrey>         If
    Jeffrey>         optimistic preauth is going to work, it has to be possible
    Jeffrey>         to start with the message the client would send after the
    Jeffrey>         PREAUTH_REQUIRED, and with no PA-FX-COOKIE.

Yes.  I'm fairly sure this is discussed in 3.2 and so forth.

    Jeffrey> [JTH.25] (Section 6.3) "When FAST is used...".  It seems to me that once
    Jeffrey>         a cookie is seen, a client can assume that absence of a cookie
    Jeffrey>         means the KDC is terminating the conversation.  The use of FAST
    Jeffrey>         is not relevant here.

That's probably true, although current implementations seem to trigger
off FAST rather than off having seen a cookie.  So, I think the spec
matches reality better in its current form.  I'd be happy to point out
that once you've seen a cookie you will continue to see one until
conversation termination.

    Jeffrey> [JTH.26] (Section 6.3) "if cookies nor FAST are used..."
    Jeffrey>         I think you mean "if _neither_ cookies nor FAST are used..."

Will make the change.

    Jeffrey> [JTH.27] (Section 6.4) PA-AUTH-SET-SELECTED includes the hints and
    Jeffrey>         value from the selected authentication set.  This is fine,
    Jeffrey>         but since at least some of this information is presumably
    Jeffrey>         freshly generated by the KDC, a cached authentication set
    Jeffrey>         may "correspond" to one a KDC would offer without matching
    Jeffrey>         it exactly.  Is this useful?

rephrase?
What change do you want made?
I think your understanding is correct here.

    Jeffrey> [JTH.28] (Section 6.5) This sentence looks garbled:
    Jeffrey>         FAST also provides solutions to common problems for pre-
    Jeffrey>         authentication mechanisms such as binding of the request
    Jeffrey>         and the reply, freshness guarantee of the authentication.
Missing and; will fix.

    Jeffrey> [JTH.29] (Section 6.5) This has been a matter of some discussion at
    Jeffrey>         various points in time.  This section contains the statement
    Jeffrey>         "Conforming implementations MUST support Kerberos FAST padata".
    Jeffrey>         This has the effect of making FAST mandatory-to-implement for
    Jeffrey>         any implementation which supports the preauth framework.  Is
    Jeffrey>         that what we intend?

As an individual I strongly support that statement.

    Jeffrey> [JTH.30] (Section 6.5.1.1) The last statement in this section, "Only
    Jeffrey>         implicit armors are allowed in the TGS at this time", seems
    Jeffrey>         to be given out of context.  Reading the document, I cannot
    Jeffrey>         tell what this statement is supposed to mean.  I suspect it
    Jeffrey>         is intended to mean that, for a TGS request, the only possible
    Jeffrey>         means of selecting the armor key are those described in the
    Jeffrey>         bullet point at the bottom of page 27, in which the 'armor'
    Jeffrey>         element of KrbFastArmoredReq is omitted.  If this is the case,
    Jeffrey>         perhaps this statement belongs at the end of that paragraph,
    Jeffrey>         instead of in section 6.5.1.1.

I'll look at this.
Your understanding is correct, I just want to consider whether 6.5.1.1 should also discuss this.

    Jeffrey> [JTH.31] (Section 6.5.2) "FAST is not expected to be used in an
    Jeffrey>         authentication set: clients will typically use FAST padata
    Jeffrey>         if available and this decision should not depend on what
    Jeffrey>         other pre-authentication methods are available."
    Jeffrey>         In other words, FAST itself is _not_ a preauth mechanism
    Jeffrey>         conforming to the framework defined in the present document,
    Jeffrey>         though it is a tool which may, among other things, be used
    Jeffrey>         to build such a mechanism.

I'm not sure whether I agree with this statement.
I think I can construct arguments before and against.
However it doesn't sound like you are asking for any changes, so I'm not sure why it matters.

    Jeffrey> [JTH.32] (Section 6.5.2) I'm questioning, again, the assignment of
    Jeffrey>         the kdc-follow-referrals option in this document.  Since
    Jeffrey>         this will fairly clearly progress sooner than referrals,
    Jeffrey>         wouldn't it make more sense to include that assignment in
    Jeffrey>         referrals?

That would also be fine.
Let me know what to do here.

    Jeffrey> [JTH.33] (Section 6.5.3) "The Kerberos client who does not receive a
    Jeffrey>         PA-FX-FAST-REPLY in the KDC response MUST support a local
    Jeffrey>         poplicy that rejects the response".  So, I don't have to
    Jeffrey>         implement that feature until someone sends me such a message?
    Jeffrey>         :-)

Will fix.
Much easier than supporting a protocol mechanism for downloading the policy option if it becomes needed.

    Jeffrey> [JTH.34] (Section 6.5.3) "Unless otherwise specified, the KDC MUST
    Jeffrey>         include any padata that is otherwise in the outer KDC-REP
    Jeffrey>         structure into this [KrbFastResponse.padata] field".  This
    Jeffrey>         is fine, except won't most PA-FX-FAST-REPLY messages be
    Jeffrey>         carried in KRB-ERROR, rather than KDC-REP?

Yes.
Will clarify.

I think we have a thread open on this.

    Jeffrey> [JTH.36] (Section 6.5.3) "When FAST padata is included, the PA-FX-COOKIE
    Jeffrey>         padata... MUST be included...".  Just to be doubly clear, this
    Jeffrey>         means that when FAST is used, the cookie is in the inner padata
    Jeffrey>         list, rather than the outer, correct?

Yes.

    Jeffrey> [JTH.37] (Section 6.5.6)  The use of PA-ENC-TS-ENC might benefit from
    Jeffrey>         a reference to RFC4120 section 5.2.7.2.
OK.

    Jeffrey> [JTH.38] (Section 6.6) Surely AD-authentication-strength need only
    Jeffrey>         include a list of the preauth mechanisms used, and not the
    Jeffrey>         complete PA-AUTHENTICATION-SET data including hints and values?

Will fix.

If anyone thinks we had a wg consensus for the full data, please speak
up.  I personally think that we just didn't think this through.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Sep 2009 17:15:01 -0400

> Also, I'd really rather  people actually read all of 3.1 at once.

I'm not sure I understand.  It seems like it should work to just add an
additional level of <section> tags where appropriate.  On re-reading, it
doesn't actually seem very long.  I suspect I was mostly thinking about
making it easier to reference specific parts of this section.

> enctype selection.

OK.

> I'm assuming you were trying to confirm your understanding, which I

This may have just been based on a misunderstanding on my part of what was
meant by "authenticate the client".  Certainly knowing the client's 
long-term
key proves its identity, while knowing some ephemeral replacement does not
inherently do so.  But, knowing the reply key established by PKINIT _does_
prove the client's identity, since the key came from a signed DH and only
the client could know that key.  Shouldn't a hypothetical preauth mech that
runs after PKINIT still be able to assume that knowledge of the reply key
authenticates the client, even though the key has been replaced?

> We have a thread we tried to start on this.

Yes; I think we're getting somewhere on this one.

>     Jeffrey> [JTH.20] (Section 6.1) KRB-FX-CF1 combines pass-phrases by 
simple

I've seen no other replies on this one, and I think we need one to either 
change
the function or remove it from the document.  So, it looks like it stays 
as-is
for now.  If the document advances to draft without this being used, we'll 
have
to remove it then.  In the meantime, if/when we need something better, we'll
define it.

> making a decision here and sticking with it is the right approach.

Yup.  We discussed this offline and I think I agree it's better to leave
this alone.

> conversation termination.

That seems odd.  What if you're using a paset that doesn't involve FAST?

> I think your understanding is correct here.

I probably didn't copy enough.  We require the client to send the selected
paset exactly, without reencoding.  The reason given for this is to allow
the KDC to perform bit-for-bit comparison.  But in practice, since the KDC
is stateless, it might generate an equivalent paset but with different
hints and/or initial value, which would not compare equally bit-for-bit.
This may especially be the case when the client is using a cached response
to optimistically select a paset.  So, I guess the question is, is it
actually appropriate to require a bit-for-bit copy, and if so, do we need
to call out that bit-for-bit comparison by the KDC might be too strict?

> However it doesn't sound like you are asking for any changes, so I'm not 
sure why it matters.

I'm not asking for any changes; just trying to confirm my understanding.