Subject: comments on draft-ietf-krb-wg-kerberos-clarifications-02.txt

From: assar <[email-masked]>
Date: 19 Nov 2002 01:59:22 -0500

>From a quick reading of the draft, I have a number of corrections,
comments, and questions.

I've tried giving enough context for all the places in the text
without quoting too much of the actual text.

> Table of Contents

is not up-to-date

> 2. Ticket flag uses and requests

Does not mention OK-AS-DELEGATE

> 2.8.1 Renewable-OK
> 
> The RENEWABLE-OK option indicates that the client will accept a renewable
> ticket if a ticket with the requested life cannot otherwise be provided. If
> a ticket with the requested life cannot be provided, then the KDC may issue
> a renewable ticket with a renew-till equal to the the requested endtime. The
                                                ^^^^^^^ duplicate 'the'
> 3.1. The Authentication Service Exchange

> exchange does not by itself provide any assurance of the the identity of the
> user[3.2].
                                                       ^^^^^^^ duplicate
> 3.1.3. Generation of KRB_AS_REP message

> When the etype field is present in a KDC request, whether an AS or TGS

It is always present.

> The flags field of the new ticket will have the following options set if
> they have been requested and if the policy of the local realm allows:
> FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. If

The ANONYMOUS flag is not mentioned in the rest of the document.

> 3.1.4. Generation of KRB_ERROR message
> 
> Several errors can occur, and the Authentication Server responds by

                                    KDC to be consistent

> 3.1.5. Receipt of KRB_AS_REP message

Should say that key-expiration (not mentioned in 3.1.3) is obsolete
and that last-req should be used instead

> system clock when generating messages [cite Davis and Geer].

incomplete reference

> 3.2.2. Generation of a KRB_AP_REQ message

> new Authenticator from the the system time, its name, and optionally an

                         ^^^^^^^ duplicate
> 3.3.3. Generation of KRB_TGS_REP message

> key key from the ticket-granting ticket. It is not encrypted using the
  ^^^^^^^
  repeated

> 3.3.3.2. Encoding the transited field

> A realm name beginning with a "/" is interpreted as being appended to the
> previous realm[18]. If it is to stand by itself, then it should be preceded

What does 18 refer to?  Dangling reference.

> Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
> they would not be included in this field, and we would have:
  ^^^^
  repeated

> A null subfield preceding or following a "," indicates that all realms
> between the previous realm and the next realm have been traversed[19]. Thus,

[19] - another dangling reference

> "," means that all realms along the path between the client and the server
> have been traversed. ",EDU, /COM," means that that all realms from the
                                           ^^^^^^^^^
                                           repeated

> 3.3.4. Receipt of KRB_TGS_REP message
> 
> When the KRB_TGS_REP is received by the client, it is processed in the same
> manner as the KRB_AS_REP processing described above. The primary difference
> is that the ciphertext part of the response must be decrypted using the
> sub-session key from the Authenticator, if it was specified in the request,
> or the session key key from the ticket-granting ticket, rather than the
                 ^^^^^^^
                 repeated

> 3.4.2. Receipt of KRB_SAFE message

> microsecond fields from the Authenticator match any recently-seen (sent or
> received[20] ) such tuples, the KRB_AP_ERR_REPEAT error is generated. If an

stale reference

> 3.6.1. Generation of a KRB_CRED message

> corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
> message.

repeated 'the'

> Implementation note: When constructing a KRB_CRED message for inclusion in a
> GSSAPI initial context token, the MIT implementation of Kerberos will not
> encrypt the KRB_CRED message if the session key is a DES or tripple DES key.

'tripple' -> 'triple'

> 3.6.2. Receipt of KRB_CRED message

> shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
> generated. v

'v' left-over

