Subject: Re: Kerb WG iakerb

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Feb 2002 7:54:34 EST

The reality is that most of the authors of the Kerberos revisions
documents have been far too focused on attempting to solve the
numerous problems with the base documents to spend any time examining
the many side documents which have been sent to last call.  It is
unlikely that during this period that documents such as IAKERB will
receive the attention they require.

I agree with Martin's unease at (b).  However, IAKERB would not be the
first use of long term storage of the user's long term password on the
system.  Microsoft Windows already stores to the long term password in
order to attempt to retrieve new TGT's automatically before they
expire; or for use in comparing the end user's secret when waking up
from an suspend mode or returning to a locked workstation.  I believe
other OS's do similar things.

I'm more concerned with the inability to require the use of Pre-Auth
data for two reasons.  (1) offline dictionary attacks; (2) pre-auth is
the primary way we have of extending the Kerberos 5 protocol to
support extensibility and internationalization.  If IAKERB cannot
require the use of Pre-Auth it will be incompatible with future
versions of Kerberos 5.

- Jeff

> I don't know whether I ever explained why the underlying IAKERB
> message exchange makes me uncomfortable (which is why I would
> really appreciate if Kerberos Gurus would comment on this part
> of the proposal).
> 
> (a) requires the KDC to issue a service ticket to a user
> 
> (b) requires the Kerberos implementation of the user to cache
>     the user's longterm credentials indefinitely
> 
> (b)
> As far as I understood it was meant to be a feature that the user's
> "ticket manager" program (be it kinit or something more sphisticated)
> would need to have the user's long term secret only for a very short
> time to be able to decrypt the AS_REP response from the KDC, so
> that the window of exposure for this longterm key remains as
> small as possible.
> 
> (a)
> Since user's long term secrets are much more vulnerable to dictionary
> attacks than the (hopefully randomly generated) long term keys there
> is a potential danger in allowing the KDC to issue AP_REQ for
> user principals -- because these can be used to mount offline
> dictionary attacks.
> 
> In order to minimize the possibility for offline dictionary attacks
> against user's long term keys the KDC should be permitted to:
> 
> * deny issuing service tickets for users (user2user tickets
>    are different in that they use a strong random key)
> 
> * deny issuing TGTs in absence of valid pre-authentication data
> 
> However this would be incompatible with the current IAKERB proposal.
> 
> 
> -Martin
> 

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 available now!!!
 The Kermit Project @ Columbia University   includes Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 [email-masked]                OpenSSL. Interfaces with OpenSSH

---

From: "Jonathan Trostle" <[email-masked]>
Date: Wed, 13 Feb 2002 09:43:33 -0800

----- Original Message -----
From: "Jeffrey Altman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, February 13, 2002 4:54 AM
Subject: Re: Kerb WG iakerb

> receive the attention they require.

It went through WG last call so it should hopefully be done - I did get some
good comments from several WG participants.

> other OS's do similar things.

I too agree with Martin's unease. IAKERB shouldn't (and hopefully doesn't in
the current spec.) require long term storage.

> require the use of Pre-Auth it will be incompatible with future

Right.

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 19:47:33 +0100 (MET)

Jonathan Trostle wrote:
> Jeffrey Altman wrote:

I don't see how you could change that as long as the IAKERB proxy
uses a service ticket addressed at the user principal encrypted
with the user's longterm key.  GSS-API doesn't have means to
set or request a password/secret for acquisition of credentials
or establishment of a security context so the long term secret needs
to be supplied to IAKERB outside of the GSS-API and cached so
that when an application is launched and requests the IAKERB
mechanism the message exchange can actually be performed.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Feb 2002 13:39:44 -0500

There's no reason why one could not design an API that includes the
ability to prompt the user, like PAM, say, for whatever passwords and
tokens are needed and *still* be compliant with GSS-API on the wire.

GSS-API and GSS-API bindings are not the same thing.

:)

That said, the default behaviour by most implementations can probably be
relied upon to be password-caching. Sigh.

Nico

-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Mon, 18 Feb 2002 16:34:25 +0100 (MET)

> tokens are needed and *still* be compliant with GSS-API on the wire.

You got it backwards.

GSS-API is explicitly both, on-the-wire and API behaviour.

The focus, however, is actually on the API -- one single API and
API behaviour for all applications and years to come!

