Subject: Section 5 of clarifications - TODO

From: Clifford Neuman <[email-masked]>
Date: Sun, 16 Jun 2002 19:21:12 -0700 (PDT)

I have placed the new version of section 5 from Tom on the web site:

  http://www.isi.edu/people/bcn/krb-revisions

While I was making changes to my sections based on some notes rom Doug
Engert, I found some of his notes on the last version of his section,
and I include them below, together with some of my thougts on the
current version - and what needs to be resolved or done to move it
toward completeion.

In the interest of moving this along, and since these are all very
minor, I would like everyone in the group to look at the current
version and get Tom your feedback on what still needs to be changed,
if anything other than the issues listed below.  Additionally, any
feedback on the items listed below would be useful.

Cliff

---

Section 5.6 contains the text:

  There are two KRB_SAFE messages; the KRB-SAFE message is the one
  specified in RFC 1510.  The KRB-SAFE2 message is new with this
  document, and shares a number of fields with the old KRB-SAFE message.

Dough Engert had several comments on an earlier draft that he thoughts
this text was for extensions.  It is still in the clarifications
document as it stands now.  Does this need correction.  There are
still several other places where the KRB SAFE 2 message is listed.

Doug also commented that in krb-safe-body the s-address is supposed to
be optional.  It is not listed as such in the current draft.  The text
later on for s-address says that it may be omitted if not needed by
the application protocols.  The same comment about the optional
s-address applied to the encrypted part of the krb-priv message too.

5.5.2 There is a double in "in in" that needs to be corrected.

In 5.1.5 you have "due such tag numbers" and are missing a "to".

In section 5.2.2 Doug had a note that the pagraph following the realm
deifition assume ASCII, and he asked "So can be used in transited
field".  I think we can be clearer so that the statement applies more
generally.  I don't think ASCII is necessary for the transited
encodings to work, but the no null certainly is.

The paragraph:

  There are some members of messages types that are still defined as
  unconstrained INTEGER types, but many of these have a (non-ASN.1)
  constraint applied in the descriptive text.  There are specific cases
  where more discussion needs to occur regarding possible constraints,
  such as for the nonce fields in various messages.

in 5.2.4 seems to indicate we need to resolve something before last
call.  Do we have resolution on this?

Section 5.2.7 still has text that is flagged as neededing discussion.
We need to resolve these issues.  Also, the table of padata-types will
be included in section 8.  Do we want to remove the table here, or
leave it duplicated here.  I also note that type 20 was in the last
draft but was dropped here.

  20 had been pa-use-specified-kvno  DER encoding of INTEGER.

This was in Tom's notes as delted.  Doug had a comment on the earlier
draft that there was no ASN.1 specified for this.  Should it be left
out of claririfications?

There are some flags like transited policy-checked that are new since
1510.  We will of course list the flag as reserved by its current name
in clarifications, BUT, do we want to remove the definition of the use
of the flag from clarifications and move it to extensions.  My own
feeling is that for new flags that introduce no interoperability
issues, we can define them in clarification without issue.

In section 5.9.1., Doug had a comment about the desription in the
ASN.1 of "correct principal" and that we should be clearer about what
is intended, e.g. the principal assumed by the TGS, rather than the
one specified in the request?  "correct" just didn't seem like the
right word to use here.

---

From: Tom Yu <[email-masked]>
Date: 19 Jun 2002 16:33:03 -0400

>>>>> "bcn" == Clifford Neuman <[email-masked]> writes:

bcn> Section 5.6 contains the text:

bcn>   There are two KRB_SAFE messages; the KRB-SAFE message is the one
bcn>   specified in RFC 1510.  The KRB-SAFE2 message is new with this
bcn>   document, and shares a number of fields with the old KRB-SAFE message.

bcn> Dough Engert had several comments on an earlier draft that he thoughts
bcn> this text was for extensions.  It is still in the clarifications
bcn> document as it stands now.  Does this need correction.  There are
bcn> still several other places where the KRB SAFE 2 message is listed.

KRB-SAFE2 should not be present in krb-clarifications in any form.

bcn> Doug also commented that in krb-safe-body the s-address is supposed to
bcn> be optional.  It is not listed as such in the current draft.  The text
bcn> later on for s-address says that it may be omitted if not needed by
bcn> the application protocols.  The same comment about the optional
bcn> s-address applied to the encrypted part of the krb-priv message too.