> ignore the address even if present in order to work better in NAT
> environments. A failed match for either case generates a KRB_AP_ERR_BADADDR
> error. Recipients MAY wish to skip the address check as the KRB_CRED message
> cannot generally be reflected back toThe timestamp and usec fields (and the
                                
                                       ^ cut here ?

> If all the checks succeed, the application stores each of the new tickets in
> its ticket cache together with the session key and other information in the

ticket cache -> credentials cache

> 3.7. User to User Authentication Exchanges
> 
> (This entire subsection is new) User to User authentication provides a

remove comment

> unprivleged user it might not have access to system keys. Similar situations

unprivileged user

>     Message direction                    Message type     Sections
>     0. Message from application server   Not Specified
>     1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
>     2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
                                                       ^^
                                                       what?

>     3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
> 
> To address this problem, the Kerberos protocol allows the client to request
> that the ticket issued by the KDC be encrypted using a session key a ticket
                                                                      ^
                                                                   from/in

> granting ticket issued to the party that will verify the authentication.
> This ticket granting ticket must be obtained from the verifier by a means
> exchange external to the Kerberos protococl, usually as part of the

by means/an exchange

> application protocol. This message is shown in the summary above as message
> 0. Note that because the ticket granting ticket is encrypted in the KDC's
> secret key, can not be used for authentication without posession of the
             ^ it

> corresponding secret key, and because the verifier does not give out the
> corresponding secret key, providing a copy of the verifiers ticket granting
                                                    ^^^^^^^^^
                                                    verifier's

> Once the verifier's ticket granting ticket has been obtained by the client,
> by specifying the ENC-TKT-IN-SKEY option to the KDC, the client can include
> the ticket as an additional ticket in its KRB_TGS_REQ frequest to the KDC
                                                        request

> If validated according to the instructions in 3.3.3, the application ticket
> returned to the client (message 3 in the table above) will be encrypted
                          ^^^^^^^^^
                          shouldn't that be message 2?

> 4. Encryption and Checksum Specifications
> 
> [RFCEDITOR: Insert citation for KCRYPTO] defines a framework for defining
> encryption and checksum mechanisms for use with Kerberos. It also defines
> several such mechanisms, and more may be added in future updates to that
> document.

I assume that KCRYPTO should be advanced at the same time?

> Key usages are unsigned 32 bit integers; zero is not permitted. The key
> usage values for encrypting or checksumming Kerberos messages are indicated
> in section 5 along with the message definitions. Key usage values 512-1023
> are reserved for uses internal to a Kerberos implementation. (For example,
> seeding a pseudo-random number generator with a value produced by encrypting
> something with a session key and a key usage value not used for any other
> purpose.) Key usage values between 1024 and 2047 (inclusive) are reserved
> for application use; applications should use even values for encryption and
> odd values for checksums within this range. Key usage values are also
> summarized in a table in section 8.4.

8.4 should be 7.5.1

> draft-ietf-krb-wg-kerberos-clarifications-02         Expires 1 May 2003
> 
> There might exist other documents which define protocols in terms of the
> RFC1510 encryption types or checksum types. Such documents would not know
> about key usages. In order that these specifications continue to be
> meaningful until they are updated, key usages 1024 and 1025 must be used to

isn't 1024 and 1025 used twice?

> 5.1.3. Empty SEQUENCE OF Types

> are indicated a comment.
               ^ with

> 5.2.1. KerberosString
> 
> The original specification of the Kerberos protocol in RFC 1510 uses
> GeneralString in numerous places for human-readable string data. Historical
> implementations of Kerberos cannot utilize the full power of GeneralString.
> This ASN.1 type requires the use of designation and invocation escape
> sequences as specified in ISO-2022/ECMA-35 to switch character sets, and the

is it ISO-2022 or ISO-1022?  And the reference should have [] around it.

> default character set that is designated as G0 is the ISO-646/ECMA-6

more []

> 5.2.2. Realm and PrincipalName

> names. Acceptable forms for realm names are specified in section 7. A

should be 6.1

> PrincipalName is a typed sequence of components consisting of the following
> sub-fields:
> 
> name-type
>      This field specifies the type of name that follows. Pre-defined values
>      for this field are specified in section 7.2. The name-type should be

should be 7.5.8

> 5.2.5. HostAddress and HostAddresses

> addr-type
>      This field specifies the type of address that follows. Pre-defined
>      values for this field are specified in section 8.1.

should be 7.5.3

> 5.2.6. AuthorizationData

>  DER encoding of AD-OR                 5

should pprobably be AD-AND-OR

>  DER encoding of AD-MANDATORY-FOR-KDC  8

> 5.2.6.1. IF-RELEVANT

what happened to 5.2.6.2 and 5.2.6.3 ?

> 5.2.6.4. KDCIssued

> The KDC-issued ad-data field is intended to provide a means for Kerberos
> principal credentials to embed within themselves privilege attributes and
> other mechanisms for positive authorization, amplifying the priveleges of

                                                              ^^^^^^^^^^
                                                              privileges
> 5.2.6.5. AND-OR

and 5.2.6.6 and 5.2.6.7 ?

> 5.2.7.5. PA-ETYPE-INFO2

> ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY

where is MAX defined?

> 5.3. Tickets

>      (KRB_AS_REP), this is the current time on the Kerberos server[24].

stale reference to 24

> caddr
[ ... ]

>      accept such tickets. The suggested and default policy, however, is that
>      such tickets will only be issued or accepted when additional
>      information that can be used to restrict the use of the ticket is
>      included in the authorization_data field. Such a ticket is a
>      capability.

This recomendation is obsolete in the sad world of NATs that we live today.

> authorization-data

>      The data in this field may be specific to the end service; the field
>      will contain the names of service specific objects, and the rights to
>      those objects. The format for this field is described in section 5.2.

make that 5.2.6

>      separately authenticated using the kdc-issued authorization data
>      element (see B.4).

should probably be 5.2.6.4

> kdc-options

>       10-13   UNUSED                   Option 11 is reserved for future is
>                                        as opt-hardware-auth.

11 is actually marked as used elsewhere in the document.

>       27      RENEWABLE-OK             then a renewable ticket may be
>                                        issued with a renew-till equal to
>                                        the the requested endtime. The value
                                         ^^^
                                         repeated
> nonce
>      This field is part of the KDC request and response. It it intended to
                                                           ^^^^^
                                                           it is
> 5.4.2. KRB_KDC_REP definition

> last-req

>      lr-type
>           If the lr-type field is zero (0), then no information is conveyed
>           by the lr-value subfield. If the absolute value of the lr-type
>           field is one (1), then the lr-value subfield is the time of last
>           initial request for a TGT. If it is two (2), then the lr-value
>           subfield is the time of last initial request. If it is three (3),
>           then the lr-value subfield is the time of issue for the newest
>           ticket-granting ticket used. If it is four (4), then the lr-value
>           subfield is the time of the last renewal. If it is five (5), then
>           the lr-value subfield is the time of last request (of any type).
>           If it is (6), then the lr-value subfield is the time when the
>           password will expire.

Missing (7) - account expiration

> key-expiration
>      The key-expiration field is part of the response from the KDC and
>      specifies the time that the client's secret key is due to expire. The
>      expiration might be the result of password aging or an account
>      expiration. This field will usually be left out of the TGS reply since
>      the response to the TGS request is encrypted in a session key and no
>      client information need be retrieved from the KDC database. It is up to
>      the application client (usually the login program) to take appropriate
>      action (such as notifying the user) if the expiration time is imminent.

Should say that key-experiation is deprecated and that Last-Req should
be used instead.  Also that key-expiration should be the earliest of
key and account expiration.

> 5.5.1. KRB_AP_REQ definition

> cksum
>      This field contains a checksum of the the application data that
                                         ^^^^^^^
                                         repeated

> 5.7.1. KRB_PRIV definition

> enc-part
>      This field holds an encoding of the EncKrbPrivPart sequence encrypted
>      under the session key[32], with a key usage value of 13. This encrypted

stale reference

> 5.9.1. KRB_ERROR definition

> error-code
>      This field contains the error code returned by Kerberos or the server
>      when a request fails. To interpret the value of this field see the list
>      of error codes in section 8. Implementations are encouraged to provide

should be 7.5.9

> 6.2. Principal Names

> Names of any type with an initial component of 'krbtgt' are reserved for the
> Kerberos ticket granting service. See section 8.2.4 for the form of such
> names.

should refer to 7.5.9

> 7.1. Host address types
> 
> Internet (IPv6) Addresses [Westerlund]

remove the reference

> Directional addresses MUST only be used for the sender address field in the
> KRB_SAFE or KRB_PRIV messages. They MUST NOT be used as a ticket address or
> in a KRB_AP_REQ message. This address type SHOULD only be used in situations
> where the sending party knows that the receiving party supports the address
> type. This generally means that directional addresses may only be used when
> the application protocol requires their support. Directional addresses are
> type XX (0xXX).

What is the value?

> 7.2.1.2. TCP/IP transport [Westerlund,Danielsson]

remove reference

> 7.5.1. Key usage numbers
> 
> The encryption and checksum specifications in [KCRYPTO] require as input a
> "key usage number", to alter the encryption key used in any specific
> message, to make certain types of cryptographic attack more difficult. These
> are the key usage values assigned in this document:
> 
>         1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
>                     with the client key (section 5.2.7.2)
>      512-1023.      Reserved for uses internal to a Kerberos
>                     implementation.

1024, 1025 and the overlapping range 1024-2047 is not included here

> 7.5.2. PreAuthentication Data Types

> PA-ENC-UNIX-TIME                5        (depricated)

deprecated

> 7.5.4. Authorization Data Types
> 
> authorization data type         ad-type value
> AD-IF-RELEVANT                     1
> AD-INTENDED-FOR-SERVER             2
> AD-INTENDED-FOR-APPLICATION-CLASS  3
> AD-KDC-ISSUED                      4

AD-KDCIussed (used inconsitently)

> AD-OR                              5

should be AD-AND-OR

> 7.5.8. Name Types
> 
> name types
> 
> KRB_NT_UNKNOWN        0  Name type not known
> KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
> KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
> KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
> KRB_NT_SRV_XHST       4  Service with host as remaining components
> KRB_NT_UID            5  Unique ID
> KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]