GSS-API mechanisms (which define on-the-wire) were supposed to be
rev'able and replacable as a design feature of GSS-API from the
beginning.  In reality, lacking a negotiation and/or migration
support in the base requirements for GSS-API mechanisms often
makes it difficult to actually replace a mechanism within an
installed base, requiring either a mechanism itself to provide
interoperability with its successor (version) or a flag day.

> relied upon to be password-caching. Sigh.

The default behaviour *must* be password caching.

Ted Ts'o once proposed a GSS-API extension to supply a callback
function for actual credential acquisition in order to interactively
prompt the user.  Such an extension, however, might only be used
by future applications to modify the existing (default) behaviour
of a GSS-API mechanism.

Do you know what happens if you run some program as a Win32
(non-interactive) service and some function suddenly decides
to open a dialog box expecting user input? 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Feb 2002 10:07:39 -0500

> GSS-API is explicitly both, on-the-wire and API behaviour.

I didn't say otherwise. I think that one can meet the spirit of GSS-API
without having to stick to the GSS-API C bindings RFCs.

If one were to add some extensions to the GSS-API C bindings in some
implementation one might still be compliant with RFC2078 even if not
with the bindings RFCs. Of course, to the extent that RFC2744 and 2078
disagree today it's hard to be compliant with both (e.g., name string
encodings).

There is sentiment that the IETF should not be in the business of
designing APIs. That said, the spirit of GSS-API, namely the bits about
context setup, IMO is worth codifying. Other protocols making use of GSS
generally concentrate on the use of gss_init_sec_context() and
gss_accept_sec-context() and perhaps they specify service naming, but no
such protocols would be broken if an implementation adds a GSS-API
extension for authz data handling, say (though better signalling of
authentication vs. authorization errors might be appreciated).

> API behaviour for all applications and years to come!

Yes. Well. It seems we have to make some serious trade-offs for that to
work. E.g., authorization data is hard to abstract, as you point out.
And so is credentials handling, and other fun stuff.

Some bits of such an API as GSS will have to be fuzzy in order to be
workable. Does that mean #ifdefs in portable code? Yeah. Can such an API
still help on the portability front? Yes.

> interoperability with its successor (version) or a flag day.

Right, so let's agree that an API such as GSS-API can help portability,
but can't be a complete panacea and let's accept that some mechanism-
and implementation-specific mods are needed.

> The default behaviour *must* be password caching.

You can also just fail when the creds expire.

> by future applications to modify the existing (default) behaviour

I'd kinda prefer not putting a callback into GSS-API and instead put in
links to other APIs (PAM on *nix, GINA on Windows).

> to open a dialog box expecting user input? 

Hopefully it fails.

Nico

---

From: Derek Atkins <[email-masked]>
Date: 19 Feb 2002 10:38:50 -0500

> links to other APIs (PAM on *nix, GINA on Windows).

You've clearly never written any GUI-based applications, have you?

> > to open a dialog box expecting user input? 

But there is no way to may it fail.  In the case of callbacks, the
application that runs in standalone mode can fail to supply a
callback, so when GSSAPI gets to the place where it might need user
input, it sees the lack-of-callback and just fails immediately.

In the case of PAM integrated directly into the GSSAPI, how would it
fail?  Follow the same path -- the GSSAPI gets to the place where it
might need user input, it calls PAM (or worse, GINA), which prompts
the (non-existant) user.  GSSAPI blocks, waiting for input.  Your
application hangs.

In UI design, callbacks are ALWAYS the better approach.  EVERY
UI-based system uses callbacks.  GSSAPI should do the same to
interface into the UI.  The reason: GSSAPI should not make any
assumptions about what is required by the UI (or the application).

> Nico

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Feb 2002 10:49:30 -0500

> You've clearly never written any GUI-based applications, have you?

I don't get this comment. Plenty of GUI apps deal with PAM just fine.
What's the problem?

Note that I didn't say I don't want callbacks at all, just not in
GSS-API :)

> the (non-existant) user.  GSSAPI blocks, waiting for input.  Your

With PAM the app has to provide the conversation callback function for
prompting and presumably the app will know if it has a display or TTY on
which to do the prompting. If the app is running as a daemon and
assuming it was started correctly then it will have neither a TTY nor a
display (X11 or otherwise).

Nico

