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

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

Love wrote: 

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

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

Can you be more specific, such as which "MUST" should not be where?

I think it is ok to have "MUST" in the comments, as long as the requirements also appear in the main body of the text.

> To sign the contentType that is otherwise unsigned.

Why do we need to sign contentType?

we should leave to the extension for signing Kerberos error messages and protecting AS_REQ. 

krb-wg, can we please get agreement on that first? Otherwise my guess is that Love could never rest in peace.

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

It depends on whether Sophie Germaine primes are used in these future DH groups, doesn't it? 

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

This is specified RFC3279. If there is not enough information to implement, can you please raise the concern to the PKIX group?

> PKINIT defines lots of SEQUENCE OF itself.

As I said, both are allowed.

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

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

> Love wrote:
>> * Normative text inside asn.1 comments.
>
> Did you mean Normative text *only* in asn.1 comments? Can you be more
> specific?

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

>> * 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.

I still think it should be protected.

>> * 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.

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

>    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 the protocol should be symmetric from the point of enckey and
dhkey. I think its a reasonable change.

>> * 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?

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

>> >       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.

PKINIT defines lots of SEQUENCE OF itself.

>> * Should oid names be broken over several lines ?
>
> Why it can not be broken in to separate lines? Tom?

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

>> >   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?

To sign the contentType that is otherwise unsigned.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 26 Oct 2005 12:46:34 +0200

> Can you be more specific, such as which "MUST" should not be where?

Let me give you an example, the first MUST in the document that is in a
asn.1 comment, page 13.

*       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
*         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
*          pkinit(3) keyPurposeKdc(5) }
*              -- Signing KDC responses.
*              -- Key usage bits that MUST be consistent:
*              -- digitalSignature.

I can't find where this requirement is defined anywhere else in the document.

Also inside the comments is the (kerberos) key usage number defined, but
not anywhere else in the document.

> I think it is ok to have "MUST" in the comments, as long as the
> requirements also appear in the main body of the text.

That is ok, its not the case now.

> Why do we need to sign contentType?

From CMS:

      signedAttrs is a collection of attributes that are signed.  The
      field is optional, but it MUST be present if the content type of
      the EncapsulatedContentInfo value being signed is not id-data.

> that Love could never rest in peace.

This have been up before, krb-wg can't change CMS.

This issue is not about signing Kerberos messages.

> It depends on whether Sophie Germaine primes are used in these future DH

So will they ?

> This is specified RFC3279. If there is not enough information to
> implement, can you please raise the concern to the PKIX group?

Why do the the text then reference IEEE 1363 ?

*       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
*                   -- Each AlgorithmIdentifier specifies a set of
*                   -- Diffie-Hellman domain parameters [IEEE1363].
*                   -- This list is in decreasing preference order.

> As I said, both are allowed.

Are the any diffrences between them (not encoded vs empty) ?

Love

---

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

Love, can you do the honor to  compile the list of nits?
 
To set the expectations here, we can beautify the text but I would try first to deal with concerns other than just the formality and nits, and I would like to make sure there are no serious issues, things such as whether the protocol clearly defined, and whether the protocol is well presented, whether the protocol itself is sound and secure.
 
if these issues are all you can find, would it be fair to say that document is ready to go but less than perfect?
 
-- Larry

________________________________

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

From CMS:

So will they ?

Love

---

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

>   the EncapsulatedContentInfo 
 
did you mean we need to quote the same text in PKINIT?

> This issue is not about signing Kerberos messages.
 
please *clearly* spell out the issues. My comments will not be applicable if my guess itself is incorrect.
 
 what is the issue exactly here? 
 
-- Larry

From: [email-masked] on behalf of Liqiang(Larry) Zhu
Sent: Thu 10/27/2005 12:09 AM
To: Love Hörnquist Åstrand
Cc: [email-masked]; Tom Yu; Jeffrey Hutzelman; [email-masked]
Subject: RE: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

 

-- Larry

From CMS:

So will they ?

Love