Is not consitent with 6.2 and is missing: KRB_NT_SMTP_NAME and KRB5_NT_ENTERPRISE

> 7.5.9. Error Codes
> error codes

> KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]

stale reference

> 8.1. Specification 2

> The following encryption and checksum mechanisms must be supported.
> 
> Encyrption: AES256-CTS-HMAC-SHA1-96

  Encryption

> Checksums: HMAC-SHA1-96-AES256

And I assume that draft-raeburn-krb-rijndael-krb-02.txt will be
advanced at the same time?

> 8.2. Recommended KDC values

> empty addresses               only when suitable  restrictions  appear
>                               in authorization data

update to current reality

> 11.1 ACKNOWLEDGEMENTS
> 11.1. REFERENCES

duplicate header

there are lots of extra hyphenation in the list of references:

     National Bureau of Standards, U.S. Department of Com- merce, "DES Modes
     Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key
     Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd Edition.

these publications are referenced and not included in the list of references:

[RFC1510]
[RFC1884]
[RFC2373]
[KCRYPTO]

these references do not follow the format of the others and are not
included in the list either:

[RFC 2222]
[RFC 1779]
[RFC 1035]
[RFC 2052]
[RFC 2253]

these references are not used:

[Bellare98]
[Blumenthal96]
[Dolev91]
[Horowitz96]
[HorowitzB96]
[ISO-4873/ECMA-43]
[Krawczyk96]
[MD4-92]
[MD5-92]
[Neu93]
[Pat92].
[X509-88]

