Subject: comments on pkinit 19

From: Ken Raeburn <[email-masked]>
Date: Thu, 6 May 2004 17:50:19 -0400

Minor formatting:

Section 3, list of extensions, the number "2" is printed twice, once 
with the (second) item and once against the left margin.

Section 3, list of extensions, item 3, I'm seeing "KDC?s" and 
"client?s".  Are you using "Microsoft quotes" instead of ASCII in this 
document?

Section 3.2.2, description of timestamps, "MUSTreturn" needs a space.

Section 3.2.2, "Enxtended Key Usage" typo.

General Kerberos protocol issues:

Should preauth systems in general be adding to the Kerberos error code 
list?  Or should we have a way of attaching a tuple of { preauth system 
id, preauth-system-specific error code } to an error reply?

PK-INIT crypto stuff:

Section 3.1.x last paragraph, last sentence would seem to indicate that 
any new encryption system to be used with the PK bits must get a new 
Kerberos cryptosystem number assigned.  Weren't the existing numbers 
going to be used only for backwards compatibility, and new encryption 
systems listed only by OID?  (Sorry, I've been a bit preoccupied with 
some other work and non-work activities, and haven't followed the 
PKINIT discussions much lately.)

Section 3.2.3, seed generation:

The case where len(seed) < k should be addressed, if only to explicitly 
disallow combinations of key type and "p" value where it could happen.  
It's not likely to with existing cryptosystems, but I bet I could 
invent a cryptosystem fully compliant with the crypto framework, 
perhaps based on public key crypto, for which the seed would need to be 
very large.  (Not a fast one, perhaps, but it doesn't need to be 
particularly desirable to demonstrate the existence of a problem.)

I'd suggest ending the paragraph discussing random-to-key with "for 
example" and dropping those words from the "1" paragraph following, to 
make it clear that both (1) and (2) are examples, not normative 
specifications.

---

From: Love <[email-masked]>
Date: Fri, 07 May 2004 23:11:00 +0200

Ken Raeburn <[email-masked]> writes:

> list?  Or should we have a way of attaching a tuple of { preauth
> system id, preauth-system-specific error code } to an error reply?

I say they shouldn't, put since PK-INIT does and it already exsists
implementaitons, just let pk-init do it.

> PK-INIT crypto stuff:
>
> Section 3.1.x last paragraph, last sentence would seem to indicate
> that any new encryption system to be used with the PK bits must get a
> new Kerberos cryptosystem number assigned.  Weren't the existing
> numbers going to be used only for backwards compatibility, and new
> encryption systems listed only by OID?  (Sorry, I've been a bit
> preoccupied with some other work and non-work activities, and haven't
> followed the PKINIT discussions much lately.)

Yes, it should be oid and not kcrypto numbers since they are CMS
types. This apparently been discussioned already, its just noone that have
send text to Brian. Here is proposal to text:

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
        supportedCmsTypes	[2] SEQUENCE OF AlgorithmIdentifier
        ...
    }

[...]
supportedCmsTypes are those CMS types that are supported by the client CMS
system.

> The case where len(seed) < k should be addressed, if only to
> explicitly disallow combinations of key type and "p" value where it
> could happen.  It's not likely to with existing cryptosystems, but I
> bet I could invent a cryptosystem fully compliant with the crypto
> framework, perhaps based on public key crypto, for which the seed
> would need to be very large.  (Not a fast one, perhaps, but it doesn't
> need to be particularly desirable to demonstrate the existence of a
> problem.)

I propose to deal with in that way that it failes. The kdc is simply not
required to deal with that case.

> make it clear that both (1) and (2) are examples, not normative

I think they should be (1) and (2) should just be removed. random-to-key is
described in kcrypto, no need to rehash it here.

Love

---

From: Brian Tung <[email-masked]>
Date: Fri, 7 May 2004 14:50:34 -0700

> required to deal with that case.

With what error type?

> described in kcrypto, no need to rehash it here.

They were put in because people wanted examples (just not normative
examples, as Ken points out).  Is that a bad idea, or are these just bad
examples?

Brian Tung <[email-masked]>

---

From: Love <[email-masked]>
Date: Sat, 08 May 2004 00:36:52 +0200

>> required to deal with that case.

KDC_ERR_KEY_SIZE should be just fine.

> examples, as Ken points out).  Is that a bad idea, or are these just bad

The examples are just fine, but I think its a bad idea, random-to-key is
described just fine in kcrypto.

And yet still, the whole DH issue unclear, I understand and fine it almost
acceptable to just use first k bits shared secret. However I still think we
should have the option of doing it diffrently. Like ANSI X9.42 ? this would
also solve the problem above.

Love

---

From: Brian Tung <[email-masked]>
Date: Fri, 7 May 2004 16:32:57 -0700

> also solve the problem above.

How do you propose that we identify which option is being used?

---

From: Love <[email-masked]>
Date: Sat, 08 May 2004 01:35:04 +0200

On the subway home I realized ...

>         supportedCmsTypes	[2] SEQUENCE OF AlgorithmIdentifier

that supportedCmsTypes should OPTIONAL

> supportedCmsTypes are those CMS types that are supported by the client CMS

And this text should be added:

"
If the KDC doesn't support any of the CMS types that the client supports it
should return KRB5KDC_ERR_ETYPE_NOSUPP.
"

The error code could be replaced by another equally confusing error code.

Should the supportedCmsTypes be ordered in preference of the client ?

Should it be a SEQ of OBJECT IDENTIFIER or some more like SMIMECapabilities
(that AlgorithmIdentifier is, but I not sure we should overload it).

Love

---

From: Love <[email-masked]>
Date: Sat, 08 May 2004 01:40:35 +0200

> How do you propose that we identify which option is being used?

Larry proposed a solution in

From: "Liqiang(Larry) Zhu" <[email-masked]>
Subject: PKINIT-19 comments
To: <[email-masked]>
Message-Id: <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>
Date: Tue, 27 Apr 2004 02:24:14 -0700

I would be fine with that since it allows the KDC to insert randomness when
in the Ephemeral-Static operation.

Love