---

From: Derek Atkins <[email-masked]>
Date: 19 Feb 2002 11:14:09 -0500

> I don't get this comment. Plenty of GUI apps deal with PAM just fine.

The comment was regarding using callbacks in UI-independent libraries
that need UI interaction.

> Note that I didn't say I don't want callbacks at all, just not in

That's not what you said..  See quote above.

Also, you are now adding a dependency of PAM to _ALL_ your
applications, even if they don't want one.  You're now saying that
every single gssapi application needs to initialize PAM before it
calls gssapi?  That seems even more broken then providing a single
gssapi callback:

        int (*gss_new_initial_cred) (void *user_data);

Note that this API probably needs the be expanded a bit, maybe to
include the requested gss name.

> display (X11 or otherwise).

So you want to add this PAM dependency to _ALL_ applications?  That
seems kind of broken (or at least extremely unkind).  It would
certainly break all previous applications that didn't use PAM.

Supplying a GSS callback is more programmer friendly.  The application
can use PAM if it wants to, but GSSAPI should not require it.

-derek

PS: ...

> related financial instruments.

... can you turn this crap off when sending to mailing lists?

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Feb 2002 11:24:10 -0500

> That's not what you said..  See quote above.

That is what I said. Re-read it please: "I'd kinda prefer not putting a
callback into GSS-API and instead put in links to other APIs (PAM on
*nix, GINA on Windows)."

PAM works with GUIs (it has a callback API). So does GINA.

What I meant by "put in links to other APIs", was to have an API to
associate a PAM context with a GSS context so that when creds are needed
the GSS-API can just call PAM with the app-provided context.

> calls gssapi?  That seems even more broken then providing a single

I have some experience with PAM. I think it's very easy to design a
prompter API that is not general enough. I think it's not worth
re-inventing the wheel.

> include the requested gss name.

That's an understatement.

> certainly break all previous applications that didn't use PAM.

It doesn't break them. Currently apps can't get new initiator creds when
they expire, not through the GSS-API anyways.

> can use PAM if it wants to, but GSSAPI should not require it.

Design it right...

> ... can you turn this crap off when sending to mailing lists?

I wish. Some list maintainers have asked me to abstain or use an
off-work mailbox. I can do that, but I can't participate as much that
way.

> -derek

Cheers,

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Feb 2002 17:57:33 +0100 (MET)

> disagree today it's hard to be compliant with both (e.g., name string

WHAT?

I doubt that there is any real incompatibility between RFC2078 and
RFC2743 (RFC2744 is the C-Bindinds document).  RFC2743 is only more
precise and more consistent.

> authentication vs. authorization errors might be appreciated).

This is just out of experience:
- a spec that covers an API is more complex and more prone to discussion
  than a simple on-the-wire spec
- normally the IETF wants to get specs completed within 12-18 months.
  for APIs this has turned out to be close to impossible.
  even for complex on-the-wire protocols (Kerberos, IPsec) this
  turns out to be impossible
- it requires a lot of (and a wide scope of) experience to design
  an abstract API that does not artificially limit the freedom
  of the implementors, and there are very few engineers with
  the necessary background involved in the IETF working groups.

> And so is credentials handling, and other fun stuff.

The GSS-API abstraction of credentials works just fine.

> still help on the portability front? Yes.

Huh?

Truely Portable code means no #ifdefs for any platform and no #ifdefs
for any gssapi mechanism and no app code changes for using new gssapi
mechanisms with already installed apps.

> and implementation-specific mods are needed.

No, in general they aren't.

You're confusing portable applications with formerly native-API
applications that try to minimize migration pains to new releases
by switching to GSS-API where possible and mixing in native-API
where this is not possible.

I have no problem with native APIs of a mechanism accepting
gssapi datatypes, but polluting GSS-API with implementation
specific data types and semantics is not a good idea.

> links to other APIs (PAM on *nix, GINA on Windows).

That's the only possibility to make it work portably with gssapi
and it's also the only possibility to limit the exposure of
longterm credentials to the absolute minimum.

> > to open a dialog box expecting user input? 

No, it stalls forever -- the popup is displayed on a virtual desktop
that is not visible/accessible to the interactive user(s).

no-interactive Win32 services reading STDIN are also stalled forever.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Feb 2002 13:54:31 -0500