> B.1 Changes to Section 1
> 
> Discussion was added to section on regarding the ability to rely on the KDC
                                 ^ 1

> B.5 Changes to Section 5

> behavior of of double-encoding.

only one 'of' :-)

> FOOTNOTES
> 
> [TM] Project Athena, Athena, and Kerberos are trademarks of the
> Massachusetts Institute of Technology (MIT). No commercial use of these
> trademarks may be made without prior written permission of MIT.

never used

> [3.5] Note that this can make applications based on unreliable transports
> difficult to code correctly. If the transport might deliver duplicated
> messages, either a new authenticator must be generated for each retry, or
> the application server must match requests and replies and replay the first
> reply in response to a detected duplicate.
> 
>   ------------------------------------------------------------------------

What happened to 3.6?

>   ------------------------------------------------------------------------
> [3.7]Note also that the rejection here is restricted to authenticators from
> the same principal to the same server. Other client principals communicating
> with the same server principal should not be have their authenticators
> rejected if the time and microsecond fields happen to match some other
> client's authenticator.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 10:34:36 -0500

>>>>> "assar" == assar  <[email-masked]> writes:

    assar> Is not consitent with 6.2 and is missing: KRB_NT_SMTP_NAME
    assar> and KRB5_NT_ENTERPRISE

