Subject: Can Authorization Data be retrieved through GSSAPI?

From: Joncheng Kuo <[email-masked]>
Date: Fri, 15 Feb 2002 17:48:52 -0500

Hi,

I'm new to this mail list.

A basic format of Authorization Data has been added to the revision of 
the draft Kerberos standard. Is there any way that this Authorization 
Data can be exposed through GSSAPI? If not, is there any move to make an 
  extension on GSSAPI?

Joncheng Kuo

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 16 Feb 2002 17:04:52 -0500

Authz data was always in RFC1510. And no, the GSS-API C Bindings do not
provide an API for getting at the authz data. But GSS is not merely
about the specific bindings. GSS could probably use some revisions.

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: Sam Hartman <[email-masked]>
Date: 18 Feb 2002 09:08:02 -0500

>>>>> "Joncheng" == Joncheng Kuo <[email-masked]> writes:

    Joncheng> Hi, I'm new to this mail list.

    Joncheng> A basic format of Authorization Data has been added to
    Joncheng> the revision of the draft Kerberos standard. Is there
    Joncheng> any way that this Authorization Data can be exposed
    Joncheng> through GSSAPI? If not, is there any move to make an
    Joncheng> extension on GSSAPI?

It is not currently possible to get this data through GSSAPI.  There
an effort to add this to GSSAPI.  However as time progresses it is
becoming more clear that there are significant mismatches between
GSSAPI's idea of the universe and Kerberos's idea of the universe.
It's also becoming clear that various GSSAPI concepts (particularly
naming or credentials depending on how you look at it) are
insufficient for certain real-world deployments.

I expect that a lot of us who have worked on Kerberos will be pushing
toreactivate the CAT working group and discuss these issues once we
are done with revisions.

You could of course ask implementers to agree on an API for exposing
the autherization data as an extension to GSSAPI.

---

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

> the autherization data as an extension to GSSAPI.

In the past there have been at least two proposals for providing
such authorization information in a GENERIC fashion via an
*optional* extension to GSS-API, one from the SESAME project
(a european project by several eurpoean companies and at least
 one university) and one called GAA from people around Cliffort Neuman.

Besides the generic approaches there are always the product specific
means to do it (DCE should have such a capability).

The main reason why this hasn't catched any significant momentum is
that in the lack of people who are going to use it with at least 2
(preferably more) entirely different authentication schemes and
user management models it is unlikely that someone will come up
with a true *generic* model.

It might have been for the existence of DEC DASS that DEC came up with
a GSS-API proposal that was actually generic enough to support authentication
schemes beyond Kerberos.  The majority of engineers is heavily entangled
with a single authentication scheme and almost always grasps the
abstraction model of the GSS-API in a painful cent-by-cent fashion.

Now what you have today is quite a lot of authentication schemes
that don't offer any authorization data, and a few scheme that
offer some very product/scheme-specific authentication data
(product specific or even proprietary data formats for that data).

What should a "portable" application do these days?  If the
application should work portably across all available mechanisms,
it will have to define and manage its own authorization data
for all mechanisms (and users) that don't provide such data.

Trying to mix and match the authorization information from completely
different mechanisms plus providing a pure-application-based authorization
scheme for the majority of GSS-API mechanism without authorization data
might prove to be a difficult problem.

Being faced with a complex (legacy) application one might realize
that some of the existing authorization schemes are unable to
represent the existing authorization granularity...

In the end you realize that often it is the most portable (across
arbitrary gssapi mechanisms) and backward compatible (across
the installed base of an application) solution to not use
any external authorization data even for gssapi mechanisms
that support (some limited) form of authorization data.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: 18 Feb 2002 10:31:18 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> In the end you realize that often it is the most portable
    Martin> (across arbitrary gssapi mechanisms) and backward
    Martin> compatible (across the installed base of an application)
    Martin> solution to not use any external authorization data even
    Martin> for gssapi mechanisms that support (some limited) form of
    Martin> authorization data.

