Subject: Updating the GSSAPI-CFX draft: GSS Names in the Kerberos v5 mechanism

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Nov 2004 00:51:13 -0800

Late last year we set out to write a draft on the Kerberos V5 GSS-API
mechanism using AES and newer enctypes, and we wanted to make sure that
folks implementing this mechanism should not need to read RFC 1964.  The
scope of the draft was well-defined, and we got our draft out fairly
quickly.

Recently it came to my attention we did not accomplish our mission. More
specifically the existing document set (RFC 2743, RFC 2744,
clarifications, kcrypto, AES-ID) does not have sufficiently detailed
information for Kerberos specific GSS names.

I pulled in the relevant text from RFC 1964 and updated the references.
Sam and Jeff (Jhutz) reviewed the text; both of them agreed there were
no significant changes between this text and that of RFC1964. I asked
Martin to review the changes, but he was not able to comment and the
IETF61 is approaching.

I propose to add the text below as a new section and make this addition
within the authors' last 48 hours.  It is understood that there must be
agreement from both the WG and the AD to make such change.  Here I bring
up the text to the list and please review.  I strongly believe myself
this is the right thing to do. I will speak with Russ about this at
Washington DC next week, if we have rough consensus on the text.  

=====================================================================
6.  Name Types and Object Identifiers

   This section discusses the name types which are passed as input to
   the Kerberos Version 5 GSS-API mechanism's GSS_Import_name()
   [RFC2743] call, and their associated identifier values.  It defines
   interface elements in support of portability, and assumes use of C
   language bindings per [RFC2744].  In addition to specifying OID
   values for name type identifiers, symbolic names are included and
   recommended to GSS-API [RFC2743] implementers in the interests of
   convenience to callers.  It is understood that not all
   implementations of the Kerberos Version 5 GSS-API mechanism need
   support all name types in this list, and that additional name forms
   will likely be added to this list over time.  Further, the
   definitions of some or all name types MAY later migrate to other,
   mechanism-independent, specifications.  The occurrence of a name type
   in this specification is specifically not intended to suggest that
   the type MAY be supported only by an implementation of the Kerberos
   Version 5 mechanism.  In particular, the occurrence of the string
   "_KRB5_" in the symbolic name strings constitutes a means to
   unambiguously register the name strings, avoiding collision with
   other documents; it is not meant to limit the name types' usage or
   applicability.

   For purposes of clarification to GSS-API implementors, this section's
   discussion of some name forms describes means through which those
   forms can be supported with existing Kerberos technology.  These
   discussions are not intended to preclude alternative implementation
   strategies for support of the name forms within Kerberos mechanisms
   or mechanisms based on other technologies.  To enhance application
   portability, implementors of mechanisms are encouraged to support
   name forms as defined in this section, even if their mechanisms are
   independent of Kerberos Version 5.

6.1  Mandatory Name Forms

   This section discusses name forms which MUST be supported by all
   conformant implementations of the Kerberos Version 5 GSS-API
   mechanism.

