Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

From: Tom Gindin <[email-masked]>
Date: Tue, 1 Nov 2005 08:36:31 -0500

If it isn't too late to fix this without breaking lots of 
implementations, the ASN.1 in this specification is over-tagged.  In 
section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
the one on signedAuthPack is actually slightly harmful.  None of the tags 
in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
subjectName and issuerAndSerialNumber are not really appropriate, and 
subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
clientDHNonce don't need tags.
        Similarly, in 3.2.3, there is no reason for any of the tags in 
PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
3.2.3.2 also seem unnecessary.

Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer.

Sam Hartman <[email-masked]>
Sent by: [email-masked]
10/28/2005 09:12 AM
 
        To:     [email-masked]
        cc:     [email-masked]
        Subject:        [Jeffrey Hutzelman] LAST CALL - Public Key 
Cryptography for Initial Authentication in Kerberos

Hi.  The Kerberos working group has started a last call on the pkinit
draft.  Pkinit is a mechanism for acquiring kerberos tickets based on
knowledge of a private key.  It also supports and is typically used
with a PKI.

I'd appreciate any review that members of the pkix working group can
provide on this document.

----- Message from Unknown on Unknown -----

solipsist-nation ([unix socket]) by solipsist-nation (Cyrus
v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Sun, 23 Oct 2005 22:07:31
-0400 X-Sieve: CMU Sieve 2.2 Return-Path:
<[email-masked]> Received: from
south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by suchdamage.org (Postfix) with ESMTP id
9BDFA1383E for <[email-masked]>; Sun, 23 Oct 2005 22:07:24
-0400 (EDT) Received: from pacific-carrier-annex.mit.edu
(PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by
south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
j9O27MkZ012927 for <[email-masked]>; Sun, 23 Oct 2005
22:07:22 -0400 (EDT) Received: from mailhost.anl.gov (mailhost.anl.gov
[130.202.113.50]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with
ESMTP id j9O26Emq005270; Sun, 23 Oct 2005 22:06:14 -0400 (EDT)
Received: by mailhost.anl.gov (Postfix) id 18622286; Sun, 23 Oct 2005
21:06:13 -0500 (CDT) Delivered-To: [email-masked]
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by
localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for
<[email-masked]>; Sun, 23 Oct 2005 21:06:12 -0500 (CDT)
Received: by mailhost.anl.gov (Postfix, from userid 10733) id
D6987286; Sun, 23 Oct 2005 21:06:12 -0500 (CDT) X-Original-To:
[email-masked] Delivered-To: [email-masked] Received: from
mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov
(Postfix) with ESMTP id 5D96227F for <[email-masked]>; Sun, 23
Oct 2005 21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov
(mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix)
with ESMTP id 4C9D526D for <[email-masked]>; Sun, 23 Oct 2005
21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov (localhost
[127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id
D63D05F0D5B; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received: from
currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by
mailrelay.anl.gov (Postfix) with SMTP id 7F1595F0D5A for
<[email-masked]>; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received:
from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by
currant.srv.cs.cmu.edu id aa18518; 23 Oct 2005 22:06 EDT Received:
from jhutz-dyn0.pc.cs.cmu.edu
(IDENT:U2FsdGVkX1+t+NgCyV0xi/[email-masked]
[128.2.200.136]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu
(8.13.4/8.13.4) with ESMTP id j9O264gX002260 (version=TLSv1/SSLv3
cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Oct 2005
22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From:
Jeffrey Hutzelman <[email-masked]> To: [email-masked] Cc: Jeffrey
Hutzelman <[email-masked]> Subject: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos Message-ID:
<[email-masked]> Originator-Info:
login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=;
token_authority=[email-masked] X-Mailer: Mulberry/3.1.6
(Linux/x86) Sender: [email-masked] Precedence:
bulk X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version:
SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0
tests=AWL,BAYES_00 autolearn=ham version=3.0.2
MIME-Version: 1.0

At long last...

As of October 23, 2005, I am beginning a two-week Last Call period
on the following document:

                 Title                           : Public Key Cryptography 
for
                          Initial Authentication in Kerberos
                 Author(s)               : B. Tung, L. Zhu
                 Filename                : 
draft-ietf-cat-kerberos-pk-init-29.txt
                 Pages                           : 36
                 Date                            : 2005-10-21

Comments on this document should be sent to the Kerberos Working Group
mailing list, [email-masked], and will be accepted at least until
11:59pm EST on November 6, 2005.  All issues raised will be entered
into the Request Tracker system at https://rt.psg.com/.

Once the Last Call period has ended, I will make a determination as to
whether there remain any unresolved issue, and whether there is a rough
consensus withing the working group to send this document to the IESG for
publication as a Proposed Standard.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2005 09:27:12 -0500

>>>>> "Tom" == Tom Gindin <[email-masked]> writes:

    Tom>         If it isn't too late to fix this without breaking
    Tom> lots of implementations, the ASN.1 in this specification is
    Tom> over-tagged.  In section 3.2.1, all three of the tags in
    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
    Tom> is actually slightly harmful.  None of the tags in
    Tom> PKAuthenticator do any good either.  The OCTET STRING
    Tom> wrappings for subjectName and issuerAndSerialNumber are not
    Tom> really appropriate, and subjectName doesn't need a tag.  Even
    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.

The kerberos working group has a rather different philosophy on ASN.1
than the PKIX community.  We've attempted to draw strong boundaries
around structures to the extent that we can: kerberos structures use
our conventions; PKIX structures use yours.

The short answer is that tagging issues have been discussed
extensively across all our ASN.1 usage.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 01 Nov 2005 19:15:24 +0100

I think I second Tom Gindin.

Itseems strange to me to have pieces of the specification
as comments of the asn.1.

example:

          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies the certificate subject by the
                   -- distinguished subject name.
                   -- REQUIRED when there is a distinguished subject
                   -- name present in the certificate.

The first two lines are syntactic specification, it was common
to have such syntactical restrictions until some years ago.
The others don't belong to the syntax at all.

The first one can be replaced by

        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

and an IMPORT that imports Name from an appropiate module. 

I have the feeling that the following sentence doesn't make sense.

   All data structures carried in OCTET
   STRINGs must be encoded according to the rules specified in
   corresponding specifications.

because as far as I remeber the texts, none of the specifications have 
any particular
requirement on the encoding, You can encode everything in XER, can't you?

There are lots of exemples of useless tagging iKDCDHKeyInfo or
PKAuthenticator All base tags are different, and there is only one 
optional field.
Well, that'a a matter of style as well as the global EXPLICIT default.

          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in the PKAuthenticator of the
                   -- request if DH keys are NOT reused,
                   -- 0 otherwise.

To me the comment seems to suggest that

	nonce                   INTEGER (1..4294967295) OPTIONAL 

could be more appropriate. But, the nonce in PKAuthenticator says:

          nonce                   [2] INTEGER (0..4294967295),
                   -- Chosen randomly;  This nonce does not need to
                   -- match with the nonce in the KDC-REQ-BODY.

so it can be 0.

This comment doesn't change anything fundamental of the spec.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 02 Nov 2005 16:58:33 +0100

Sam,

Just because I find your response strange I'd like to add some reamrks.
Why do you mention PKIX here. Tom didn't mention it at all.
You could as well have mentioned SMIME.
Anyway, not too important.

Saying that kerberos has other rules than PKIX has nothing to
do with the problem. besides that PKIX has no rules and continue
s to use obsolete ASN.1, thus it may be good to use something else,
i.e. to ignore whatever some PKIX authors are proposing. :-)

There are two issues in Tom's message: The tagging with
context tags almost always explicit, and the wrapping.

Tagging is a matter of ket's say "taste", in fact, it is a matter of 
implementation
experience. ASN.1 after many years has come with AUTOMATIC tags
allowing automatically unambiguous and non-excessive explicit tagging.

The actual tagging appeared in the 03 draft in 1997 as far as I see.
The krb-wg first meeting was in Jul 2000 but the text was obviously
discussed before in cat. well, let's see the mail archives of this group.
oops. It is difficult to determine now what has "always" been discussed.

Wrapping: Strong boundaries would make sense if you don't have to
cross them

Interoperability note: Some implementations may not be able to decode
   wrapped CMS objects encoded with BER but not DER; specifically, they
   may not be able to decode infinite length encodings. 

something that seems to be necessary according to the previous citation.

As soon as you have the data structure that you wrap,
you can also encode them in DER. I doubt that you just have the
octet string contents only available as blobs.

I refer to the minutes of San Diego concerning the use of DER/BER
and wrapping. Must have been real fun, this meeting
The argument of the difficulties of parsing BER (in particular
when it is totally unrestricted) seem right to me, or better, that
it is too complex to mandate a BER parser.

There may be good arguments after years to keep the syntax or the bits
on the wire but it has been change just a year ago after 8 years or so.

Have fun
Peter

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 02 Nov 2005 20:53:44 +0100

>         subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

Lets take another example:

       PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.

With you syntax this should be

	signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo

Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
Kerberos datatypes uses DER.

How is that expressed in a formal way ?

Just saying IMPORT and CONTANING and expect the right thing to happen when
given to a compiler seems very naive.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 02 Nov 2005 21:00:56 +0100

Peter,

> allowing automatically unambiguous and non-excessive explicit tagging.

The excessive amount of tagging seems like minor nit, its bloaty, sure, its
like rest of the Kerberos protocol.

> octet string contents only available as blobs.

The CMS implemtetion might use another asn1-package then then Kerberos
implemetation, I think today that this is the common case. You call CMS
package, get back blob, and you have no clue about the encoding it used
used.

Love

---

From: Steven Legg <[email-masked]>
Date: Thu, 03 Nov 2005 10:37:43 +1100

Love, et al,

>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

The correct syntax here is:

          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) OPTIONAL

> How is that expressed in a formal way ?

signedAuthPack IMPLICIT OCTET STRING
                   (CONTAINING ContentInfo
                    ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2) distinguished-encoding(1)})
                   OPTIONAL

The OID after the "ENCODED BY" is the OID that identifies DER.

> given to a compiler seems very naive.

There's a better chance that the compiler can do something useful than if
the requirements are expressed informally as a comment.

Regards,
Steven

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 Nov 2005 10:37:49 +0100

Hi,

I stand corrected (for the syntax). For the rest, I am not sure whether
I could have given an explanation as precisely as Steve. :-)

Peter

---

From: Olivier Dubuisson <[email-masked]>
Date: Thu, 03 Nov 2005 15:10:50 +0100

> 3.2.3.2 also seem unnecessary.

The easiest thing would be to put "AUTOMATIC TAGS" in the module header 
(instead of "EXPLICIT TAGS") and not bother with tags, for "AUTOMATIC 
TAGS" would tag where necessary. But I understand from another response 
that the Kerberos team doesn't want to deviate from their historical 
choice...
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

---

From: Olivier Dubuisson <[email-masked]>
Date: Thu, 03 Nov 2005 15:51:09 +0100

>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL

The right syntax is:
subjectName   [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL

It would be even better to add an "ENCODED BY oid" after "CONTAINING 
Name" with 'oid' being the OID of the binary encoding rules used to 
encode 'Name'.

But I can already hear some people saying: This is not supported by Snacc :(

 > and an IMPORT that imports Name from an appropiate module.

IMPORT*S*

 > Well, that'a a matter of style as well as the global EXPLICIT default.

Not only, an EXPLICIT tagging takes more bytes because you can encode 
more than one tag per value.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

---

From: Russ Housley <[email-masked]>
Date: Thu, 03 Nov 2005 10:51:51 -0500

I find AUTOMATIC TAGS to be more difficult later down the line when 
one is doing maintenance.  In my opinion, it hides too much.

Russ

At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:

>> implementations, the ASN.1 in this specification is 
>> over-tagged.  In section 3.2.1, all three of the tags in 
>> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack is 
>> actually slightly harmful.  None of the tags in PKAuthenticator do 
>> any good either.  The OCTET STRING wrappings for subjectName and 
>> issuerAndSerialNumber are not really appropriate, and subjectName 
>> doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
>>         Similarly, in 3.2.3, there is no reason for any of the 
>> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in 
>> ReplyKeyPack in 3.2.3.2 also seem unnecessary.
>
>The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>"AUTOMATIC TAGS" would tag where necessary. But I understand from 
>another response that the Kerberos team doesn't want to deviate from 
>their historical choice...
>--
>Olivier DUBUISSON
>France Telecom

---

From: Steven Legg <[email-masked]>
Date: Fri, 04 Nov 2005 09:55:48 +1100

> But I can already hear some people saying: This is not supported by 

Since the constraint does not change the bits on the wire for BER the
simple retort is: "If your ASN.1 compiler does not support
CONTAINING constraints then comment them out". The hardship caused to
users of dumber ASN.1 toolkits is negligible in a case like this.

Regards,
Steven

---

From: Tom Yu <[email-masked]>
Date: Sun, 06 Nov 2005 01:01:06 -0500

>>>>> "Peter" == Peter Sylvester <[email-masked]> writes:

>> signedAuthPack IMPLICIT OCTET STRING

"IMPLICIT" only goes after a tag, so the above should contain something
like "[0] IMPLICIT" or drop the IMPLICIT completely.  Dropping the
context-specific tag would cause a change in wire encoding from
pkinit-29.

>> The OID after the "ENCODED BY" is the OID that identifies DER.

Except here, we are using a CMS message, which is permitted to be
encoded in BER, and pkinit requires DER, so you really want something
like

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack [0] IMPLICIT OCTET STRING
        (CONTAINING ContentInfo ENCODED BY {
            joint-iso-itu-t asn1 (1) basic-encoding (1)
        })
}

You'll need to normatively reference X.682, because the "CONTAINING"
constraint isn't in X.680.

>> the requirements are expressed informally as a comment.

What one can expect from the compiler depends on what sort of compiler
one is using.  The open-source ASN.1 toolkits with acceptable license
conditions often omit much of the functionality of the full ASN.1
standard.

---Tom

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 06 Nov 2005 16:14:17 +0100

BTW:

Since SNACC is mentioned. There is one application thta uses SNACC, and in
order to decode soem data encapsulated in an OCTET STRING the author
has changed the syntax to something like

[UNIVERSAL 4] IMPLICIT SEQUENCE {data TheType}

and then changed in the generated code the generation/parsing of the 
constructed
bit by hand. If the syntax would not have the addition OCTET STRING 
encapsulation
such a hack wouldn't be necessary.

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 06 Nov 2005 16:14:09 +0100

I think we may have a different opinion of what could be maintenance.
Feel free to explain.

Anyway, You can do exactly what AUTOMATIC does with concrete tags.

The message was not necessarily to promote AUTOMATIC, but a question
why there is a different tagging regime involved which is not totally 
respected
because OCTET STRINGS are IMPLICIT tagged when the contain other
syntaxes.

Russ Housley wrote:

>>> section 3.2.1, all three of the tags in PA-PK-AS-REQ are 
>>> unnecessary, and the one on signedAuthPack is actually slightly 
>>> harmful. None of the tags in PKAuthenticator do any good either. The 
>>> OCTET STRING wrappings for subjectName and issuerAndSerialNumber are 
>>> not really appropriate, and subjectName doesn't need a tag. Even in 
>>> AuthPack, pkAuthenticator and clientDHNonce don't need tags.
>>> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo. The tags in ReplyKeyPack 
>>> in 3.2.3.2 also seem unnecessary.
>>
>>

---

From: Olivier Dubuisson <[email-masked]>
Date: Sun, 06 Nov 2005 21:08:49 +0100

> because OCTET STRINGS are IMPLICIT tagged when the contain other

What do you mean here? Which clause of the ASN.1 standard states that 
"OCTET STRINGS are IMPLICIT tagged when the contain other syntaxes".
Also, what does "contain other syntaxes" mean? Do you mean "contain the 
encoding of an ASN.1 value"?
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

---

From: Steven Legg <[email-masked]>
Date: Mon, 07 Nov 2005 10:20:46 +1100

Tom,

Tom Yu wrote:
> like "[0] IMPLICIT"

Quite right. I was focussed on the constraint and didn't notice the tag
had been dropped.

or drop the IMPLICIT completely.  Dropping the
>             joint-iso-itu-t asn1 (1) basic-encoding (1)

I'm not an expert on this but it would seem that as far as pkinit is
concerned, the encoding of a ContentInfo value contained in the
signedAuthPack component of a PA-PK-AS-REQ value is always a DER
encoding. It doesn't matter what encoding rules CMS uses to encode
values of ContentInfo, and the constraint has no effect whatsoever
on encodings of ContentInfo values outside the signedAuthPack component.

> constraint isn't in X.680.

Yes.

> conditions often omit much of the functionality of the full ASN.1

And they always will if ASN.1 specifications always pander to the lowest
common denominator. Contents constraints are a nudge in the right direction.

Regards,
Steven