I thought we dropped smtp name because no one knew what it was and we
concluded it was a dup of enterprise name.

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 11:32:14 -0500

>> ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY

assar> where is MAX defined?

MAX is defined by definition of the ASN.1 syntax for the ValueRange
notation (used in the constraint notation), section 48.4 of
X.690:1997.  Basically it means that the corresponding bound is that
of the parent type, which in this case is effectively unlimited.

---Tom

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 13:13:33 -0500

>> of the parent type, which in this case is effectively unlimited.

assar> Okay.  Can you add that paragraph somewhere before MAX is used?

Do we really feel that it is necessary to define things that are
already well defined in the ASN.1 standard?

---Tom

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 13:23:55 -0500

>> already well defined in the ASN.1 standard?

assar> We do feel that we should try to aim for clarity, and saying where
assar> something is defined will improve that.

We don't explicitly give detailed citations for all the other ASN.1
notation that we use in the document.  Why should we do so for MAX?

---Tom

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 15:12:23 -0500

assar> Matt Crawford <[email-masked]> writes:
>> No, we don't, because that's the beginning of a long road to a bad place.

assar> And that road was already started when ASN.1 was picked.  Pointing at
assar> the road is not a bad thing.

We should consider X.680:1997 and X.690:1997 to be normative
references.  A responsible implementor should read the normative
references to arrive at a correct implementation.  I believe that both
of these references are already listed in the document.

---Tom

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 16:19:06 -0500

>>>>> "assar" == assar  <[email-masked]> writes:

assar> And what's the problem with saying that they define MAX?

We don't explicitly reference X.690 to explain the meaning of any
other specific piece of ASN.1 notation, as far as I can tell.

assar> Since the ISO documents explain ASN.1 fully, why is there any need for
assar> any ASN.1-related discussion at all in the document?

The ASN.1-related discussion existing in the document consists
largely, if not completely, of clarifications about the specific use
of ASN.1 in Kerberos, or of implementation notes.  I think we should
make an effort to *not* be an ASN.1 tutorial.

---Tom

---

From: Matt Crawford <[email-masked]>
Date: Tue, 19 Nov 2002 13:44:16 -0600

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2002 17:09:24 -0500

>> make an effort to *not* be an ASN.1 tutorial.

assar> But this would clarify the size of specific objects in the protocol.
assar> How is that not useful if the spec is to be as clear as possible?

I'm sorry.  I should have been more verbose.  What I meant was that
the initial subsections of section 5 clarify ambiguities inherent in
the use of particular ASN.1 types by Kerberos, e.g. optional integer
types.  The size constraint is applied to a new type that we
introduced in kerberos-clarifications.  The meaning of the constraint
is clear to anyone who has read the ASN.1 specification.  The
ambiguities in semantics which we describe in the initial subsections
of section 5 may or may not be obvious to someone who has read the
ASN.1 specification, since there are legitimate reasons for other
hypothetical protocols to distinguish between certain abstract values
that Kerberos implementations have historically held to be
semantically identical.

The ASN.1 notation itself should need no clarification.  That is not
the purpose of this document.  The motivations and interoperability
considerations relating to specific use of ASN.1 in this protocol may
require clarification, and such clarification does belong in this
document, in my opinion.  I claim that your desire for the definition
of the "MAX" notation falls into the first category.

---Tom

---

From: assar <[email-masked]>
Date: 19 Nov 2002 16:53:49 -0500

> make an effort to *not* be an ASN.1 tutorial.

But this would clarify the size of specific objects in the protocol.
How is that not useful if the spec is to be as clear as possible?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 17:45:15 -0500

assar> Tom Yu <[email-masked]> writes:
    >> largely, if not completely, of clarifications about the
    >> specific use of ASN.1 in Kerberos, or of implementation notes.
    >> I think we should make an effort to *not* be an ASN.1 tutorial.

    assar> But this would clarify the size of specific objects in the
    assar> protocol.  How is that not useful if the spec is to be as
    assar> clear as possible?