> > disagree today it's hard to be compliant with both (e.g., name string

I was referring to minor, yes minor issues like different char sets for
gss names. I thought this had been discussed before.

And we have to keep in mind that Kerberos i18n will require GSS-API i18n
eventually.

> The GSS-API abstraction of credentials works just fine.

Really? Then why is it that the GSS-for-OpenSSH patches have to go to
such troubles to create ccaches?

[...]

> specific data types and semantics is not a good idea.

Why? As long as those implementation specific data types are treated as
opaque pointers and the semantics are simple then it should be
tolerable. I think that's fine for ccache stuff and for authorization
data, ticket extensions, etc... I can't imagine an easy to use generic
C interface to authorization data.

> that is not visible/accessible to the interactive user(s).

Oh, that's too bad.

Cheers,

Nico

---

From: "Jonathan Trostle" <[email-masked]>
Date: Tue, 19 Feb 2002 22:51:51 -0800

----- Original Message -----
From: "Nicolas Williams" <[email-masked]>
To: <[email-masked]>
Cc: "Jonathan Trostle" <[email-masked]>; <[email-masked]>
Sent: Friday, February 15, 2002 10:39 AM
Subject: Re: Kerb WG iakerb

> relied upon to be password-caching. Sigh.

It's not needed for IAKERB. No long term access to the user's password is
needed.

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Feb 2002 13:06:46 +0100 (MET)

> gss names. I thought this had been discussed before.

Huh? There is *no* difference in rfc2078 and rfc2743 in this area.

> And we have to keep in mind that Kerberos i18n will require GSS-API i18n

i18n support requires only some trivial definitions to be added to GSS-API.

There are only very few "printables" in the GSS-API spec anyways:

  (1) names from gss_display_name() and for gss_import_name()
  (2) error messages from gss_display_status()

Printable Names are already tagged with "Nametype OIDs", so defining
additional OIDs for UTF8-encoding should take care of that.

Since gss_display_status() also takes an input parameter "status_type"
to indicate whether to translate a minor or a major status code,
this input parameter could be extended with "major_utf8" and "minor_utf8".

The only remaining problem would be to predetermine whether
gss_display_name() should be required to return the regular plain-ascii
variant for plain-ascii names for updates of a gssapi mechanism that
wants to keep its mechanism OID unchanged.

> such troubles to create ccaches?

create ccaches?  Wait a minute, that sounds like an extremely implementation
specific type of thing.  This smells baaaaad.

I haven't seen what they do, so I can just guess what they're trying
to accomplish:

GSS-API has only very simplistic support for credential delegation,
and maybe they're trying to write a delegated credential out to
a file _above_ the gssapi mechanism level -- which would definitely
be an extremely broken design.

Whether or not a delegated credential should be written out to a
permanent storage so that remains available after the delegated_cred
handle has been passed to gss_release_cred(), and similarily
whether a delegated credential becomes available to other processes
through this is a completely local matter of every individual gssapi
mechanism implementation (both in policy and data format).
Same for the management and cleanup of (delegated) credentials
-- this is explicitly outside of the scope of GSS-API.

Implementation specific means that it doesn't need to be the same
for two independent implementations of the *same* gssapi mechanism,
and as I've said before, you will have serious problems trying to
push MIT-Kerberos internal representations of data into
Microsoft's W2K Kerberos.

> C interface to authorization data.

No, it is not!

Leave the native data at the native API.  Don't pollute the
generic API with lots of native API data that will be very implementation
specific and not be usable by portable applications.

The proposed extensions are being used to feed the implementation specific
data blobs either into native APIs or interpret its contents.
This would be a definite breach of the abstraction model, and therefore
these extensions belong into the native API of the mechanism, not
into the GSS-API part.

You're free to accept gss-api data at the API level because
there shouldn't be any confusion inside the mechanism about its
own gssapi objects, and it will not pollute the gssapi spec.

-Martin

---

From: Von Welch <[email-masked]>
Date: Wed, 20 Feb 2002 12:31:56 -0600

>-- this is explicitly outside of the scope of GSS-API.

I think applications need to be able to control this, or at least know if 
it has or has not been done.

>these extensions belong into the native API of the mechanism, not