Sure, but there are many reasons for using GSSAPI.  I've seen a lot of
applications start using GSSAPI lately, very aware that they will have
to add mechanism-specific knowledge for every GSSAPI mechanism they
support.  They end up choosing GSSAPI either because they believe that
even given this requirement, adding new mechanisms will be easier.
Others choose GSSAPI because they want to use Kerberos and want to
work on Windows/Solaris.  Others choose GSSAPI because they want SASL.

So, while the portable decision may be to do application-specific
authorization, many application authors are finding that decision does
not satisfy their  users.

The criticality of Kerberos authorization data is also going to be
very annoying for GSSAPI.  In order to actually get authorization data
to be critical, we as implementers are going to have to make sure that
gss_accept_sec_context fails if the authorization data has not been
understood by the library or application by the end of the call.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 18 Feb 2002 13:14:11 -0600

> about the specific bindings. GSS could probably use some revisions.

You may wish to look at this document, which has some revisions to GSS-API.

http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf

It defines a gss_inquire_context_by_oid to allow access to additional mech specifiy
information. The authz data could be one of these. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Sam Hartman <[email-masked]>
Date: 18 Feb 2002 14:22:32 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> It defines a gss_inquire_context_by_oid to allow access
    Douglas> to additional mech specifiy information. The authz data
    Douglas> could be one of these.

Why is this work going on in terms of Grid Form rather than IETF.  I
thought they implied they wanted to work with us at a recent meeting.
I'd think part of that would be submitting extensions to IETF
standards to the IETF especially when such extensions were not
specific to their needs.

---

From: Matt Crawford <[email-masked]>
Date: Mon, 18 Feb 2002 14:01:35 -0600

> Why is this work going on in terms of Grid Form rather than IETF?

Let's explain by indirection: the GGF is meeting right now, and their
network is NATted.

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Feb 2002 12:23:51 +0100 (MET)

This is more a CAT than a KRB comment...

Douglas E. Engert wrote:
> It defines a gss_inquire_context_by_oid to allow access to additional
> mech specifiy information. The authz data could be one of these. 

I just finished reading the suggested document and I'm not very
happy about it.  The document describes very implementation specific
extensions of the native APIs of the authentication mechanisms
implemented by GSI.  I strongly suggest that the naming and
description to be changed so it looks less deceiving about
its level of abstraction.

These native calls are modeled so that they can re-use data types
of the GSS-API and convert between native and GSS-API-style objects.

Unfortunately the document creates the expression that it describes
an actual abstraction and extension to GSS-API, while it acutally is
a very implementation specific extension of a particular mechanism
*implementation*.

Normally, the IETF only standarized on-the-wire protocols, and even
there arises confusion and interoperability problems quite often.

GSS-API was unusual for the IETF in that it not only defines
the on-the-wire format, but also an API with a limited set of
abstract datatypes and detailed but abstract semantics of the
API calls so that ultimately portable applications could be
plug'n'play with arbitrary gssapi mechanisms.

The IETF-defined GSS-API strictly *avoids* to mandate implementation
details for gssapi mechanisms (beyond on-the-wire framing and the
abstract semantics required by the API), and in particular on the
native APIs of the mechanisms and their data types.

In fact, if you compare Microsoft's W2K Kerberos and MIT Kerberos,
in particular their "(officially) exposed APIs", you will notice
that they differ considerably.  Microsoft primarily implemented
on-the-wire interoperability.  However, since GSS-API doesn't
mandate implementation details, this shouldn't be a problem.
To accomodate for the lack of a real GSS-API, I wrote a wrapper
DLL that offers true GSS-API data-types and semantics on top
of Microsoft's SSPI and it's quite usable.  Portable applications
shouldn't notice a difference between Kerberos implementations
from MIT or Cybersafe and Microsoft's W2K Kerberos underneath
my wrapper DLL.

The GSI proposal for GSS-API "extensions" require quite a lot of
interoperability on very implementation specific aspects of the
particular gssapi implementation, and these extensions will *NOT*
fit underneath SPNEGO (not that I personally like SPNEGO, but
if an extension doesn't fit underneath, then it probably breaks the
abstraction model of GSS-API).

One of the more interesting aspects of the document:
(1) It tries to offer a policy selection on whether or not context
    expiration should be enforced.
(2) It tries to offer a policy to reliably disable all encryption.