I tthink Tom is right and this clarification should be rejected.  The
problem is that when you include something from another spec by value
rather than by reference people familiar with that specification need
to make sure that you have correctly included the value references
rather than accidentally creating a new protocol.

For the same reason I find it incredibly annoying that RFC 1964
includes value references to several Kerberosv types.

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Nov 2002 22:25:32 +0100 (MET)

> already well defined in the ASN.1 standard?

Unless you can prove that there is one single document that
comprises the exact and complete ASN.1 standard that you're
referring to ... (and one that is easily and readily available
for at most $$ (and not $$$$+))  PLUS one that can actually
be understood with moderate time investments by mere mortals.

I really think it might be worth it.  If it isn't obvious what it means
to an actual Kerberos implementor, then it should be worth a comment
in the spec.

E.g. I think it is extremely useful that the GSS-API spec completely
describes the few ASN.1 structures/object that it uses so that
you can write your own parser even if you're an ASN.1 layman or
even ASN.1 illiterate (which applies to >95% of the implementors).

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Nov 2002 16:35:53 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> E.g. I think it is extremely useful that the GSS-API spec
    Martin> completely describes the few ASN.1 structures/object that
    Martin> it uses so that you can write your own parser even if
    Martin> you're an ASN.1 layman or even ASN.1 illiterate (which
    Martin> applies to >95% of the implementors).

I agree that for GSSAPI it is great that OID encodings are described.
However I'll point out that GSSAPI uses a lot less ASN.1 than
Kerberos.

We have over 10 years of evidence that says people who do not fully
understand the ASN.1 they are using should not implement Kerberos.
They'll get it wrong and the entire community will regret the
interoperability mess that is created.  I'd much rather restrict the
set of Kerberos implementers to people who are willing to spend a
fairly significant chunk of time understanding ASN.1 than provide
enough hints for people to hurt themselves but not enough detailed
instruction for them to get it right.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Nov 2002 14:00:24 -0800

The ASN.1 standards are available for free download.

ASN.1 has changed over time, of course.  Clarifications ought to
reference the latest standard, and since it is actually multiple
specifications, the ones that matter, really, are X.680 (1994 ASN.1),
X.682 (constraint specifications) and X.690 (BER/DER/CER spec).  Not one
document, but three, each referring to a different part of the ASN.1
whole.

The clarifications draft lists X.680 and X.690 in the references
section; it may need to reference X.682 as well.

The GSS-API's use of ASN.1 is so simple (so much simpler than Kerberos
V's) that it can reasonably be described as bits on the wire.  Kerberos
V's usage of ASN.1 is sufficiently complex as to be difficult to specify
as bits on the wire.

I don't think an ASN.1 layman can write his or her own parser, nor do I
see any easy way to describe to a layman how to write an encoder/decoder
for an ASN.1 spec without in the process also teaching them all that
would be necessary for them to no longer be an ASN.1 layman.

Cheers,

Nico

---

From: Leif Johansson <[email-masked]>
Date: Wed, 27 Nov 2002 23:31:09 +0100

Sam Hartman wrote:

<snip>

> They'll get it wrong and the entire community will regret the

True, however ITU have been known to change their specs. In the ldap
community the decision was made early on to reference X.500. Today we
are in a rathole of having to keep track of which version of X.500 we
reference and backport certain fixes included in later versions of
the standard...

I am not saying that referencing ASN.1 is a bad idea, just that there
may be unwelcome surprises down the road.

	leifj

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Nov 2002 23:52:30 +0100 (MET)

> However I'll point out that GSSAPI uses a lot less ASN.1 than

Agreed.

> instruction for them to get it right.

Although there is a lot of truth in this I feel very uncomfortable
with the conclusion.

The purpose of standardization of a protocol in the IETF is to
encourage, *not* discourage further independent implementations,
and the specification should facilitate this (and interoperability
among implementations) by trying to be as clear and precise as
possible and trying to avoid ambiguities and mysteries.
And yes, educating others about ASN.1 should be done because
there are still so few that fully understand ASN.1, and unfortunately
that includes several authors of ASN.1-ladden specs.