The idea of the extensions is not to be specific to our implementation or 
mechanism. The idea is any implementation or mechanism could use this 
function. Some stuff may be mechanism or implementation specific, in which 
case the application needs to know this, like they do today when they play 
with Kerberos or GSI environment variables. One could also define things 
that are common across multiple mechanisms. Not all mechanisms may support 
it, but at least this gives applications a standard way of discovering that.

Von

---

From: Ken Raeburn <[email-masked]>
Date: 20 Feb 2002 21:28:33 -0500

<naive> Huh?  You mean the strings I get aren't already using my
native {UTF-8, iso8859-999, EBCDIC}?  </naive>

> additional OIDs for UTF8-encoding should take care of that.

Eww.  While AFAICT RFC 2743 says nothing about character set encoding,
the C bindings in RFC 2744 (section 3.2.2) do specify ISO Latin 1 for
"certain multiple-word data items" including printable strings.  And
the Java bindings (RFC 2853) use String objects of "two-byte Unicode
characters".

So, where would these new OIDs be specified, and what would be the
effect in the various language bindings?  Would C and Java code get
different name types for names that fit in "two-byte Unicode" but not
in ISO Latin 1?

Seems to me the encoding should maybe have been one of those
implementation-defined details, like which "pointer or arithmetic
type" is used for gss_cred_id_t.  Either one can make it impossible
for independent implementations to work together at the ABI level.
(Though, granted, character set encoding changes can imply more than a
simple recompile, at least in C.)

If we open the door to encoding-specific OIDs, what're the chances
someone will propose a way of importing or exporting UCS-2 or UCS-4
names without UTF-8 conversions?  How many character sets would an
application need to know how to display?

> this input parameter could be extended with "major_utf8" and "minor_utf8".

Would this just be an extension at the C bindings layer?

The GSS-API uses an integer for status_type, and specifies values 1
and 2 for major and minor respectively; the C bindings just indicate
how the integer value is passed in (what type and where in the
argument list).

So the revised i18n C bindings would do what?  Map from a set of
integers (from RFC 2743) and desired encodings to another set of
integers (to use in application C code)?  Add some flags in the high
bits and hope that the generic API is never extended so as to use
those bits?  (And remember, it's an "int" in the C bindings so we can
only assume 16 bits are available in all.)

Or do we extend it at the GSS-API layer?  If so, the extension is
meaningless in a set of language bindings that specifies UTF-8, but
maybe that's okay.  But see above re UCS-2 extensions.

> wants to keep its mechanism OID unchanged.

Also ISO Latin 1 strings that are not plain ASCII.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: 20 Feb 2002 21:30:46 -0500

> -- this is explicitly outside of the scope of GSS-API.

Still needs to be done somehow, somewhere.

How would you suggest we set up something like an ssh server that can
receive credentials and make them available to the login session (or
other random process to which we can't just hand off the GSS context
handle)?  To make it interesting, let's assume for the sake of
argument that it's handling multiple incoming connections, and thus
isn't changing any global state like its uid that the underlying GSS
mechanism can key off of.

We added a routine to our implementation of the krb5 GSS mechanism to
copy out the delegated credentials to a krb5 ccache.  I believe
Heimdal has the same addition; at least, that was the plan when we
discussed it with Assar.  (Would this count as a "native API" by your
definition?  Or would it have to be in the krb5 library instead and
lose the "gss_" name prefix?)

> Microsoft's W2K Kerberos.

Absolutely.

> > > specific data types and semantics is not a good idea.

Doesn't that imply that the "native APIs" might have to know about the
internals of the GSS-API implementation as well as the specific
mechanism(s) it cares about?  If the GSS-API library is a glue layer
that negotiates and dynamically loads "real" mechanisms, might some of
the objects it returns be wrapped versions of mechanism-specific
objects?  Or is it not possible to do such a thing without the
mechanism knowing those details already?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Feb 2002 22:42:52 -0500

> specific type of thing.  This smells baaaaad.

Well, let's see, the only consumers of Kerberos must be GSS apps, right?

No, wrong, and users expect their tickets to be useable, so we need to
be able to interface GSS apps using the Kerberos mech to non-GSS apps
also using Kerberos.

And there may be several ways a user may want to name ccaches.

And some apps may need memory-only ccaches.

