Subject: Name type for new mechanism

From: Wesley Leggette <[email-masked]>
Date: Wed, 25 Mar 2009 21:04:16 -0500

I am current writing an I-D for our password mechanism, which we are calling
"Basic Password Authentication Mechanism".

Our mech requires three name forms: user name, host-based service, and
account identifier.

My questions:

1. We take "account identifier" to be an account UUID/GUID because we make
use of this form in our application. Is it reasonable to require this in a
mechanism in general, or is this more a SHOULD sort of thing?

2. We support federated systems and as such allow a "realm" to be indicated.
However, our current implementation interprets a user name or service-based
host similiarly to Kerberos but uses the OIDs for mechanism-independent name
forms. Is this kosher, or should we use mech-specific OIDs?

Here's what we're talking about as for User Name Form:

--------------------------------------------

2.1.  User Name Form

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

   This name type is used to indicate a named user on a local,
   distributed, or federated system.  The elements included within this
   name representation are as follows, proceeding from the beginning of
   the string:

   1.  One principal name component.  Arbitrary octets may be included
       within the principal name component, with the following
       constraints and special considerations:

       A.  The `@` character is restricted.

       B.  The ASCII newline, tab, backspace, null, and other non-
           printable characters SHOULD NOT be generated.  Peers MAY
           accept such characters.

   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 `@` character is restricted
       from appearing within the realm name.

   Interpretation of the realm name is application specific.  Peers MUST
   be prepared to interpret a user name without a specified realm.
   Peers MAY ignore the realm name if a non-federated authentication
   system is in use.

--------------------------------------------

Thanks,
Wesley Leggette

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Mar 2009 22:05:19 -0500

> mechanism in general, or is this more a SHOULD sort of thing?

