Subject: comments on krbclar-draft-03.txt

From: Simon Josefsson <[email-masked]>
Date: Fri, 03 Jan 2003 04:51:51 +0100

I have not received any announcement from IETF about the updated
draft, but I looked briefly at krbclar-draft-03.txt.

,----
| 3.4.1. Generation of a KRB_SAFE message
| 
| When an application wishes to send a KRB_SAFE message, it collects its data
| and the appropriate control information and computes a checksum over them.
| The checksum algorithm should be the keyed checksum mandated to be
| implemented along with the crypto system used for the sub-session or session
| key. The checksum is generated using the sub-session key if present, or the
| session key.
`----

The last sentence seem incorrect given the first paragraph of 3.2.6.
According to 3.2.6 KRB_SAFE does not have to use the (sub-)session
key.

,----
| 3.4.2. Receipt of KRB_SAFE message
| 
| When an application receives a KRB_SAFE message, it verifies it as follows.
| If any error occurs, an error code is reported for use by the application.
| 
| The message is first checked by verifying that the protocol version and type
| fields match the current version and KRB_SAFE, respectively. A mismatch
| generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
| application verifies that the checksum used is a collision-proof keyed
| checksum that uses keys compatible with the sub-session or session key as
| appropriate, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated.
`----

It does not have to be compatible with the sub-session or session key,
judging by 3.2.6.  Perhaps it should be compared with the derived
application key for key type compatibility.

,----
| 3.5.1. Generation of a KRB_PRIV message
| 
|    When an application wishes to send a KRB_PRIV message, it collects
|    its data and the appropriate control information (specified in
|    section 5.7.1) and encrypts them under an encryption key (usually the
|    last key negotiated via subkeys, or the session key if no negotiation
|    has occurred). As part of the control information, the client must
`----

Again, what key to use is up the application according to 3.2.6.

,----
| KDC-REQ         ::= SEQUENCE {
|         -- NOTE: first tag is [1], not [0]
|         pvno            [1] INTEGER (5) ,
|         msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
|         padata          [3] SEQUENCE OF PA-DATA OPTIONAL
|                             -- NOTE: not empty --,
|         req-body        [4] KDC-REQ-BODY
| }
`----

Why not use SIZE(1..MAX) instead of the "not empty" comment?

Currently it is unclear if an empty field should be treated as a
syntacticaly error, or simply be treated as a empty field.  Handling
syntactical errors explicitly in the ASN.1 syntax is more robust.
Existing implementations seem to handle empty fields correctly in the
few cases I've tried, so if SIZE(1..MAX) is considered too
restrictive, I suggest dropping the comment or explaining what to do
when it is empty.

,----
| -- NOTE: AuthorizationData is always used as an OPTIONAL field and
| -- should not be empty.
| AuthorizationData       ::= SEQUENCE OF SEQUENCE {
`----

Same here: SIZE (1..MAX)?

AuthorizationData is not always used as an OPTIONAL field as far as I
can see.

This "not empty" issue applies to several places.

,----
|    [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.
`----

See section 10(3.2) of RFC 2026 on IPR issues and copyright and more.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Jan 2003 03:21:14 -0500

Hi.  I think there was a previous working group consensus not to
restrict fields that should be empty in the syntax, even though we
agreed doing so would be nice.  The problem is that we don't want to
break existing implementations that may send empty sequences.

It's very likely this will be fixed for extensions.

While it is Doug's call as chair, it doesn't sound like you are
bringing up anything new that wasn't already covered when this
consensus was reached.

Also, I may be confused about what was decided.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 03 Jan 2003 15:34:46 +0100

> bringing up anything new that wasn't already covered when this

OK.  Sorry for bringing up old news; I have not followed the
discussions here closely.