And some OSs require specific ccache naming conventions for their secure
filesystem stuff to work (hint, one such vendor's name starts with 'S').

> be an extremely broken design.

No, it's called realpolitik.

> permanent storage so that remains available after the delegated_cred

or not-permanent storage, for that matter. It's not just the type of
storage, but the naming (not just how to specify a ccache name, but how
to determine the name of a ccache so it can be passed to other apps).

> -- this is explicitly outside of the scope of GSS-API.

If it's out of scope then either GSS-API can't cope and its users must
not be able to do useful things with GSS creds OR there must be a mech-
or impl-specific interface. I prefer the latter.

> for two independent implementations of the *same* gssapi mechanism,

Doh.

> Microsoft's W2K Kerberos.

Clearly. I wouldn't want to.

Face it, there are real differences between the various platforms, and
we (the users, developers, sysadmins, implementors) may not want to
settle for the lowest common denominator that can be abstracted 100%
portably. I can deal with a few #ifdefs, clearly so can the MIT folk :)

Look at Simon's GSS-for-OpenSSH patches. Pretty simple. Very clean, not
unduly full of #ifdefs. It would be simpler if there was some interface
between the GSS-API C bindings and specific implementations. Simon's
code manages to work with two mechanisms and three different
implementations (two of the Kerberos mech, one of the GSI mech).

So there's proof that: a) GSS-API is decent and b) GSS-API is not good
enough.

> Leave the native data at the native API.  Don't pollute the

But if you stick to the GSS-API as it stands today it's very hard to
interface correctly with the local native APIs. That's the point, you
have to resort to acrobatics to handle ccache stuff correctly, say. I
can't wait to see a pure abstraction on all the intersting things one
might do with authorization data.

> specific and not be usable by portable applications.

Nah, #ifdefs are terribly useful in writing portable code :) :) :)

Mind you, I'm no fan of C/C++, but we'll have to make do for now.

> these extensions belong into the native API of the mechanism, not

I guess I'm skeptical about the possibility of GSS evolving into a swiss
army knife abstraction layer that can really do everything desired of
it.

Cheers,

Nico

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Feb 2002 21:34:24 +0100 (MET)

I have the impression that quite many people only think of the
most simplistic usage scenario where one single or a fixed set
of predetermined/preknown gssapi mechanism is linked to an
application and the application knows about the exact characteristics
before its being compiled and linked to it.

The "portable" applications that the GSS-API spec specifically
tries to address and support is significantly different.
Portable applications will be faced with arbitrary unknown GSS-API
mechanism implementations at runtime, or even with a set
of several different gssapi mechanisms with differing characteristics,
an in some scenarios the selection of a particular mechanism may
be a result of an SPNEGO negotiation.

In these scenario, a portable application will have to restrict itself
to the well-defined behaviour and characteristics of GSS-API.

> native {UTF-8, iso8859-999, EBCDIC}?  </naive>

Today it is implementation defined what encoding is being used;
rfc 2743/44 talk of "printable octet strings" only.

On ASCII-machines the 7-bit ASCII characters should be safe.
Everything else is implementation defined and may change
with (language) environment/configuration.

On EBCDIC machines this probably is EBCDIC (but since the
ISO Latin1 characters exist in 13 slightly different variants
for individual western european countries you're probably
limited to *LESS* than ASCII 7-bit...)
 
In our application we don't prevent use of 8-bit chars,
but clearly discourage their use.  The customer may try to use
it and it may work...

Unfortunately, in the past few years our codebase was reengineered
to allow the use of Unicode (UCS2 internally).  However this actually
creates a problem for the use of 8-bit chars at the GSS-API because
now we would have to know about the local encoding of 8-bit chars
to be able to show those printable strings to human users or
accept them from users through our own Unicode-enabled UIs...

This is where the "local matter" really hurts and new tags that
indicate UTF8 encoding would *REALLY* help.

> different name types for names that fit in "two-byte Unicode" but not

Additional generic nametypes that indicate UTF8-encoding should
be added to the High-level spec (rfc2743).  It's up to the language
binding to be more precise about the encoding of the existing
generic nametypes.  I think it's perfectly ok for the JAVA bindings to
always use Unicode here.

If the C-Bindings actually mention ISO Latin 1, then this is an
error, probably not backwards compatible with GSS-API v1 C-Bindings
(rfc1509) and a bad idea for the few EBCDIC-dinosaurs that are
still around.  Implementations have been very liberal in defining
the "local character set".  I've met two different gssapi mechanisms
that were returning Japanese multibyte text from gss_display_status()
and I think that is ok.

> simple recompile, at least in C.)

