Subject: RE: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 25 Oct 2005 10:24:14 -0700

Love wrote:
> * Normative text inside asn.1 comments.

Did you mean Normative text *only* in asn.1 comments? Can you be more specific?

> * TD-DH-PARAMETERS unprotected but it doesn't need to be,
>  KDC have a certificate, lets use it to avoid downgrade attacks

the security considerations have already addressed this one.

> * Q is not expilictly defined for most D-H groups, Q is a non-OPTIONAL
>  field in DomainParameters. How should client and server handle this ?

let me guess where you got this idea. RFC3526 does not include Q. This is because you can easily calculate Q based on P; in fact you can just right-shift P by one bit to get Q.

   The security of a modular exponentiation group depends on the largest
   prime factor of the group size.  In order to maximize this, one can
   choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q
   are prime.  However, if P = kQ + 1, where k is small, then the
   strength of the group is still considerable.  These groups are known
   as Schnorr subgroups, and they can be found with much less
   computational effort than Sophie-Germaine primes.

> * DH doesn't protect the request (asChecksum), I think it should,
>  there are more options sent in the request more then the PK-INIT
>  request.

Let me assume I have guessed correctly what you meant.

KINIT has been in draft mode for more than a decade now.
We should at most try to fix errors and make minor changes at this stage or we risk opening a can of worms with endless discussions on details and then another year goes quickly in this standards process.

I do not support you in this one.

> * I think TD-DH-PARAMETERS is somewhat underspecified, but can't
>  really describe how to make it better. Its the content that is
>  underspecified.

Hummm... can you substantiate this comment?

>* Remove . after only. Also this sentintense is ambigious, is empty the
>  empty set or the omitted field ?

Good catch, I think we should remove the "only.", not just the ".", I just removed these in my version.

> >       hints to guide its selection of an appropriate certificate chain
> >       to return to the client.  This field may only. be left empty if

> * General question, are all SEQUENCE OF are allowed to be the empty
>   sequence (0 elements) ?

This is what RFC3280 should decide. I believe both are allowed, but I think Tom might know better here.

> * Should oid names be broken over several lines ?

Why it can not be broken in to separate lines? Tom?

> >   2.  The contentType field for the type EnvelopedData is id-
> >       signedData:

> * I think it should be pointed out that "signedAttrs" field in
>  SignedData might be used.

For what is it might be used?

> The general state of the document have improved much, and after proper
> CMS/X.509 review I think its implementable.

Good.

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2005 9:25 AM
To: [email-masked]
Cc: Jeffrey Hutzelman; Liqiang(Larry) Zhu; [email-masked]
Subject: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

In the first read though of the document I found these issues:

* Normative text inside asn.1 comments.
* TD-DH-PARAMETERS unprotected but it doesn't need to be,
  KDC have a certificate, lets use it to avoid downgrade attacks
* DH doesn't protect the request (asChecksum), I think it should,
  there are more options sent in the request more then the PK-INIT
  request.
* Q is not expilictly defined for most D-H groups, Q is a non-OPTIONAL
  field in DomainParameters. How should client and server handle this ?

* I think TD-DH-PARAMETERS is somewhat underspecified, but can't
  really describe how to make it better. Its the content that is
  underspecified.

* Remove . after only. Also this sentintense is ambigious, is empty the
  empty set or the omitted field ?

>       hints to guide its selection of an appropriate certificate chain
>       to return to the client.  This field may only. be left empty if

* General question, are all SEQUENCE OF are allowed to be the empty
  sequence (0 elements) ?

* Should oid names be broken over several lines ?

>   2.  The contentType field for the type EnvelopedData is id-
>       signedData:

* I think it should be pointed out that "signedAttrs" field in
  SignedData might be used.

--- 

The general state of the document have improved much, and after proper
CMS/X.509 review I think its implementable.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 25 Oct 2005 20:04:55 +0200

> Did you mean Normative text *only* in asn.1 comments? Can you be more

Its contains lots and lots of "MUST" and "SHOULD" that I don't think belong
there.

> the security considerations have already addressed this one.

I still think it should be protected.

> let me guess where you got this idea. RFC3526 does not include Q. This is
> because you can easily calculate Q based on P; in fact you can just
> right-shift P by one bit to get Q.

Will that be true for all other Q in the future ?

> KINIT has been in draft mode for more than a decade now.  We should at
> most try to fix errors and make minor changes at this stage or we risk
> opening a can of worms with endless discussions on details and then
> another year goes quickly in this standards process.
>

I think the protocol should be symmetric from the point of enckey and
dhkey. I think its a reasonable change.

> Hummm... can you substantiate this comment?

Its doesn't tell how to fill in the AlgorithmIdentifier-s, its
un-implemetable.

> This is what RFC3280 should decide. I believe both are allowed, but I think Tom might know better here.

PKINIT defines lots of SEQUENCE OF itself.

> Why it can not be broken in to separate lines? Tom?

Sure it can, but I don't think it should.

> For what is it might be used?

To sign the contentType that is otherwise unsigned.

Love

---

From: Tom Yu <[email-masked]>
Date: Wed, 26 Oct 2005 17:01:49 -0400

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

>> * General question, are all SEQUENCE OF are allowed to be the empty

lzhu> This is what RFC3280 should decide. I believe both are allowed,
lzhu> but I think Tom might know better here.

Why is RFC3280 relevant for the SEQUENCE OF types in this document?
Also, note that the main ambiguity problem for zero-length SEQUENCE OF
types is when they are OPTIONAL components of a SEQUENCE type: you can
encode either a zero-length SEQUENCE OF type or omit the SEQUENCE OF
type completely.  I will note that there are multiple instances of
SEQUENCE OF types being OPTIONAL components of SEQUENCE types in this
draft.

>> * Should oid names be broken over several lines ?

lzhu> Why it can not be broken in to separate lines? Tom?

Do you mean OID values rather than OID names?

---Tom

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 27 Oct 2005 00:00:01 -0700

> Do you mean OID values rather than OID names?
 
Love, what did you mean? OID values or OID names?

________________________________

From: [email-masked] on behalf of Tom Yu
Sent: Wed 10/26/2005 2:01 PM
To: Liqiang(Larry) Zhu
Cc: Love Hörnquist Åstrand; [email-masked]; Jeffrey Hutzelman; [email-masked]
Subject: Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

---Tom