Subject: CONSENSUS CALL: binding AS-REQ and AS-REP in PKINIT

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Aug 2005 19:07:35 +0200

>From the summary of our meeting in Paris:

> - Andre Scedrov (UPenn) and Aaron Jaggard (Tulane) have been doing formal
>   analysis of Kerberos protocols, and gave a presentation on a problem
>   they found in PKINIT in RSA mode.  They described two approaches which
>   they believe would fix the problem.  One involves having the KDC sign
>   the AS-REQ; the other involves having it sign the client's identity.
>   The former approach is essentially what Larry has proposed in pkinit-27,
>   and they believe that will fix the problem.
>
>   After some discussion, there was general agreement that the approach
>   taken by pkinit-27 was acceptable, and to a certain extent even
>   preferred.

If this approach is selected, the editor will fix the problem mentioned in 
the WG meeting regarding placing normative requirements in ASN.1 comments.

This message serves as a consensus call to validate the conclusion reached 
during the working group meeting.  Please indicate whether you support the 
approach to solving this problem which is embodied in PKINIT-27.

-- Jeff

---

From: Brian Tung <[email-masked]>
Date: Wed, 10 Aug 2005 15:37:15 -0700

> approach to solving this problem which is embodied in PKINIT-27.

As you might expect, I support the approach given in pk-init-27.

-- 
Brian Tung <[email-masked]>
USC Information Sciences Institute

---

From: [email-masked]
Date: Fri, 12 Aug 2005 08:44:10 -0500 (CDT)

Hi all,

> the WG meeting regarding placing normative requirements in ASN.1 comments.

As requested in Paris, here is some draft text addressing this issue.

Best regards,  Iliano, Aaron, Andre, Joe, and Chris

======================================
3.2.1  Generation of Client Request

   The initial authentication request (AS-REQ) is sent as per [RFC4120];
   in addition, a pre-authentication data element, whose padata-type is
   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
   type PA-PK-AS-REQ, is included.

Suggestion: Add a sentence to the above:

"If the client requests Public Key Encryption (instead of Diffie-Hellman
key generation/reuse), then the client MUST save the entire request
message in order to later verify the keyed checksum in the reply."

======================================
3.2.4  Receipt of KDC Reply

   Upon receipt of the KDC's reply, the client proceeds as follows.  If
   the PA-PK-AS-REP contains the dhSignedData field, the client derives
   the AS reply key using the same procedure used by the KDC as defined
   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
   field, and the client decrypts and extracts the temporary key in the
   encryptedKey field of the member KeyTransRecipientInfo, and then uses
   that as the AS reply key.

Suggestion: In the last sentence, replace "." with

"; in this case, the client MUST verify the asChecksum contained in the
ReplyKeyPack before using the AS reply key.  (If this check is not
performed, there is no guarantee that the AS-REP was generated in
response to the client's AS-REQ; this allows an attacker to learn the
temporary and AS reply keys in the reply.)"

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Aug 2005 18:20:19 -0400

On Wednesday, August 10, 2005 03:37:15 PM -0700 Brian Tung <[email-masked]> 
wrote:

> Jeffrey Hutzelman wrote:
>> If this approach is selected, the editor will fix the problem mentioned
>> in  the WG meeting regarding placing normative requirements in ASN.1
>> comments.
>>
>> This message serves as a consensus call to validate the conclusion
>> reached  during the working group meeting.  Please indicate whether you
>> support the  approach to solving this problem which is embodied in
>> PKINIT-27.
>

Well, at least someone replied.
Given that most of the people who've been active in this effort were at the 
meeting, I'm going to call this if I don't see any objections here in the 
next couple of days.

-- Jeff

---

From: "Aaron D. Jaggard" <[email-masked]>
Date: Thu, 18 Aug 2005 16:22:00 -0500

Hi all,

As we're writing up the PKINIT binding issue it appears that, in PKINIT
RSA mode, the client's signature key may be different from the client's
decryption key.  Is this a correct reading of the various specs?

Thanks very much,  Iliano, Aaron, Andre, Joe, and Chris

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 26 Aug 2005 18:20:54 +0200

> decryption key.  Is this a correct reading of the various specs?

It used to be that way, but that part of the ASN.1 data was dropped. If
there still is text that hints that is the way still, I guess it should be
clarified so it doesn't confuse anyone.

It was there so the client could have two rsa key, one for signing and one
for encryption. But since the encryption certifiate was outside the
signedData and there was no real text on how to determin that this was the
certifiate to use, it was killed out.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 19:41:37 -0400

On Wednesday, August 17, 2005 06:20:19 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

>
>
> On Wednesday, August 10, 2005 03:37:15 PM -0700 Brian Tung
> <[email-masked]> wrote:
>
>> Jeffrey Hutzelman wrote:
> Given that most of the people who've been active in this effort were at
> the meeting, I'm going to call this if I don't see any objections here in
> the next couple of days.

OK, so I gave it more than a couple of days.  I'm declaring consensus on 
this.  For reference, this is ticket #1063.

-- Jeff