6.1.1  Kerberos Principal Name Form

   This name form is represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   krb5(2) krb5_name(1)}.  The recommended symbolic name for this type
   is "GSS_KRB5_NT_PRINCIPAL_NAME".

   This name type corresponds to the single-string representation of a
   Kerberos name.  The elements included within this name representation
   are as follows, proceeding from the beginning of the string:

   (1) One or more principal name components; if more than one principal
      name component is included, the components are separated by `/`.
      Arbitrary octets MAY be included within principal name components,
      with the following constraints and special considerations:

      (1a) Any occurrence of the characters `@` or `/` within a name
         component MUST be immediately preceded by the `\` quoting
         character, to prevent interpretation as a component or realm
         separator.
      (1b) The ASCII newline, tab, backspace, and null characters MAY
         occur directly within the component or MAY be represented,
         respectively, by `\n`, `\t`, `\b`, or `\0`.
      (1c) If the `\` quoting character occurs outside the contexts
         described in (1a) and (1b) above, the following character is
         interpreted literally.  As a special case, this allows the
         doubled representation `\\` to represent a single occurrence of
         the quoting character.
      (1d) An occurrence of the `\` quoting character as the last
         character of a component is illegal.
   (2) OPTIONALLY, a `@` character, signifying that a realm name
      immediately follows.  If no realm name element is included, the
      local realm name is assumed.  The `/` , `:`, and null characters
      SHALL NOT occur within a realm name; the `@`, newline, tab, and
      backspace characters MAY be included using the quoting conventions
      described  in  (1a), (1b), and (1c) above.

6.1.2  Host-Based Service Name Form

   This name form is described in Section 4.1 of [RFC2743].

6.1.3  Exported Name Object Form for Kerberos Version 5 Mechanism

   This name form is represented by the "GSS-API Exported Name Object"
   OID value as defined in Section 4.7 of [RFC2743].

   This name type represents a self-describing object, whose framing
   structure is defined in Section 3.2 of [RFC2743].  When generated by
   the Kerberos Version 5 mechanism, the Mechanism OID within the
   exportable name is that of the Kerberos Version 5 mechanism.  The
   name component within the exportable name MUST be a contiguous string
   that represents a Kerberos Principal name.

   In order to achieve a distinguished encoding for comparison purposes,

   the following additional constraints are imposed on the export 
   operation:

   (1) All occurrences of the characters `@`,  `/`, and `\` within
      principal components or realm names MUST be quoted with an
      immediately-preceding `\`.
   (2) All occurrences of the null, backspace, tab, or newline
      characters within principal components or realm names MUST be
      represented, respectively, with `\0`, `\b`, `\t`, or `\n`.
   (3) The `\` quoting character SHALL NOT be emitted within an exported
      name except to accommodate the two cases above.

6.2  Optional Name Forms

   This section discusses additional name forms which MAY be supported
   by implementations of the Kerberos Version 5 GSS-API mechanism.
   Inclusion of this support within GSS-API implementations is intended
   as a convenience to applications.

6.2.1  User Name Form

   This name form is described in Section 4.2 of [RFC2743].  Assuming
   that users' principal names are the same as their local operating
   system names, an implementation of GSS_Import_name() based on
   Kerberos Version 5 technology can process names of this form by
   post-fixing an "@" sign and the name of the local realm.

6.2.2  Machine UID Form

   This name form is described in Section 4.3 of [RFC2743].

6.2.3  String UID Form

   This name form is described in Section 4.4 of [RFC2743].
====================================================================

-- Larry

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Nov 2004 09:50:14 -0600

Can this be addressed by making the new RFC update, rather than obsolete
rfc1964?

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 03 Nov 2004 11:08:32 -0500

I suggest that the working group chair should discuss the process for 
this update with the Area Director to determine what the most 
appropriate process is for this change (assuming it receives WG 
approval).  While I do not disagree with the inclusion of the text I 
question the process by which the text is being added.

I believe the authors 48 hour window is meant for the correction of 
typographical and perhaps gramatical errors.  It is not meant for the 
addition of significant quantities of text even if that text is 
copy/pasted from an existing RFC which is referenced.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Nov 2004 15:21:05 -0600

Allow me to make one more point, if I may.

Folks, earlier versions of the cfx I-D had it *obsoleting* rfc1964, then
we briefly discussed whether it should do so and pull in all the
necessary text from rfc1964 (but note, we did not specifically discuss
the naming section) or make cfx *update* rfc1964.

Recent versions of the cfx I-D, needless to say, claim to *update*
rfc1964.

I know, I just searched the archive.

I find myself quite surprised, though not very concerned, by this
thread.  It seems too late to be changing our minds on that point.
Although that's not being proposed, given that only the krb
AES256-CTS-HMAC-SHA1-96 enctype is REQUIRED in clarifications,
technically pulling in the naming text from rfc1964 into the cfx I-D
might suffice to obsolete rfc1964.

> information for Kerberos specific GSS names.

Larry, did you get a complaint from someone?  If so, why wasn't that
complaint forwarded to this list?

Anyways, proceed if you must and the AD et. al. agree, but I don't think
there's any need to do this -- none has been presented anyways.

Nico
--