Subject: PKINIT-18 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 8 Apr 2004 21:49:00 -0700

section 3.2.3.  KDC Reply
 
> The key is derived as follows: Both the KDC and the client calculate
> the value g^(ab) mod p, where a and b are the client's and KDC's
> private exponents, respectively.  They both take the first k bits of
> this secret value as a key generation seed, where the parameter k
> (the size of the seed) is dependent on the selected key type, as
> specified in the Kerberos crypto draft [15].  The seed is then
> converted into a protocol key by applying to it a random-to-key
> function, which is also dependent on key type.

Simply truncating ZZ probably won't preserve the secret entropy. why
don't you use the key generation algorithms specified in RFC 2631? 

3.2.1.  Client Request
> Finally, if the clientPublicValue is filled in, indicating that the
> client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
> checks to see if the parameters satisfy its policy.  

If anyone knows of works that study this ephemeral-ephemeral
Diffie-Hellman mode in detail, I would appreciate pointers.

Thanks,

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Tung
Sent: Tuesday, March 30, 2004 6:57 PM
To: Eric Rosenfeld
Cc: [email-masked]
Subject: Re: Feedback from PKINIT Review...

Eric Rosenfeld wrote:
> 2) ASN.1 - We found several problems with the ASN.1. We think it would

> be a good idea to have a complete ASN.1 module in an Appendix. The 
> problems that we found so far:
> 
> 	- The latest draft imported the wrong ASN.1 module for PKIX. It 
> imported PKIX1Explicit93, but RFC3280 (and RFC2459 before it) use 
> PKIX1Explicit88.
> 	- Incorrect Import statements, and multiple Imports for the same

> module. A single module in an appendix would allow for a single import

> for each module.
> 	- Definition of subjectAltName was incorrect. It used
OTHER-NAME, 
> which was in RFC2459, but defined differently in RFC3280 because of 
> incompatibilities between 93 syntax and 88 syntax. We had to perform 
> major surgery here.

The problem is that PKIX1Explicit88 (and OTHER-NAME within it) does not
use the object information model, which (I seem to recall from our
hallway meeting in Minn) we wanted to use in lieu of AnotherName, which
uses EXPLICIT ANY DEFINED BY type-id, which I thought we did not want to
use.  Did I misremember?  (It wouldn't be the first time.)

> We should be finished with our review tomorrow, and will hand the 
> results back to Brian Tung then. We will have additional comments that

> need to be addressed. However, given the importance of the issues 
> raised above, it would be good if we could get some discussion and 
> resolution before posting draft 19.

Jeff, I agree that we should post it as soon as I look at it.

Brian Tung <[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Apr 2004 15:52:52 -0500

> Diffie-Hellman mode in detail, I would appreciate pointers.

"Ephemeral-ephemeral DH" means, AFAICS, "DH key exchange with ephemeral
[i.e., randomly generated, one-time use] exponents."

I'm not sure how one can do ephemeral-ephemeral DH with PKINIT -- it's
just not clear from the draft.  Presumably PKINIT in this mode does not
authenticate either of the client or target principals to the other, but
that's not clear either.

More interesting would be how to do "ephemeral-static DH" which, with
the addition of the new pre-auth framework would give us a way to
protect PA-ENC-TIMESTAMP.

So, we need more detail on PKINIT w/ DH exchanges other than
static-static...

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Apr 2004 13:41:27 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> section 3.2.3.  KDC Reply
 
    >> The key is derived as follows: Both the KDC and the client
    >> calculate the value g^(ab) mod p, where a and b are the
    >> client's and KDC's private exponents, respectively.  They both
    >> take the first k bits of this secret value as a key generation
    >> seed, where the parameter k (the size of the seed) is dependent
    >> on the selected key type, as specified in the Kerberos crypto
    >> draft [15].  The seed is then converted into a protocol key by
    >> applying to it a random-to-key function, which is also
    >> dependent on key type.

    Liqiang(Larry)> Simply truncating ZZ probably won't preserve the
    Liqiang(Larry)> secret entropy. why don't you use the key
    Liqiang(Larry)> generation algorithms specified in RFC 2631?

I think truncating is going to be fine based on my understanding
although it is probably worth sitting down with either a group theory
text or cryptographer.

I object to anything that depends on a specific hash or crypto system.