(1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is the only
    gssapi mechanism that I've seen that mandates context expiration.
    Curiously, this is a part where Microsoft's implementation doesn't
    comply with the spec.  My wrapper DLL tries to workaround that
    deficiency and enforce context expiration, though.

    How can a gssapi mechanism "enforce" context expiration at all?
    For an application that doesn't use message protection after
    initial context establishment there's nothing a gss-api mechanism
    can do to stop it.  :)
    The only means for a gssapi mechanism to indicate that a context
    has expired is to fail any of the remaining calls that an application
    will use once the security context has been successfully established.
    These are the message protection/unprotection calls and optionally
    the context_export/import calls.

    How difficult is it for a long-running application to deal gracefully
    with context expiration?  Somewhere from hard to extremely difficult.
    An application will have to perform another context establishment
    token exchange to create a new security context.  The real problem
    comes from context expiration while protected messages are "in transit",
    be it on the wire, in network buffers or message queue(s).
    Although context expiration is a good idea from the security
    point of view, it is a major PITA for application protocol design
    and may simply not fit under many of the existing multi-layer
    application protocol stacks.

(2) The purpose of such a policy _really_ puzzles me.
    Confidentiality during message protection is only applied when
    the application asks for it when calling gss_wrap().
    Since (a) setting a no-encryption policy and (b) calling
    gss_wrap() with conf_req==FALSE is both a volutary decision of
    the application, why should we need an extension to implement (a)
    when (b) is readily available in the base spec and working just fine?

    A while ago I met a gssapi mechanism implementor that tried to
    enforce the opposite policy (i.e. always encrypt) within the
    gssapi for certain users and I just laughed at him.
    He tried to do so by always applying encryption when an application
    called gss_wrap(), independent of the conf_request flag.
    Well, our application uses gss_getmic() when configured for
    integrity-only protection, and it can also be configured to
    run with no message-protection at all, so the gssapi mechanism
    is unable to override the application's configuration.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: 19 Feb 2002 09:02:56 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> (1) So far the Kerberos 5 GSS-API mechanism (rfc1964) is
    Martin> the only gssapi mechanism that I've seen that mandates
    Martin> context expiration.  Curiously, this is a part where
    Martin> Microsoft's implementation doesn't comply with the spec.
    Martin> My wrapper DLL tries to workaround that deficiency and
    Martin> enforce context expiration, though.

How would you feel about dropping this when we next revisit RFC 1964
to add AES support?

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Feb 2002 15:41:43 +0100 (MET)

> How would you feel about dropping this when we next revisit RFC 1964
 
Please leave it as it is.

Jeff Schiller as the Security Area Director required the context
expiration for RFC-1964.  The reasoning was that no encryption
key should be permitted to live forever.  The same reasoning
was applied to SSL and to IPSEC, and I think its just as valid
today.  The discussion details is somewhere in the CAT archives,
I could dig it up if you're interested.

It takes some extra efforts at the application protocol levels 
to accomodate for expiring security context (something which
Microsoft probably chose not to do after the W2K beta2 failed
badly with enforced context expiration...)

I have added provisions to our application protocols to perform
a context renegotiation, but it is not perfect or fail-safe,
and it probably has a rough edge that I should improve one
of these days...  But basically, it works.

For asynchronus application communication, the extra negotiation causes
some extra complexity.  For synchronus app communication (blocking
threads) there is little extra complexity but additional stalls
for which it might be difficult to define timeouts (but the timeout
problems for SSL communication is also an unsolved question already).

-Martin

---

From: Von Welch <[email-masked]>
Date: Tue, 19 Feb 2002 09:21:31 -0600

Martin, Sam-

First, to respond to Sam's earlier question as to why this document is in 
GGF instead of IETF - We are indeed interested in putting this document 
through the IETF (which is why we have it in ID draft format instead of GGF 
format). Yes, we see it going in the CAT working group. About a year ago we 
approached John Lynn with the idea and got a cold response. Given that we 
knew the document was still serious evolving we held off. If however we 
could get interest from Kerberos community as well, we would certainly jump 
back into the IETF community with this.