When we had the discussion about the use of CHOICE in the 
in the kerberos set/change password protocol, I asked the
following in a message the the ietf-krb list on May 15th, 2001:

:                           I haven't seen any explanation from
: the ASN.1 fanciers yet that explain how the CHOICE element
: used in this spec can be quickly implemented by the non-ASN.1
: guys so that this issue can be simply ignored.

However the document authors involved in the discussion seemed
either unable or unwilling to answer this question.

It wasn't until November 9th, 2001 when Tom Yu finally started
sheding light at what CHOICE actually means in DER encoding
(but on a completely different subject).

The use of ASN.1 and reluctance to elaborate on details upon
requests will significantly impair discussion and peer review
and probably not have a good effect on the document quality.

Each time when we can use precise language/description instead
of ASN.1 or each time we replace or enrich ASN.1 in a spec
with descriptive language it will improve the document quality
and ease peer review.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Nov 2002 13:51:24 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Although there is a lot of truth in this I feel very
    Martin> uncomfortable with the conclusion.

    Martin> The purpose of standardization of a protocol in the IETF
    Martin> is to encourage, *not* discourage further independent
    Martin> implementations, and the specification should facilitate
    Martin> this (and interoperability among implementations) by
    Martin> trying to be as clear and precise as possible and trying
    Martin> to avoid ambiguities and mysteries.  

I completely agree this is the goal of the standardization effort.  I
believe that the clearest way we can describe ASN.1 is to refer to the
ISO specification.  If we attempt to clarify it ourselves we are
likely to create ambiguities by accidentally disagreeing with the real
spec or by having different emphasis or simply by being too brief.

It is exactly because I believe we would ultimately decrease clarity
and interoperability  that I think we should not go down the route of
explaining ASN.1.

Note that the specification will still achieve its goal of increasing
number of interoperable implementations--you'll just have to solve the
sub project of understanding ASN.1 before starting on the Kerberos
spec.

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Nov 2002 21:01:38 +0100 (MET)

> sub project of understanding ASN.1 before starting on the Kerberos

Well -- humans are rarely born as ASN.1 experts.

The spec should care for those implementors that are still ASN.1 laymen --
although they might have an ASN.1 spec within reach or just finished
reading it, this most likely is their first encounter and they have
no prior experience/practice whatsoever.

They're going to stumble frequently at all those rough edges in ASN.1
which ASN.1 experts have learned to recognize and handle.  Therefore
the experts (which really should include the document authors of specs
that contain ASN.1) should definitely give helpful comments/hints
for the laymans whereever the spec hits a rough edge of ASN.1
to minimize frustration, casualties and broken implementations.
(sort of "dangerous" bend signs like in Donald E. Knuth's The TeXbook).

Really, there exist so few ASN.1 experts that this ought to be a MUST.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 30 Nov 2002 03:45:46 +0100

> spec or by having different emphasis or simply by being too brief.

Any particular reason Kerberos Clarifications reference the superseded
1997/1998 ASN.1 standard?

(None of the differences or resolved defects compared with more recent
standards affect Kerberos from what I have been able to tell, so this
is mostly academic, but if you want to solve the problems by
referencing elsewhere, using superseded documents seems not ideal.)

---

From: Marcus Watts <[email-masked]>
Date: Sat, 30 Nov 2002 01:28:37 -0500

Sam Hartman wrote:
...
> > spec or by having different emphasis or simply by being too brief.
...

I had always thought ISO specifications were expensive and
hard to get.  It's with some amazement I can say that I found a copy
referenced from:
	http://asn1.elibel.tm.fr/en/standards/
pointing to this:
	http://www.itu.int/ITU-T/studygroups/com17/languages/x680-x693_0702.pdf
I don't know if this is a permament thing, or a temporary aberation.

I also don't know how prone to confusion this document is - I've seen
other standards that were not sufficiently clear to permit unambiguous
interoperable implementations to co-exist.  For what it's worth, the
URL above points to an *newly updated* ASN.1 standard, although the
changes seem to be mainly the descriptive grammar not the wire
protocol.

				-Marcus Watts
				UM ITCS Umich Systems Group