The S-ADDRESS field in KRB-SAFE-BODY is *not* optional in
krb-clarifications, as it was required in rfc1510, and that would be a
backwards-incompatible change.

bcn> 5.5.2 There is a double in "in in" that needs to be corrected.

Either you've corrected this already in your copy, or I can't find it.

bcn> In 5.1.5 you have "due such tag numbers" and are missing a "to".

Likewise.

bcn> In section 5.2.2 Doug had a note that the pagraph following the realm
bcn> deifition assume ASCII, and he asked "So can be used in transited
bcn> field".  I think we can be clearer so that the statement applies more
bcn> generally.  I don't think ASCII is necessary for the transited
bcn> encodings to work, but the no null certainly is.

We assume ASCII anyway due to the constraint used on KerberosString.
There is an additional question: Should we further constrain realm
names and principal names to not contain control characters?  That
would simplify a number of things.  The primary reason for allowing
control characters in KerberosString would be to allow newlines,
horizontal tabs, etc. in error messages.

bcn> The paragraph:

bcn>   There are some members of messages types that are still defined as
bcn>   unconstrained INTEGER types, but many of these have a (non-ASN.1)
bcn>   constraint applied in the descriptive text.  There are specific cases
bcn>   where more discussion needs to occur regarding possible constraints,
bcn>   such as for the nonce fields in various messages.

bcn> in 5.2.4 seems to indicate we need to resolve something before last
bcn> call.  Do we have resolution on this?

This was an error; the paragraph should be deleted, as I believe there
are no longer any unconstrained occurrences of INTEGER in the ASN.1.

bcn> Section 5.2.7 still has text that is flagged as neededing discussion.
bcn> We need to resolve these issues.  Also, the table of padata-types will
bcn> be included in section 8.  Do we want to remove the table here, or
bcn> leave it duplicated here.  I also note that type 20 was in the last
bcn> draft but was dropped here.

The note preceding the paragraph that starts "This field may also
contain information" may be deleted, in my opinion.  I think I left it
there by mistake.

The paragraph beginning "When this field is used to" and the
accompanying note should be deleted.  Their content falls under the
category of authenticated plaintext, which we decided to leave for
krb-extensions.

I think for now that duplicating the table is the best approach; the
document could stand to be reorganized to reduce duplication of
information, but that would likely take longer than is optimal.

bcn>   20 had been pa-use-specified-kvno  DER encoding of INTEGER.

bcn> This was in Tom's notes as delted.  Doug had a comment on the earlier
bcn> draft that there was no ASN.1 specified for this.  Should it be left
bcn> out of claririfications?

It was not present in rfc1510, and I know of no implementations.

bcn> There are some flags like transited policy-checked that are new since
bcn> 1510.  We will of course list the flag as reserved by its current name
bcn> in clarifications, BUT, do we want to remove the definition of the use
bcn> of the flag from clarifications and move it to extensions.  My own
bcn> feeling is that for new flags that introduce no interoperability
bcn> issues, we can define them in clarification without issue.

I was under the belief that at the interim meeting we decided that
TRANSITED-POLICY-CHECKED and the related flags were to be included in
krb-clarifications.  We lack reasonable specification for
implementation behavior upon encountering unrecognized flags in
various cases, and research needs to be done regarding established
implementation behavior when presented with unrecognized flags.
Actually, this needs to be done for other "holes" that existed in
rfc1510, such as PA-DATA and AuthorizationData.

bcn> In section 5.9.1., Doug had a comment about the desription in the
bcn> ASN.1 of "correct principal" and that we should be clearer about what
bcn> is intended, e.g. the principal assumed by the TGS, rather than the
bcn> one specified in the request?  "correct" just didn't seem like the
bcn> right word to use here.

This was copied text from rfc1510.  I do not know what the
interpretation of that comment was to be in rfc1510, as there was no
real explanatory text accompanying the ASN.1 comment.  Perhaps we
should drop it for now and leave it up to the implementation, or
specify it as being "server principal and realm copied from the
KDC-REQ".  There is the possibility of a KRB-ERROR return being
appropriate in situations where the party generating the KRB-ERROR
message is unable to determine the principal/realm names in the
request, so we'd need a well-defined exception case for this.

---Tom