[34] in GSSAPI Development
[Percy Tzelnic: Meeting notes: Athena/Kerberos - DEC/SPX; 4/17/91 ]
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed May 1 18:39:32 1991
Date: Wed, 1 May 91 18:39:23 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: gssapi-dev-mtg@menelaus.mit.edu
Reply-To: tytso@athena.mit.edu
------- Forwarded Message
Date: Wed, 1 May 91 12:05:20 PDT
From: Percy Tzelnic <tzelnic@pmaxpt.enet.dec.com>
To: jis@ATHENA.MIT.EDU, "jtkohl@athena.mit.edu"@Pa.dec.com,
"jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
kahn@zendia.enet.dec.com, linn@zendia.enet.dec.com,
wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
kaufman@kibitz.enet.dec.com, tzelnic@Pa.dec.com
Subject: Meeting notes: Athena/Kerberos - DEC/SPX; 4/17/91
Cc: ultra::lipner, ultra::gasser, ultra::modeen, zendia::sanders,
erlang::patel, tl::lauck, mailto::frampton, nac::kirby, erlang::wilde,
nac::tardo, took::schimpf, smurf::ferson, lassie::lawler, smurf::hu,
smurf::williams
I am pleased to distribute these notes, which mark our reaching an important
milestone in agreeing on a common API across multiple authentication
mechanisms, in particular Kerberos and SPX. (This API is based on John Linn's
GSSAPI, and on John Wray's corresponding C-binding.)
My thanks to you all.
Percy
-------
<Notes taken by Kannan Alagappan>
Participants:
-------------
DEC - Kannan Alagappan, Charlie Kaufman, John Linn,
Percy Tzelnic, John Wray
MIT - John Carr, John Kohl, Jeff Schiller, Ted T'so
Meeting goals:
--------------
1. Reach agreement on GSSAPI naming issue
Agenda (proposed):
------------------
1. Opening remarks (goals, agenda, etc.)
2. Discuss two issues with naming (handouts provided at meeting)
a) Name representation
b) Importing application information
3. Discussion; action items, closure of the GSSAPI topic
4. Closure and summary
Brief summary:
--------------
The three hour discussion on naming was very lively! It helped
all of us understand the issues better. Thanks to a compromise
solution proposed by Jeff Schiller, we managed to reach agreement
on the naming issue, which would allow building of portable applications
(such as telnet and rlogin). The proposal is not in itself
sufficient to support construction of a single GSSAPI implementation
supporting both mechanisms, though hooks remain for future generalization
towards this goal.
The summary of the agreements:
1) "import" would accept a null nametype and a string of the form
"SERVICE:service@host-as-internet-name". (Acceptance of null nametype
is in addition to implementations' acceptance of any non-null nametypes
they choose to register and support.)
2) "display" would produce names of the form "KERBEROS:service.inst@realm"
in the case of Kerberos and "SPX:/C=US/.../CN=foo" for SPX. (It was
strongly argued at the meeting that identifiers of name types should be
independent of mechanisms.)
3) We will continue discussions of other possible nameforms at future
meetings.
Discussion:
-----------
The discussion on name representation covered the following points:
- It was observed that authentication names at some level (either as
an input argument specified by a user or as a name on an ACL entry)
need to be represented as printable strings.
- Athena stated their strong preference for using printable string names
across the API, emphasizing the simplicity and ease of implementation
for their mechanism. Cost and FTP availablility of X/Open standards was
another Athena concern.
- The current C-binding spec calls for names to be represented
only in the X/OPEN format, stressing that no canonical printable
name representation exists and therefore the X/OPEN format makes
sense - as an emerging standard.
- An alternate proposal was submitted, for names to be represented as an
opaque pointer and a tag, where the tag determines the structure
pointed at. Each mechanism could decide on which name types
it was willing to support (if more than one.) However, some
participants found this solution unacceptable since it required
an extra argument for every name.
- Jeff Schiller proposed a compromise solution whereby names are
represented as opaque structures without tagging. The decision on
how API-internal names are actually represented is left to each GSSAPI
implementation.
- As an implication of API-internal names' opacity, portable applications
will be able to generate authenticable names only by invoking "import_name"
and to examine them only by examining the output from "display_name."
"compare_name" remains available as a means to compare API-internal names.
No portable application will be able to depend on the structure of
API-internal names.
The discussion on importing application information covered a wide
range of topics such as the need for a "name_glue" routine, the
different types of names, and how authorization might work in the
current spec. Without summarizing the entire discussion, I would
like to highlight the major points.
- It was observed that Kerberos and SPX applications authenticate
server principals with different granularity. Therefore the
initial conversation focused on how to represent this difference
of authentication granularity at the interface.
- The current C binding spec proposes a printable string and a name type
OID, which determines the syntactic coding of the printable string, as
input to the "import" function.
- An alternate solution proposed that we hide the name type OID from
application developers by explicitly passing the `generic' target
information to a modified "import" function. [Described in handout.]
- Jeff Schiller proposed that the modified "import" function should
actually be an additional alternative to "import_name", not a
replacement for it. Also, Jeff referred to it as a private, rather
than a GSS routine.
- It was observed that the authorization model in the current spec
requires that each ACL entry be imported to an internal name format.
Then, the internal name is compared with the name returned from an accept
context call. Jeff pointed out that two names which compare successfully
may not be sufficient to authorize a user access to a service. We agreed
not to try to solve multiple trust paths issues at this time.
- Jeff and Ted T'so stated that the name being passed into the "import"
function should be a self-describing printable name in order for
authorization to work. Ted pointed out that the current C binding
spec for "display_name" should be fixed to return an OID parameter
to describe the type of the output name. We discussed adding an input
name_type OID parameter to "display_name", qualifying the translation
from internal form, but no consensus was reached on this point.
- Jeff expanded the discussion on self-describing printable names. He
observed that the GSSAPI should be able to import authentication names
such as "SERVICE:service@host-as-internet-name" and "UID:uid". Note that
these names would be created by the application developer and they would
not appear on ACLs.
- Also, the GSSAPI should be able to import authentication names that
appear on ACLs such as "KERBEROS:service.inst@realm" and
"SPX:/C=US/.../CN=foo". We should seek further agreements for
self-descriptive printable forms (e.g., for X.500 names.)
- Jeff Schiller proposed a compromise solution whereby the "import"
function will accept a self-describing printable name and a NULL
name type. Specification of a NULL input_name_type to import_name will
indicate that the input name's interpretation is not specified through
the OID mechanism, thus it is a local matter based on interpretation of the
input string.
- In order to achieve SPX <-> Kerberos portability by working around the
current mismatch between SPX node-granularity verifier credentials and
conventional Kerberos service-granularity verifier credentials, we made
an implementors' agreement that both implementations of import_name will
be able to accept (along with a NULL input_name_type tag) the form:
"SERVICE:service@host-as-internet-name."
No restrictions on the output of display_name were defined. Other API
external name forms will be defined by mechanism designers, hopefully
to converge in later agreements.
Action items:
-------------
1. John Wray to issue a revised version of the spec.
2. Develop a prototype of the GSSAPI and demonstrate application
portability across Kerberos and SPX (Ted T'so and Kannan Alagappan.)
3. Meet, after we have a working prototype, to discuss what we've
learned from this work.
------- End Forwarded Message