Martin - in reponse to your comments, I would much rather address your 
issues of this being mechanism specific than say this is mechanism 
specific. We (the authors) have a fair amount of Kerberos experience 
between us and we've tried very hard to at least keep that mechanism in 
mind when laying out this document since working over it is also serious 
interest to our project. Could give some specific examples of what you 
think are mechanism-specific attributes?

In response to your specific comments, our attempt to standardize behavior 
on context expiration is just an attempt to standardize the behavior of the 
wrap/unwrap calls when context expires and to give the application a way to 
control this. The idea being that some sites might want to know when the 
context expires, but finish some action (e.g. a file transfer in progress) 
before disallowing further activity.

The idea behind disabling of encryption is that this allows an application 
to disable encryption for some policy reason, even if the mechanism 
supports it. By doing so before context setup, this allows the client to 
gracefully know this before a wrap call fails. Honestly, we threw this in 
as a "seems like a good idea".

Von

---

From: Sam Hartman <[email-masked]>
Date: 19 Feb 2002 10:36:16 -0500

>>  How would you feel about dropping this when we next revisit
    >> RFC 1964 to add AES support?
 
    Martin> Please leave it as it is.

I'm sort of disinclined to do this, or at least am uncomfortable with
expiration as short-lived as Kerberos tickets.  This is particularly
true since the native Kerberos protocol does not have this limit with
the krb_priv or krb_safe messages.

I'll be sure to talk to Jeff before proposing any change.

As you point out this creates significant problems for application
protocols.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 19 Feb 2002 09:50:12 -0600

> standards to the IETF especially when such extensions were not

In regards to:

We are working with the IETF. 

In Minneapolis last year we discussed this with the CAT WG chair to 
try and get the CAT group interested, but there has not been any CAT 
group meetings since. We would still like to get the CAT group involved. 

The GGF security work: http://www.gridforum.org/2_SEC/GSI.htm
is based on the Globus Project(tm) http://www.globus.org
security component, GSI, which implements a GSS-API over the SSL/TLS 
protocol with X509 certificates with mutual authentication and delegation.
We found that there where a number of missing features from the GSS-API 
specification which we needed in order to avoid calling the GSI directly,
thus subverting the concepts of a GSS. 

There are additional security drafts from the GGF which are also in the
IETF, in particular, "Internet X.509 Public Key Infrastructure Proxy 
Certificate Profile" 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-01.txt
This formalizes the certificates which are used for delegation with the 
GSS-API. This has received a lot of attention, and we has presented this
at least twice. 

We have  submitted to the TLS group some extensions to TLS to 
allow an additional message type for delegation. I gave a 5 minute
presentation in London on this.  

We have not pushed any of these concepts via the KRB-WG. As you know,
the members of the group are very busy with "Clarifications" and 
"Extensions". But we would like to see these same extensions work with 
Kerberos too. 

We have also been active in the SECSH group making sure GSSAPI was added
so we could use the GSI with SSH via GSSAPI. 

I believe we have, in some way, presented every part of the GGF 
security work at the IETF. This work, http://www.gridforum.org/2_SEC/GSI.htm 
is based on the Globus Project(tm)  http://www.globus.org 
security component, GSI, which implements a GSS-API over the SSL/TLS 
protocol with X509 certificates with mutual authentication and delegation.

So I would say that the GGF has been working with the IETF, but sometimes
it is hard to get the IETF members to listen. 

--

---

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

> before disallowing further activity.

As long as the app can reset the option so that the wrap functions are
re-anabled after context expiration for the purpose of completing
operations in-progress.

> as a "seems like a good idea".

Sounds like GSS-level negotiation of app-level issues. It would need
changes to the existing mechs to be useful. Whereas a generic feature
negotiation framework might be useful (particularly if it can work with
optimistic mech negotiation and one-round-trip mechs), this seems like
too specific a feature.

> Von

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 19 Feb 2002 11:03:08 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> I'm sort of disinclined to do this, or at least am
    Sam> uncomfortable with expiration as short-lived as Kerberos
    Sam> tickets.  This is particularly true since the native Kerberos
    Sam> protocol does not have this limit with the krb_priv or
    Sam> krb_safe messages.

To clarify, I don't tmhink I could follow the spec if I were trying to
sell Kerberos.  MIT can get away with following the spec because we
can more effectively use security arguments to explain why we aren't
meeting customer needs than we could if we were getting money from
customers.

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Feb 2002 18:52:34 +0100 (MET)

> think are mechanism-specific attributes?

I meant to imply that your proposed extensions are *implementation*
specific, which is actually worse that being mechanism-specific.

When I wrote my wrapper DLL for Microsoft's W2K Kerberos SSP I would
have gladly added support for MIT Kerberos keytab -- if there was
just an API that allowed me to stuff such credentials into
W2K Kerberos -- however there isn't.

Some of descriptions in the purpose of the calls confuse me,
like the purpose of gss_export_cred()/gss_import_cred().
Although the description makes it sound like a gssapi based
app would have some need to export and re-import credentials,
this concept is actually totally alien to portable applications
and places significant implementation constraints on the
nature of credentials.

As it is designed, individual credentials are distinguished
by (a) the identity they're able to authenticate and
optionally (b) the gssapi mechanism (OID) for which they
are usable.  With the regular GSS-API v2 functionality
a portable application can already manage _and_ use an
arbitrary number of credentials today.

The proposed change for gss_init_sec_context()/gss_accept_sec_context()
to accept an initial non-NULL context handle prefilled with policy
options would be a significant backwards-incompatible change to
the existing GSS-API (and always require significant app code
changes to use those features).  For the initiator side you
could alternatively try to use context-options to indicate
your additional desires, which then would be safely ignored
by mechanisms that don't implement it and which would
would not confuse an existing SPNEGO in between.

On the acceptor side I would rather prefer an alternative
gss_accept_sec_context_2() that takes context options as an
additional input parameter.  The original designers probably
thought that it would be ok if the acceptor just participated
the full handshake and decided after security context establishment
whether the result complies with its policy...

> before disallowing further activity.

My preferred approach would be to create additional informatory major_status
return codes that would be pair-able with either GSS_S_FAILURE or
GSS_S_COMPLETE in order to indicate whether there is an
advisory or enforced context expiration on the message protection calls,
similar to the change that I requested for the message sequencing errors
-- just that the sequencing errors were informatory from the beginning
and the context expiration has always been a fatal error code.

(side note: when a gssapi mechanism actually wants to implement
 advisory sequencing errors instead of fatal sequencing errors,
 then it is quite difficult to decide when to stop returning
 sequencing-related informatory status bits after a sequencing error ...)

> as a "seems like a good idea".

Huh? before a wrap call fails?
I don't understand, what is that supposed to mean?

gss_wrap() will not fail when encryption is requested but not available,
it must succeed and return conf_flag==FALSE as long as integrity
is available on the security context.

getmic()/verifymic() as well as wrap()/unwrap() will work as
long as context establishment returns the context flag for
availability of integrity protection (GSS_C_INTEG_FLAG?).

-Martin

---

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

Sam Hartman wrote:
> 
> To clarify, I don't think I could follow the spec if I were trying to

To clarify my standpoint:
Although I know it is difficult to deal with it at the application level
(and I tried to explain why), I still think the requirement is ok
and should be kept.

We sold/shipped our application to MIT in 1996 and of course,
they're using their own Kerberos as their gssapi mechanism and
it enforces context expiration, so I had to deal with it at
the application level. :)

The current code is not perfect and I should improve one rough
edge one of these days, but it seems to be working.  At least
I haven't received any complaints so far (once the discovered
how it works and that they need to refresh their tickets
before they expire in order to make the automatic refresh work.

I'm sure, if you allow application designers/implementors to
effectively ignore context expiration, almost every implementor
an in particular all commercial vendors will *not* implement provisions
for a context renegotiation to refresh the session key, resulting
in exactly those long-lived session keys that Jeff wants to prevent.

And for multi-threaded synchronus applications the additional
complexity in implementing context refresh is comparatively small
(when compared to the necessary complexity for asynchronus
 non-blocking applications).  Our application is asynchronous
non-blocking and I know it is doable.

-Martin

---

From: Von Welch <[email-masked]>
Date: Wed, 20 Feb 2002 10:24:24 -0600

Let me give a little background on our changes. We, the Globus Project, 
have been successfully using GSSAPI over SSL in something we call the Grid 
Security Infrastructure (GSI) for a number of years now. We chose to use 
the GSSAPI because we knew we would have users that would want to use 
Kerberos instead of PKI and it has been very successful for us - our code 
can be linked with either GSSAPI/kerberos or GSI with relatively little work.

  In doing this we have noticed a couple of things. First, a number of 
things, especially credential management happen day behind the scenes are 
are controlled with mechanism-specific magic (e.g. environment variables) 
that applications need to be aware of. Second, we are just reaching limits 
for what we need to do to deploy more advanced security systems. Instead of 
throwing out the GSSAPI or adding to it in a non-GSSAPI manner we are 
attempting these extensions.

  In summary our extensions do the following:

   * Attempt to provide more portable methods to handle things that are 
currently handled today by mechanism-specific magic (e.g. environment 
variables).

  * Separate delegation from authentication and allow an application to put 
policy (be in some independent, mechanism-specific or application-specific) 
into delegated credentials.

  * Allow for the fact there are things beyond identity and lifetime in a 
credential that are interesting for authorization.

  * Allow for a method to set options on a GSSAPI context.

A couple of our functions use the notion of an oid and a blob of data, 
where the oid specifies what the blob of data is. This is akin to the 
get/setsockopt() function calls. The oid can be mechanism specific, in 
which case the application better know it is running over a particular 
mechanism (like it does today if it plays with environment variables), or 
it can be mechanism independent.

Some specific comments are below.

>specific, which is actually worse that being mechanism-specific.

An example would still be appreciated to make sure I understand your statement.

>and places significant implementation constraints on the

If a GSSAPI-based server, e.g. sshd, accepts a delegated credential and 
wants to make it available to a spawned process today how does it do this 
in a portable way? Today credential storage isn't defined, the application 
just has to assume that it happens and then use knowledge of 
mechanism-specific environment variables to make it happen. With 
export_cred() an application can do this explicitly and if the mechanism 
doesn't support it, it learns that in which case it has a problem the user 
probably wants to know about.

>whether the result complies with its policy...

That certainly sounds like a reasonable suggestion.

>and the context expiration has always been a fatal error code.

Again, a reasonable suggestion.

>I don't understand, what is that supposed to mean?

Currently an acceptor has no way to tell the GSSAPI library it doesn't want 
to allow confidentiality, it's totally up to the mechanism. All it can do 
is signal an application-level error if encrypted data arrives. The idea 
here is this allows the acceptor to disable this at context establishment. 
The mechanism may just record this state or it may actually change it's 
protocol.

Von

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 20 Feb 2002 19:39:11 -0500 (EST)

> specific, which is actually worse that being mechanism-specific.

Um.  You do realize that RFC2744 and RFC2853 define standardized C and
Java language bindings for GSS-API, right?  The MIT Kerberos distribution
includes a GSS-API library which implements RFC2744.  The Microsoft SSPI
does _not_ implement RFC2744, though it does produce messages which are
wire-compatible with those defined in the GSSAPI.

IMHO, RFC2744, RFC2853, and their predecessors were a mistake.  The term
"GSSAPI" is a misnomer; GSSAPI isn't an API at all; it is a protocol
building block which defines some protocol elements and an abstract
functional description of how application protocols and authentication
mechanisms work together.  That's good.

RFC2744 and RFC2853, however, _are_ API's.  In particular, they are C and
Java API's which are intended to be implemented by someone providing a
GSSAPI mechanism (or multi-mechanism switch), and called by code
implementing a GSSAPI-using application protocol.  IMNSHO, the IETF should
not be in the business of defining such API's.  Not only is it completely
out of scope, but we're also lousy at it.

I'd very much like to see GSSAPI extended to handle authorization data and
actually try to address the naming problems in a reasonable way.  This is
pretty hairy work that should properly be done in CAT, which has been
dormant for some time now.  A few of us would like to "wake up" the CAT
group and start doing some work on GSSAPI, but really don't have time to
start such an effort until kerberos-revisions is finished.

-- Jeff