I think it's fine to REQUIRE support for it, but since in any security
context there are only two names involved (the initiator's and the
acceptor's) the question I find interesting is:

When would an application use "user name" and when "account identifier"?

> forms. Is this kosher, or should we use mech-specific OIDs?

You should define mechanism-specific name types, or, if these are
sufficiently similar to Kerberos V's, then reuse those.  But it's
probably OK (if not strictly so) for a mechanism implementation to
support mechanism-specific syntaxes with GSS_C_NT_USER_NAME (it's
certainly for name_type == GSS_C_NO_OID).

>            printable characters SHOULD NOT be generated.  Peers MAY

Is the username UTF-8?  What stringprep will you use for it?

(Same questions re: password.)

>        from appearing within the realm name.

It's not so much that '@' in a realm name is problematic, but '@' in a
username -- I've seen that be requested, e.g., in the case of SSHv2.

Now, typically one can determine a realm from a user's domainname, so
this is not really an issue, but if you disallow '@' in realms then you
can support:

    user@			-> user in local realm
    user@domain@		-> user@domain in local realm
    user@domain-or-realm	-> resolve a realm name
    user@domain@realm		-> user@domain in given realm
    user@realm@@		-> user in given realm

>    Peers MAY ignore the realm name if a non-federated authentication

I find this confusing.  If an application specifies a realm then the
peer had better know about it, right?  Having the acceptor ignore the
realm if it doesn't know it seems wrong.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Mar 2009 08:45:31 -0700

--On Wednesday, March 25, 2009 10:05:19 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> 2. We support federated systems and as such allow a "realm" to be
>> indicated. However, our current implementation interprets a user name or
>> service-based host similiarly to Kerberos but uses the OIDs for
>> mechanism-independent name forms. Is this kosher, or should we use
>> mech-specific OIDs?
>

If the mechanism supports a name type with the syntax and semantics of 
GSS_C_NT_USER_NAME, then it should use that OID.  Kerberos supports a name 
type that is unique to Kerberos, because it actually _has_ names whose 
syntax and semantics are unique to Kerberos.  A mechanism that identifies 
users with a simple username should just use GSS_C_NT_USER_NAME.

However, the name type described assigns mechanism-specific semantics to 
the '@' character which are not part of those defined for 
GSS_C_NT_USER_NAME.  Thus, it is a different name type and needs its own 
OID.

> realm if it doesn't know it seems wrong.

Agree.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Mar 2009 23:11:19 +0100 (MET)

> mechanism in general, or is this more a SHOULD sort of thing?

It is perfectly OK to require specific name type in a gssapi mechanism
spec.  Such a mechanism-specific nametype MUST use its own nametype OID.
If you're the mechanism spec author of a new gssapi mechanism, then you
can assign the OID yourself and define the exact semantics.

For GSS-API v2, one actually needs two mechanism-specific nametypes
defined: one printable and one binary canonical.

(In case you're wondering where to get an OID from -- its usually much
 easier to obtain an entire OID arc for free from the IANA registry
 SNMP private enterprises, than to officially "lease" an OID arc for
 a significant yearly fee from your (companies) national ISO member body).

The username and userid nametypes in the high-level gssapi spec
are specifically for use of the notion of "users" as seen by the local OS,
which, on traditional Unix, is a host-local account.

The exact semantics of the "username" are dictated by the OS.
On Windows, a "username" as seen by the OS is case-INsensitive.

The exact syntax and semantics of a mechanism-specific nametype, such
as a Kerberos Principal Name is defined by the Kerberos 5 gssapi mechanism.
Kerberos Principal Names are case-sensitive.

In that respect,

- if a Kerberos gssapi mechanism is passed a printable name along with
  a GSS_C_NT_USER_NAME nametype can process it in an case-insensitive
  fashion _IF_ usernames are case-insensitive for the underyling OS.

- if a Kerberos gssapi mechanism is passed a printable name along with
  a GSS_C_NT_USER_NAME nametype and parses it as a Kerberos Principal
  name instead, that is, for inputs to gss_import_name, still under the
  "be liberal in what you accept" umbrella because of the "similarity"
  and traditions of how to derive kerberos principal names.

- a printable output of gss_display_name() along with GSS_C_NT_USER_NAME
  should only be done for one of the following:
    - printable names that were imported with that nametype and
      are still completely unprocessed
    - printable names that were imported with that nametype and
      processed only by username-related functions of the
      underlying OS
    - printables names that were originally created from
      username-related functions of the underlying OS

  On Windows, the Username as seen by the OS is the representation
  returned from "GetUserName" or "GetUserNameEx(NameSamCompatible)"
  (the other Name formats known the GetUserNameEx() would all count
   as seperate distinct nametypes).

- if the representation of a printable name of type GSS_C_NT_USER_NAME
  is transformed in a mechanism-specific fashion, then the result belongs
  to a different (mechanism-specific) namespace / nametype.

- if a Kerberos gssapi mechanism is passed a printable name along with
  GSS_C_KRB5_NT_PRINCIPAL_NAME (as defined by rfc1964 2.1.1) and
  processes it in a case-INsensitive fashion, it is likely broken
  (I admit that I don't know what kind of hacks were "common" in
   "krb5_parse_name()" at the time rfc-1964 was published, so the
   exact meaning of rfc1964 2.1.1 looks quite fuzzy in that respect).

- 

> forms. Is this kosher, or should we use mech-specific OIDs?

I would strongly recommend that you define a new nametype (and therefore
assign a new nametype OID) for that purpose, UNLESS you plan to completely
conform to the syntactic rules of an existing mechanism-specific
nametype like a Kerberos Principal Name--and use only a normative
reference to the Kerberos Principal Name nametype of the
Kerberos GSS-API mechanism spec (rfc1964 for the nametype).

>    type is "GSS_BPAM_NT_USER_NAME".

Assigning your own symbolic name is probably a good idea, but you
MUST assign your own OID for the nametype, abusing

>        from appearing within the realm name.

You can make that part of the definition of a mechanism-specific
nametype.

In order to implement a "exported binary canonical name" you have
to address a few more things:

  - are your names going to be case-sensitive or case-INsensitive,
    and if the latter, what is the canonical representation and
    how is canonicalization to be performed exactly.

  - what character set or code page will your implementation use, and
    what is the character set / codepage in the binary canonical names?

    rfc-2743 (gss-api c-bindings) has a historical affiliation with iso-latin1

>    Peers MAY ignore the realm name if a non-federated authentication

For the acceptor, this would be "non-portable" behaviour in the
GSS-API architecture.  In the GSS-API architecture, the acceptor
(usually the server) obtains the authenticated name of the 
initiator as a result of a successfuly security context establishment
handshake via the src_name parameter of gss_accept_sec_context().

GSS-API aware "portable" application (Servers) will export that
resulting src_name as binary canonical name and look it up in an ACL.

On the initiator side it is much more common to start with a memorized
non-ambiguous representation of the targets name and use a
secure directory service or have a secure transformation of that
name be transformed withing gss_init_sec_context() -- in case that
the initiator _really_ cares about actually authenticating the acceptor.

(It is, however, not so uncommon that initiators care little about target
 authentication and use some kind of weak identification scheme for
 the target instead, e.g. by blindly deriving the target/acceptor name
 from network endpoint addresses, ignore ambiguities, or perform
 or allow insecure transformations on the name.

For simple gss-api mechanisms, which perform only a uni-directional
authentication of the initiator to the acceptor, the "target_name"
parameter to gss_init_sec_context() may be omitted (per GSS-API v2 spec).
If not omitted, it ought to be ignored by the gssapi mechanism.

There are gssapi mechanism, such as Kerberos 5 (rfc1964/rfc4121),
which always require a correct target_name parameter to be supplied to
gss_init_sec_context(), even when ONLY uni-directional authentication
is requested and performed.  (That is a constraint of the underlying
mechanism design.)

-Martin