Well, that is impossible.

In those few places where gssapi has "printable octet strings",
these are meant to be treated and processed as strings, i.e.
read from configuration files, written to logs,
presented to users thru UIs or passed along from user input.

We need to be explicit about the encoding or portable applications
must limit themselves to the small safe subset of 7-bit ASCII chars
(or some chars less on EBCDIC).

> application need to know how to display?

Huh -- Where do you see a problem?

There is no limit on mechanims-specific and implementation-specific
nametypes in GSS-API, and most gssapi mechanisms offer several
implementation specific nametypes today.

Acutally, every gssapi mechanism will require
a private, non-generic, well-specified nametype.  The Kerberos 5
gssapi mechanism (rfc1964) specifies such a mechanism-specific
nametype, the Kerberos principal name.  SPKM (rfc2025) lacks
that nametype, that's why all independent implementations of
SPKM1 mechanisms fail to interoperate on printable names...
Although I complained loudly, LIPkey was published with
the same flaw (lack of a well-defined mechanism specific nametype).

> how the integer value is passed in (what type and where in the

I would add it to both, High-level and C-Bindings as a
"v2 mechanism SHOULD implement", i.e. major_utf8 = 3, minor_utf8
and allow the language binding to omit the *_utf8 variants when
it already uses Unicode characters by default (e.g. the JAVA bindings). 

> only assume 16 bits are available in all.)

The generic layer doesn't use bits!
It's just a simple integer value, more like an enum

> Also ISO Latin 1 strings that are not plain ASCII.

That is one of the problems.  But changing the behaviour of a
gssapi mechanism that is already deployed would cause interoperability
problems if suddenly the semantics of gss_display_name() change
with a newer version.

In order to provide the most backwards compatibility we will probably
need a seperate call "gss_display_name_utf8()", which might not be
needed for the language (bindings) such as JAVA.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: 21 Feb 2002 21:00:09 -0500

> before its being compiled and linked to it.

Not at all.  I try to think in terms of a GSS-API implementation that
consists of a config file parser and a dynamic loader, with the rest
up to the whim of the system administrator.  However, the
Kerberos-only scenario is the only one I have any practical experience
with, so it's hard for me to escape that box enough to see what
assumptions I'm making that don't apply elsewhere.

If you have a pointer to any *good* documentation on GSS-API, better
than the RFCs, I'd like to see it.

> that were returning Japanese multibyte text from gss_display_status()

RFC 2744, section 3.2.2.  Actually, it says some items "may be
regarded as simple ISO Latin-1 character strings"; how much "may be
regarded as" affects actual coding requirements, I can't say.

If it's an error, perhaps an update should be issued.  But what should
it say instead?  "Local character set"?  "Implementation-defined"?

> Huh -- Where do you see a problem?

We also have some mechanism-specific name types.  The problem I see is
they're (somewhat?) independent axes; we could easily get a request
for an OID for a Kerberos principal name using EBCDIC encoding.  Which
names in this multidimensional matrix should be considered "portable
across GSS-API version A.B implementations", or "portable across
implementations of mechanism X", or "portable across implementations
on operating system Y", or whatever other classifications you might
want?

> nametypes in GSS-API,

And the use of either makes an application less portable in one way or
the other.

> it already uses Unicode characters by default (e.g. the JAVA bindings). 

I'm still a newbie to the whole Unicode/UCS/UTF situation (again,
mostly 'cause I never use any of it in real life), but my impression
is that Java uses UCS-2, and that covers just 16 bits worth, whereas
Unicode is much bigger.  A UTF-16 encoding has been put forth that can
encode code points from 16 more planes in two UTF-16 "characters"
(i.e., 20 bits from four bytes), but you'd still have to know to do
the conversion.  So the Java bindings might want major_utf16 and
minor_utf16, whereas they'd probably be uninteresting under the C
bindings unless you have 16-bit chars, or rewrite the API to use
wchar_t, and even then only if wchar_t is 16 bits and not 32, which
gets us back to implementation-specific options.

Of course, I may be completely wrong.  My experience with Java and
Unicode is about as limited as my experience with non-Kerberos
GSS-API.

Ken