Subject: Re: [Ietf-krb-wg] pkinit alg agility and ticket in checksum

From: Greg Hudson <[email-masked]>
Date: Wed, 04 May 2011 11:09:49 -0400

On Fri, 2011-04-29 at 14:25 -0400, Sam Hartman wrote:
> Then there's the question of what the pkinit agility draft should do.
> Certainly, integrity protecting the ticket is nice.
> However being able to implement without re-architecting your
> implementation is also nice.

My preference is that the agility draft not add integrity protection for
the ticket.

By referencing the final form of the ticket, pkinit takes on a job more
properly belonging to protocol frameworks (specifically FAST).  The cost
is more required interplay between the preauth and authdata handling
systems of KDCs.

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 04 May 2011 11:09:41 -0700

> is more required interplay between the preauth and authdata handling

Is there a proposed alterative to bind the key to the exchange or is using the random seed from the KDC/client enough ?

Love

---

From: Greg Hudson <[email-masked]>
Date: Wed, 04 May 2011 18:18:01 -0400

On Wed, 2011-05-04 at 14:09 -0400, Love Hörnquist Åstrand wrote:
> Is there a proposed alterative to bind the key to the exchange or is
> using the random seed from the KDC/client enough ?

I think what RFC 4556 uses (client and server DH nonce if DH keys are
being reused) is sufficient for new KDFs, unless we're aware of a
vulnerability there.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 18:25:44 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Wed, 2011-05-04 at 14:09 -0400, Love Hörnquist Åstrand wrote:
    >> Is there a proposed alterative to bind the key to the exchange or
    >> is using the random seed from the KDC/client enough ?

    Greg> I think what RFC 4556 uses (client and server DH nonce if DH
    Greg> keys are being reused) is sufficient for new KDFs, unless
    Greg> we're aware of a vulnerability there.

Actually, that brings up an interesting point.
draft-ietf-krb-wg-pkinit-alg-agility does not actually describe how the
DH nonces influence the KDF.

I can see two approaches:

1) including them in z just as RFC 4556 does.

2) Include them in SupPubInfo.

I wonder how comfortable NIST would be including things other than the
secret in the secret.
Would it be advisable to run this by NIST, or do we want to just pick?

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 04 May 2011 15:26:57 -0700

> Would it be advisable to run this by NIST, or do we want to just pick?

I would say 2 and always included them.

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 19:18:03 -0400

Well, I think they should only be included when they are used: in
situations where both the client and KDC choose to use DH nonces.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Wed, 11 May 2011 13:16:07 -0400 (EDT)

> I would say 2 and always included them.

PkinitSuppPubInfo already includes the as-req, which includes the
clientDHNonce if one was present, and the PA-PK-AS-REP, which includes
the serverDHNonce if one is present.  Is there any need to include
them specifically?

I don't think so, so my proposal is just to remove the ticket (and the
... trailer, which is pointless for a structure that won't be
decoded):

 PkinitSuppPubInfo ::= SEQUENCE {
          enctype           [0] Int32,
              -- The enctype of the AS reply key.
          as-REQ            [1] OCTET STRING,
              -- This contains the AS-REQ in the request.
          pk-as-rep         [2] OCTET STRING
              -- Contains the DER encoding of the type
              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
 }

If there is a reason to include them specifically, the structure would
look like this:

 PkinitSuppPubInfo ::= SEQUENCE {
          enctype           [0] Int32,
              -- The enctype of the AS reply key.
          as-REQ            [1] OCTET STRING,
              -- This contains the AS-REQ in the request.
          pk-as-rep         [2] OCTET STRING,
              -- Contains the DER encoding of the type
              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
          clientDHNonce     [3] DHNonce OPTIONAL,
              -- Client nonce, if one was present in the
              -- request's AuthPack
          serverDHNonce     [4] DHNonce OPTIONAL
              -- Server nonce, if one is present in the
              -- reply's DHRepInfo
 }
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 May 2011 19:14:28 -0400

This starts a consensus call on whether to accept Greg's proposal to
remove ticket from the SuppPubInfo structure. I'd appreciate comments by
25 May.

The specific proposal is attached below: