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

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Oct 2009 08:52:13 -0400

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

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

    Jeffrey> This may have just been based on a misunderstanding on my part of what was
    Jeffrey> meant by "authenticate the client".  Certainly knowing the client's
    Jeffrey> long-term
    Jeffrey> key proves its identity, while knowing some ephemeral replacement does not
    Jeffrey> inherently do so.  But, knowing the reply key established by PKINIT _does_
    Jeffrey> prove the client's identity, since the key came from a signed DH and only
    Jeffrey> the client could know that key.  Shouldn't a hypothetical preauth mech that
    Jeffrey> runs after PKINIT still be able to assume that knowledge of the reply key
    Jeffrey> authenticates the client, even though the key has been replaced?
No, I don't think that would be reasonable.  Pkinit authenticates the
client.  The fact that some later mechanism also uses that reply key
does not strengthen the authentication in the same way that using the
long-term key--or a strengthened but not replaced reply key--does
authenticate the client.  Put another way, you don't get anything
stronger than pkinit from the pkinit reply key.

    Jeffrey> [JTH.25] (Section 6.3) "When FAST is used...".  It
    >> seems to 
    Jeffrey> me that once
    Jeffrey> a cookie is seen, a client can assume that
    >> absence 
    Jeffrey> of a cookie
    Jeffrey> means the KDC is terminating the conversation.
    >> The 
    Jeffrey> 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> That seems odd.  What if you're using a paset that doesn't involve FAST?

I thought you needed to use cookies with auth sets as well.

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

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

Ugh.
The entire point of the above was to allow for bit-for-bit comparison.

I'd rather just not have it work well to use optimistic pre-auth with
mechanisms that require challenges.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 05 Oct 2009 20:25:23 -0400

> stronger than pkinit from the pkinit reply key.

OK, fair enough.

> I thought you needed to use cookies with auth sets as well.

I mean, it seems odd that implementations key on use of FAST rather than
on having seen a cookie.  If you use a paset that doesn't involve FAST,
seeing a message without a still cookie means the conversation is over.

> mechanisms that require challenges.

OK, but consider a stateless KDC and a preauth which does require a
challenge.  To do a bit-for-bit comparison of the client's selected
paset with what it offered, the KDC would have to have a trusted,
bit-for-bit copy of what it offered.  I suppose that information could
be stashed in the cookie.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Oct 2009 10:19:05 -0400

--On Thursday, September 24, 2009 10:19:33 AM -0400 Sam Hartman 
<[email-masked]> wrote:

> Jeff, I think your change is an improvement.  I'd like to make it.
> How much additional support (if any) do I need?

It doesn't change the intent, and I think it was probably well-understood 
within the working group that this document is not intended to alter the 
behavior or processing of unrelated PA-data.  I've also seen no objections 
since this was raised a month ago, so I think it's reasonable for you to go 
ahead with the change.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 17:22:09 -0400

Jeff, a couple of notes.

I believe I've resolved your issues.  However in doing so I had to
make a couple of calls.

1) In the section on ap-request aromr, you asked me to remove a
sentence about only implicit armor being permitted for the TGS.  That
sentence was the result of a fair bit of discussion between Larry and
I.  I think the intent was to make it clear that ap-request armor
cannot be used in a TGS since we sk armor specifications to indicate
whether they can be used in the TGS.
I have the following replacement:
            <t>This armor type is only valid for AS requests; implicit armor, described below in \
            TGS processing, is the only supported way to establish an armor key for the TGS at this time.</t>

2) You proposed that the authorization data describing what
authentication mechanisms are used only include the pa-type, not the
pa-value or pa-hint.  I said KDCs MUST send, clients MUST ignore.  The
intent here is to allow a mechanism to specify a hint for this
sequence in case we want to include the used CA or some oid from the
cert in the future.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Oct 2009 17:33:02 -0400

--On Monday, October 26, 2009 05:22:09 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>             <t>This armor type is only valid for AS requests; implicit
> armor, described below in \             TGS processing, is the only
> supported way to establish an armor key for the TGS at this time.</t>

OK; that sounds good.  IIRC, I was mainly concerned that the original 
statement didn't make much sense where it was.  This sounds better, though 
I haven't yet looked at it in context.

> sequence in case we want to include the used CA or some oid from the

Hm.  That makes sense, though MUST send seems like it might be too strong. 
This, too, I'll have to reread in context.

I'll take a look at the updated document shortly.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 18:04:18 -0400

I believe I've posted a version 15 that is ready to go to Tim,
assuming I didn't mess something up or miss something.  Because of the
deadline I have not checked in with Larry before posting.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg