Subject: [kitten] Simplified/minimized GSS-API profiles

From: Nico Williams <[email-masked]>
Date: Sun, 15 Jul 2012 01:16:05 -0500

I keep running into this "the GSS-API is enormous, enormously complex,
forget it" attitude.  So I've written an I-D that I hope will help
with this.  It's too late for the -00 cut-off.  Here's a non-submitted
I-D:

https://raw.github.com/nicowilliams/httpbisIDs/master/gss-profiles.txt

Other renderings are available at:

https://github.com/nicowilliams/httpbisIDs

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Jul 2012 14:18:05 -0700

I really appreciate that you're trying, but this document seems like 
something designed to appeal to people interested in security concepts and 
philosophy. Some application developers are not interested. Security is 
sometimes viewed by newer application developers as an annoyance that makes 
it more difficult to accomplish useful goals. For experienced application 
developers, security is often viewed as a risky area where the best 
approach is to write the absolute minimum amount of code necessary to 
accomplish specific customer requirements and to be wary both of 
third-party security libraries and of the risk integrating such libraries 
creates as these have been frequent sources of major vulnerabilities in 
real-world software. I put myself in the latter camp.

Anyway, if you want to make GSS-API appealing to application developers, 
I'd suggest starting with a focus on two things:

1. How to get the client authenticated to the server using traditional 
username.
2. How to exchange the messages over protocol between the client and server 
to accomplish 1.

SASL has seen partial success in deployment when it has successfully made 
the case that it solves these two problems with less effort than a 
roll-your-own approach.

GSS-API has utility to the extent it is makes the code simpler when solving 
these two problems and responding to real-world customer requests, such as: 
Kerberos authentication (this request comes from Universities or sites 
running Windows Domain Controllers) and TLS client certificate 
authentication.

Then perhaps discuss how things like SCRAM and channel bindings available 
through GSS-API might be a competitive advantage, or help customers/sites 
get a bit ahead of the curve on security.

		- Chris

--On July 15, 2012 1:16:05 -0500 Nico Williams <[email-masked]> 
wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Jul 2012 16:35:27 -0500

On Mon, Jul 16, 2012 at 4:18 PM, Chris Newman <[email-masked]> wrote:
> [...]

Whenever one of us usual suspects says "GSS" several people start
complaining about complexity.  But the GSS-API is NOT complex.  It is
NOT something that an application developer MUST use.

The main purpose of the GSS-API for me is to provide a degree of
formalism in application protocols.  It's like the syntax used in TLS
for its messages, or ASN.1 (the notation), or XDR syntax, or ABNF,
or...  That's all.  That's all I want anyone to use it for.

Whether anyone uses the GSS-API for implementations, I don't actually
care.  GSS-API, SSPI, home-brew wire-compatible equivalents (e.g.,
like Samba) -- doesn't matter to me.

Now, this particular I-D is intended to show how simple the GSS-API
can be for any use of it, whether specification or implementation, by
showing that for most use cases a tiny subset of the API is
sufficient.  In particular this I-D is targeting some misplaced
criticisms uttered on the HTTPbis WG mailing list regarding my
"REST-GSS" proposal for HTTP/2.0 authentication.  (Actually, REST-GSS
uses SASL/GS2, so it should really be called REST-SASL.  It's just a
RESTful approach to multi-legged authentication message key exchanges,
and by using POST it also results in a session URI which can be
DELETEd to logout.  It has a number of advantages over all other HTTP
auth proposals.)

I'm starting to think that we need different names for different
aspects of the API.  In particular the *abstract* API (RFC2743) needs
to be named something that doesn't have "API" in the name, or even
"GSS".  It's not an API in the strictest sense, it's a) a language for
specifying how applications use GSS, b) a pattern for actual
programming language bindings of it.

> Anyway, if you want to make GSS-API appealing to application developers, I'd
> suggest starting with a focus on two things:
>

So, this is part of that.  I intend to add another I-D describing how
to use the API.  The only reason I'd do this in another I-D is that
having too much content in one I-D is going to make it large and,
evidently, scary.

> 2. How to exchange the messages over protocol between the client and server

Yes.

> the case that it solves these two problems with less effort than a

Right.

Thanks for your feedback.  While you're thinking about this, can you
think of how better to separate the abstract and concrete uses of the
GSS-API?   I think that's where we could do the most to promote the
use of it...  (And no, promoting its use is not a fetish, but a code
and specification re-use matter.)

Nico
--

---

From: Nathan <[email-masked]>
Date: Tue, 17 Jul 2012 01:05:47 +0100

> NOT something that an application developer MUST use.

If it helps any, I'm a fairly competent web developer, I've read 
gss-profiles.txt (didn't sink in, sorry) and then read the REST-GSS ID, 
which I'm glad to say did make far more sense.

However, I don't "get it" - it appears to be a way to store encrypted or 
verifiable session state on a remote server using verious cryptographic 
methods and tied to various apis (like gss). So it leads me to a few 
questions:

a) why would I want a session with a stateless protocol like HTTP?

b) if I did want a session, why would I want it's state to be stored on 
a third, web accessible, resource?
.. using a custom message structure which isn't a well known media type?
.. dependent on knowledge of several other specifications?

c) what advantage does any of this give over say a simple client side 
certificate containing a unique user identifier?

(c) is perhaps the most important of my questions, if I'm missing 
something I'm keen to learn - as currently I've just got a big "but 
why?" when I think about these IDs I've just read.

TIA,

Nathan

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Jul 2012 19:25:28 -0500

> which I'm glad to say did make far more sense.

Great.

> methods and tied to various apis (like gss). So it leads me to a few

Every cryptographic authentication protocol ever devised involves some
exchange of authentication messages.  GSS, SASL, EAP, SSHv2, IKEv*,
TLS -- all of these have a such a thing.

GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract
API to just that exchange of authentication messages.

Typically one outcome of authentication is session keys (because
authentication and key exchange generally go together).  The
interfaces to shared session keys are:

 -  the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and VerifyMIC)
 - GSS_Pesudo_random() (for generating sub-session key material for
application purposes)

Another typical outcome of authentication is a name of the peer, which
is typically then used for authorization.  The interfaces to this are:

 - GSS_Display_name()
 - GSS_Display_name_ext()
 - GSS_Export_name()
 - GSS_Inquire_name()
 - GSS_Get_name_attribute()

> a) why would I want a session with a stateless protocol like HTTP?

Because HTTP is stateless, but the application protocol rarely ever is.

Cookies exist precisely to bind multiple requests (and corresponding
responses) into one session.

> b) if I did want a session, why would I want it's state to be stored on a
> third, web accessible, resource?

Session keys are shared by the two end-points of the session -- by
definition.  The resource itself would not be accessible to third
parties: the server would only allow the client that owns the session
(i.e., that knows its URI and is using MIC tokens, if that option is
enabled) to GET or DELETE it.

> .. using a custom message structure which isn't a well known media type?

There's really not much to this resource.  If we must we can add a
media type for it.

> .. dependent on knowledge of several other specifications?

Surely we want to re-use existing authentication specifications.
There's a number of reasons for this.  If one has deployed Kerberos,
say, surely one does not want to abandon that investment just so that
HTTP can have an authentication scheme that... does not reuse other
specifications.

:)

> certificate containing a unique user identifier?

Not everyone can carry private keys around.  Even if everyone has
smartphones, tablets, ... with them, there are times when the only way
to recover from some disaster is via a password.  "Ooops, my phone
fell in the toilet, now I have no credentials."

But also, user certificates have not see wide deployment.  The Mozilla
browserid concept is basically to authenticate traditionally then
download your private keys so you can use user certificates, and even
that hasn't taken off.

I propose that we need pluggable authentication precisely so that
people can re-use the credentials infrastructures that they already
have.  Deploying a new credentials infrastructure is essentially
duplicating effort, at least for the long period of migration that
must follow it.

> (c) is perhaps the most important of my questions, if I'm missing something
> I'm keen to learn - as currently I've just got a big "but why?" when I think
> about these IDs I've just read.

RESTful authentication gives you:

 - a way to initiate authentication w/o revealing what resource you're
interested in before you finish authenticating the service

 - sessions using something better than cookies (and with an option
for replay protection)

 - logout!

 - universally implementable HTTP authentication even when the
mechanism selected requires multiple round trips

   This works with HTTP/1.0, 1.1, and almost certainly with whatever
the final 2.0 will look like.  It can be implemented with FCGI on well
over 95% of web servers.  It can be implemented on all client HTTP
stacks.  It can also be implemented by the HTTP stack so the
application doesn't have to.

 - pluggable authentication (see above)

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Jul 2012 18:33:47 -0700

> and specification re-use matter.)

I'd start by breaking this down into sub-elements of the problem space. So 
we have:
1. a protocol-independent authentication model
2. a set of rules to bind the protocol-independent model to an application 
protocol and perform an authentication exchange for that protocol.
3. an optional set of elements that can be added to the above model that 
are helpful for specific authentication mechanisms or security problems. 
Most of these elements shouldn't or don't manifest in the protocol and can 
be ignored by implementations until they are needed.
4. a client/server API
5. extensions to the client/server API for item 3
6. a generic client/server mechanism ABI to go with 4
7. extensions to a generic client/server mechanism ABI for generic 
client/server API

I consider standardization of items 1-3 incredibly valuable, 
standardization of items 4-5 of dubious value, and standardization or 
implementation of items 6-7 to be a design error in most cases.

SASL and GSS-API both adequately cover 1. SASL covers 2 well (I find 
GSS-API vague in that area albeit more flexible due to that vagueness). 
SASL largely ignored 3, while GSS-API adds value in that area. Both models 
botched handling of authentication errors, but that can be worked around on 
a per-application basis as needed.

The problem with trying to "market" the model to protocol implementers is 
that they may not understand that passwords-over-TLS won't be good enough 
forever, or they may want to pretend their protocol is the 
one-true-protocol and none of the other ones matter, or they may think 
their protocol is a special case, or they may have noticed that IETF 
authentication mechanisms have a poor track record and mistake that for 
lack of utility of a standardized model, or they may not understand how few 
constraints a standard model places on applications and implementations.

Perhaps a "guide to IETF application authentication" that focuses on how 
the SASL/GSS-API models impact protocols and their implementations without 
getting into any API cruft. And do it incrementally, perhaps like:

* You need TLS + password authentication in your protocol/implementation. 
Here are some issues to consider...

* Your code base supports authentication for more than one protocol. Here 
are some additional issues to consider...

* You want an IETF standards track application protocol with 
authentication. Some issues to consider... Checklist...

* You may have security conscious customers who want certificate 
authentication via TLS. Some issues to consider...

* You have customers who want multi-protocol single-sign-on (e.g., via 
Kerberos and/or Windows domain controller). Some issues to consider...

* You want to innovate on authentication. Some issues to consider...

The idea is instead of trying to convince them that the model we have is 
great, we need to help them solve their problem better and show how the 
model we have does that as they encounter new customer requirements.

		- Chris

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Jul 2012 04:57:39 +0200 (CEST)

While I'm in principle OK with trying to make GSS-API easier
to digest for app programmers, I find your document much harder
to understand than the original GSS-API spec, and I'm slighlty
concerned about misleading information in the document about
what can be reasonably expected from GSS-API implementations.

> API to just that exchange of authentication messages.

OK.

>  - the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and VerifyMIC)

Some authentication schemes may establish a shared (session) secret between
peers during authentication and offer "message protection" service that
application callers can use to protect their actual communication of
application data between the peers.

>  - GSS_Pesudo_random() (for generating sub-session key material for

Huge WARNING sign: this is not part of GSS-API v2 and not commonly available.

> is typically then used for authorization.  The interfaces to this are:

for visualization/debug purposes only.

>  - GSS_Display_name_ext()

not part GSS-API v2 and not commonly available
for > 90% of existing gssapi mechs.

>  - GSS_Export_name()

for populating ACLs and comparing authenticated peers to ACLs.

>  - GSS_Inquire_name()

not part of GSS-API v2 and not commonly available

>  - GSS_Get_name_attribute()

not part of GSS-API v2 and not commonly available
for > 90% of existing gssapi mechs.

And other that your document suggest, support for hostbased service names
(GSS_C_NT_HOSTBASED_SERVICE) is BY FAR not universal.
Of the ~20 gssapi mechanism implementation we have certified
for interop with our application, only the solutions implementing
Kerberos (rfc1964, rfc4121) support the hostbased service name,
*ALL* other do not support it.

Support for the nametype GSS_C_NT_USER_NAME is also quite questionable.
This nametype is defined to "indicate a named user on a local system.
Its syntax an interpretation may be OS-specific".  For GSS-API mechanisms
that are not tightly integrated with the OS, there may not even exist
a mapping between users known to a GSS-API and users known to the OS.
In general, GSS-API mechanisms have their very own notion of
identities, and these may be syntactically very distinct from users
as known to the OS.  One should not blindly assume that GSS_C_NT_USER_NAME
is ignored on input, but rather use GSS_C_NO_OID.

gss_display_name() will rarely emit usernames, but typically identities
as known natively to the GSS-API mechanism, with a "proprietary nametype"
that may either be defined by the spec describing this gssapi mechanism
(as it is with the Kerberos GSS-API mechanism), or might be
implementation defined (as it is with implementations of rfc-2025,
the "Simple Public Key Mechanism" due to the lack of a standardized
name format/syntax in the specification.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Jul 2012 22:13:18 -0500

>> and specification re-use matter.)

Let me go a bit further.  We've seen the rise of quite a few
frameworks where initially some protocol had one authentication
method, then another was added, then... and finally implementors
factored out authentication sub-protocols completely.

EAP and SASL grew organically like that.  GSS was more
design-by-committee contemporaneously with Microsoft's SSPI and with
SASL.  It should be no surprise that Microsoft uses one API to
interface to... three! frameworks: TLS, SASL, and GSS.  Three!  Heck,
with a bit of effort I think IKE could be added to that list so that
it could interface four frameworks.

Heck, we could easily make GSS mechanisms based on SSHv2, so we could
have one interface to five frameworks.

The point: the same pattern repeats over, and over, and over again.
Every time we build one more new framework we create duplication of
effort and code.  Every time we build a new framework we create bloat.

So just to be utterly clear: it's not a GSS fetish I have, it's a
re-use fetish.  Once upon a time that was widely thought a good thing;
isn't it still?

> I'd start by breaking this down into sub-elements of the problem space. So

Yes, roughly that is right.

> I consider standardization of items 1-3 incredibly valuable, standardization
> of items 4-5 of dubious value, and standardization or implementation of
> items 6-7 to be a design error in most cases.

Let's grant that for argument's sakes.  Does any harm come from
standardizing APIs/ABIs?  It happens all the time outside the IETF.
Are you merely objecting the IETF as the SDO for APIs/ABIs?  Did harm
actually follow from our having done so?

> SASL and GSS-API both adequately cover 1. SASL covers 2 well (I find GSS-API
> vague in that area albeit more flexible due to that vagueness). SASL largely

I find SASL utterly vague because it's specified entirely in English
language with nothing to add any formalism.  The GSS-API too is
specified in English language, but by having a notion of types and
functions it makes it much easier to specify how to use the GSS-API
formally, whereas SASL... there's no tools for formalism.  Why is it
OK to ask for the use of ABNF for specifying message forms, say, but
not to have a similar tool for specifying protocol flows and options?

> ignored 3, while GSS-API adds value in that area. Both models botched
> handling of authentication errors, but that can be worked around on a
> per-application basis as needed.

I'd like to hear more about the handling of authentication errors.
The GSS-API has a concept of error token for conveying authentication
error information.  Twelve years ago I had make sure that sshd sent
those so that clients had useful error information to show to users.

> forever, or they may want to pretend their protocol is the one-true-protocol
> and none of the other ones matter, or they may think their protocol is a
> special case, or they may have noticed that IETF authentication mechanisms
> have a poor track record and mistake that for lack of utility of a
> standardized model, or they may not understand how few constraints a
> standard model places on applications and implementations.

Yes, this is happening.

> Perhaps a "guide to IETF application authentication" that focuses on how the
> SASL/GSS-API models impact protocols and their implementations without

Actually, what I'd like to do is implement and see.  I can't right
now, but maybe in a couple of months.  We'll see.  My proposal is
partly designed to make it real easy to get near universal server-side
support by being implementable as FCGI (actually, I lie: I realized
this was so *after* I decided to use a RESTful design).  The
client-side is the hard part: I'd have to implement plugins for three
or four major browsers, and it'd be hard to get the proper level of UI
integration as a plugin.

> are some additional issues to consider...

Well, if we don't say this, no problem: within a few years the
framework pattern will repeat by itself :)

(But that should be a sad smiley.  I'm screaming from the rooftop that
there's no need to re-invent the wheel one more time.  We have so many
authentication frameworks...  But I guess we'll never learn.)

> * You want an IETF standards track application protocol with authentication.
> Some issues to consider... Checklist...
>

Right, we should give them running code.

Nico
--

---

From: Nathan <[email-masked]>
Date: Tue, 17 Jul 2012 21:24:43 +0100

> API to just that exchange of authentication messages.

can you summarise their functionality for me? (even though it's fairly 
obvious)

>  - GSS_Pesudo_random() (for generating sub-session key material for

Am I correct in thinking these correspond to commonly used terms:
  encrypt, decrypt (or seal and open)
  sign, verify
  and then just a typical random bytes function
?

>  - GSS_Get_name_attribute()

okay, functions to get details on the peer, what about the client details?

> Because HTTP is stateless, but the application protocol rarely ever is.

It's probably worth mentioning that I'm already one of the converted who 
uses HTTP strictly stateless, storing state in client side applications 
where needed - however I won't mention that again as it isn't useful to 
this convo, and obviously I did use sessions w/ http for years. No need 
to respond to this, just an fyi.

> responses) into one session.

understood - and I can see some merits to the pattern of storing "state" 
in restful resource.

Have you considered the use cases of shared session / application state 
between multiple clients? as this is something we run in to often.

aside: when I say we, I typically refer to a bunch of people I work 
closely with who are part of the Read-Write-Web CG, WebID group (you may 
be interested in this), Linked Data community and various related 
projects around W3C.

> enabled) to GET or DELETE it.

If the entire process is done over plain old HTTP, won't it be open to 
MIM attacks? and will it involve any passing of sensitive data (key info 
etc) over unencrypted / insecure transports?

> There's really not much to this resource.  If we must we can add a

may come back to this later in the discussion, I'll keep it in mind.

> HTTP can have an authentication scheme that... does not reuse other

This resonates with me, and enables me to see what you're trying to 
achieve as (please correct if wrong):

Define a simplified abstract protocol for creating secure sessions, then 
map that abstract protocol to HTTP, via the use of headers which allows 
resource to specify which type of security to use, and which resource to 
access in order to create and manage a session.

Correct?

> fell in the toilet, now I have no credentials."

Yes, this is one of the core issues we've found with WebID - so the 
point resonates.

> download your private keys so you can use user certificates, and even

Agree, things take time - but anything that involves certificates can 
involve jumping through an inordinate amount of hoops, either for 
developer or user.

> duplicating effort, at least for the long period of migration that

Admirable goal. To be brutally honest, the IDs I've read and which were 
discussing do not make this clear, they're:

a) verbose
b) couched in unfamiliar terminology from GSS
c) unclear, both in terms of structure, and as to what you're trying to 
convey.

I'm hoping that through this chain of emails you'll be able to explain 
to me simply the contents of the ID and what you're trying to achieve, 
and that may well be enough to write a much more generic and terse ID on 
the topic - which may help you greatly in your effort. Would be glad to 
learn what I can from you here and aid what you're trying to do, 
regardless of where it ultimately ends up - if that's okay with you.

> interested in before you finish authenticating the service

So authentication, rather than authorisation?

>  - sessions using something better than cookies (and with an option

why optional replay protection, isn't this a critical feature?

> mechanism selected requires multiple round trips

sounds good - I'm not clear on the details yet, but hope to be soon.

Best,

Nathan

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Jul 2012 16:13:17 -0500

> can you summarise their functionality for me? (even though it's fairly

GSS_Init/Accept_sec_context() drive the exchange of authentication
messages ("security context tokens" in GSS speak).

The model is that the initiator sends the first token, the acceptor
consumes it.  If the acceptor produces a token, then that is to be
sent to the initiator, and if the acceptor wants another token from
the initiator then the function will return a status indication for
that.  We loop until we're done.

These functions DO NOT do the I/O for the authentication message
exchange -- they deal in buffers, and it's the application's job to
actual send and receive them.

This allows for authentication message exchanges consisting of 1
message (half round trip), 2 (one round trip), 3, 4, ... N.  Most GSS
mechanisms have a fixed number of messages, but they technically can
use variable numbers of authentication messages.

The authentication message exchange is synchronous.  It's not possible
for one party to send two such messages without receiving one in
between.

There's a fairly large number of arguments to these functions, but
most inputs have reasonable defaults.  The ones that matter most as
follows.

Inputs:

 - target_name (initiator side) is the intended name of the acceptor, and it's a
   required input
 - mech (initiator side) is the intended mechanism choice, but takes a default
   value
 - input_cred_handle (both) is the credential object for the local
party; takes a
   default value
 - req_flags (initiator side) requests features
 - input_token (both), token from the peer

 - context (both) is an input/output parameter as these functions act as the
   constructor for the security context object on the first call, and then use
   the constructed context as the state object to tie the subsequent calls (if
   any) to the initial ones

 - all other inputs are not worth mentioning here

The outputs include:

 - actual_mech (both), being the mechanism that was used, which can differ
   from the initial choice if the initial choice can negotiate an alternate
   mechanism (e.g., SPNEGO can do this)
 - ret_flags (both), indicates what functionality is available
 - the context itself, of course
 - output_token (both), token to send to the peer
 - src_name (acceptor-side only), the authenticated name of the initiator

 - all other outputs are not worth mentioning here.

>  and then just a typical random bytes function

Yes, with the caveat that sign/verify are with symmetric keys, not
public keys ("signature"nowadays tends to mean "public key
signature").

> okay, functions to get details on the peer, what about the client details?

It's symmetric: each peer gets to know the other's name.  So the
client can ask about the server and vice versa.

(It's possible too for either or both peers to be anonymous.)

> where needed - however I won't mention that again as it isn't useful to this
> convo, and obviously I did use sessions w/ http for years. No need to
> respond to this, just an fyi.

REST-GSS allows for all REST-GSS server-side state to be stored by the
client, with that state being encrypted in a server key, of course.
The server could just cache the state instead of burdening all the
client requests with this state ticket; if the state gets lost then
the client just gets to re-authenticate.

> understood - and I can see some merits to the pattern of storing "state" in
> restful resource.

The state can be encrypted into a ticket that the client's requests
have to carry.

> between multiple clients? as this is something we run in to often.

No.  Where can I learn more about this?  Could the use of a state
ticket (see above) address this?

> If the entire process is done over plain old HTTP, won't it be open to MIM
> attacks? and will it involve any passing of sensitive data (key info etc)
> over unencrypted / insecure transports?

I envision REST-GSS being used either in conjunction with TLS (with
channel binding) or standalone.  When used standalone you'll want to
use the MIC option for certain to provide integrity protection to the
requests and responses.  I did not provide an option for TLS-less
confidentiality protection (i.e., encryption), should I?

> This resonates with me, and enables me to see what you're trying to achieve
> as (please correct if wrong):
>
> Define a simplified abstract protocol for creating secure sessions, then map
> that abstract protocol to HTTP, via the use of headers which allows resource
> to specify which type of security to use, and which resource to access in
> order to create and manage a session.
>
> Correct?

Yes.  I'm particularly interested in NOT forcing a one-size-fits-all
solution, which to me means we need a pluggable framework.

> involve jumping through an inordinate amount of hoops, either for developer
> or user.

The problem is not the certificates but the private keys.  Users can't
be expected to type them in :( so we need to carry them on thumb
drives, or better, smartcards.  But that creates all sorts of
problems.  Smartphones and tablets allow for device keys -- as if the
devices were or had an embedded smartcard.  But we don't always get to
use personal mobile wireless devices (e.g., in the corporate
environment it's all about desktops, terminals, servers).

So I think there must be room for password-based mechanisms, among others.

> I'm hoping that through this chain of emails you'll be able to explain to me
> simply the contents of the ID and what you're trying to achieve, and that
> may well be enough to write a much more generic and terse ID on the topic -
> which may help you greatly in your effort. Would be glad to learn what I can
> from you here and aid what you're trying to do, regardless of where it
> ultimately ends up - if that's okay with you.

Great.  I appreciate the help!  I am coming around to the idea of
re-writing the REST-GSS I-D in a way that doesn't remotely mention GSS
(nor SASL/GS2)... I can arrange for it to be such that it'd be exactly
compatible REST-GSS.  We did just this with SCRAM (RFC5802), which is
designed to be a GSS-API mechanism but not described as such in the
normative specification.

>>> something

Authorization follows authentication.  GSS gives you authentication
and information suitable for authorization, but the application has to
do the authorization bit.  E.g., the server has to decide whether you
get to GET a resource, POST to it, DELETE it....

> why optional replay protection, isn't this a critical feature?

If you use a state ticket (see above) then you can't have it, that's all.

> sounds good - I'm not clear on the details yet, but hope to be soon.

I truly appreciate that you're interested and asking these questions.
I am open to the idea that this is the wrong approach, or that
significant changes may be needed, but I can only really figure that
out when I get feedback like yours.

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Tue, 17 Jul 2012 22:03:32 -0700

> re-use fetish.  Once upon a time that was widely thought a good thing;

I think many have learned the hard way that code re-use is overrated. A 
generalized library that tries to solve many problems can be difficult to 
use, difficult to maintain and make problem diagnosis harder. Simple 
narrowly focused code can reduce long term costs better than re-use of 
complex general purpose code.

But protocol re-use and model re-use can have great benefits even if no 
code re-use is involved. I strongly support reusing the GSS/SASL model, but 
have zero interest in promoting the API. Indeed, I think promoting the API 
is harmful to this effort because it taints a useful model with complex 
implementation details that are often irrelevant to the problem at hand.

> actually follow from our having done so?

Absolutely. When a de-facto standard API/implementation for a technology 
arises and it has poor behavior in practice, it taints the implementer 
experience around that technology. This has happened time and time again. 
Good protocols that have inappropriately gained a negative reputation due 
to poor implementation/API design issues include: IMAP, LDAP, Kerberos and 
GSS.

I have no objection to developing an API in a standards organization, as 
long as it's at least a good API. GSS-API is not a good API. The model and 
protocol elements are fine and should be reused when appropriate, but the 
API stinks and I'll avoid using it whenever possible. I have the same 
opinion when it comes to SASL. The SASL API that I designed years ago is 
not a good API either, but I've found the SASL model incredibly valuable 
and useful in practice.

> Why is it

I would support development and/or use of a good tool for specifying 
protocol flows, states and options. I don't think the API portion of 
GSS-API is a good tool for this purpose.

		- Chris

---

From: Nathan <[email-masked]>
Date: Wed, 18 Jul 2012 16:30:44 +0100

> messages ("security context tokens" in GSS speak).

Thanks, I'll reply in full later on, if needed, however I think I just 
stumbled upon something which would be a natural blocker for me to even 
consider using this, and on which I need your comments.

It appears to me that this whole thing is premised on there being "one" 
peer in the server role, indicated by 'login-uri = relativeURI', and the 
assumption that the server delivering the requested resource (that which 
requires auth) has access to the security context.

The thing is, in almost every website / application I make, there are 
multiple (physical and virtual) servers, and the setup would need to 
involve two peers in the server roles - additionally often this is 
delegated to SSO servers, or via third parties as in oath and openid.

Can you explain how this would work when there are three machines involved:
C - Client
DS - Document Server
AS - Authorisation Server

C requests a document from DS,
DS says that it needs authorisation and points the client to AS
...?????....

Cheers,

Nathan

---

From: [email-masked] (Martin Rex)
Date: Wed, 18 Jul 2012 17:44:22 +0200 (CEST)

> DS says that it needs authorisation and points the client to AS

Such an exchange does not exist.

When the process of authenticating client/initiator to server/acceptor
requires communication with third parties, then any such communication
would have to be performed by the GSS-API mechanism "under the covers"
during gss_init_sec_context() on the client side or during
gss_accept_sec_context() on the server side.

Take Kerberos 5 as an example, where an authentication between client
and server (traditionally) uses a two token exchange:
an AP_REQ token client -> server and AP_REP token server -> client
in response.  In order for the client to produce an AP_REQ token,
the client needs to already have a kerberos ticket for the server
available, or the client will have to perform a TGS_REQ/TGS_REP
exchange with the KDC under the covers during gss_init_sec_context().

When a (Microsoft) PAC in the service ticket is to be used by the server,
then the server might perform a communication under the covers during
gss_accept_sec_context() with Active Directory to validate the PAC
from the service ticket.

For the application on top of GSS-API, there exist only the two communication
peers client/initiator and server/acceptor.

-Martin

---

From: Simo Sorce <[email-masked]>
Date: Wed, 18 Jul 2012 11:54:45 -0400

> Such an exchange does not exist.

Martin I would refrain from such absolutes because they are certainly
wrong.

The scenario Nathan describes above is quite common.

> gss_accept_sec_context() on the server side.

I think you misunderstand what Nathan is saying, Nathan is talking about
application level behavior not authentication protocol behavior.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Nathan <[email-masked]>
Date: Wed, 18 Jul 2012 16:57:11 +0100

> peers client/initiator and server/acceptor.

That's what I thought, I can't see how it would be possible to make GSS 
RESTful given these constraints, it seems to contradict the ethos of the 
uniform interface - we need the solution to be stateless, uniform, and 
something which hides implementation details, such that it doesn't 
matter whether there are 1 or 1000 physical/virtual servers/proxies 
hiding behind the interface exposed by HTTP (or any RESTful protocol).

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2012 11:04:18 -0500

On Wed, Jul 18, 2012 at 10:57 AM, Nathan <[email-masked]> wrote:
> something which hides implementation details, such that it doesn't matter
> whether there are 1 or 1000 physical/virtual servers/proxies hiding behind
> the interface exposed by HTTP (or any RESTful protocol).

REST-GSS has a stateless mode where the state is kept in an encrypted
state ticket that is carried in every client request.  This  mode
can't do replay protection.  This mode *can* more easily share a
single session across many servers (though the alternative, with
absolute session URIs, can also result in sessions spanning many
servers if those servers can access the shared resource).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2012 11:01:32 -0500

On Wed, Jul 18, 2012 at 10:30 AM, Nathan <[email-masked]> wrote:
> It appears to me that this whole thing is premised on there being "one" peer
> in the server role, indicated by 'login-uri = relativeURI', and the

I just added the relativeURI thing, but it seemed wrong.  Yes, I think
we want sessions to have "scope" that can span many servers (in one
domain).  I can't change this till next week.

> DS says that it needs authorisation and points the client to AS

I'd expect that DS just runs through REST-GSS and returns a session
URI (which cannot be relative) and just performs the authorization
itself.  In general I expect authorization to be done at each
resource.  REST-GSS with absolute session URIs can cope with
separating where authentication happens from where authorization
happens, but it does nothing to make it possible to do authorization
on servers that are not the ones where the resources being accessed
are -- for that we'd want "capabilities", say, but does one want a
couple of redirects for every resource being accessed??

Nico
--

---

From: Nathan <[email-masked]>
Date: Wed, 18 Jul 2012 17:12:43 +0100

> couple of redirects for every resource being accessed??

I have a feeling that a continuation of this thought train would just 
end up at OAuth(2). ?

---

From: [email-masked] (Martin Rex)
Date: Wed, 18 Jul 2012 18:13:46 +0200 (CEST)

> The scenario Nathan describes above is quite common.

I'm sorry for the misunderstanding, I did not intend to offend anyone.

This was meant to say:

At the abstract model of the GSS-API that is exposed to the application,
such an exchange does not exist.

> application level behavior not authentication protocol behavior.

I believe I understand his example.  That's why I described the
situation for Kerberos 5, which always involves _at_least_ 3 parties
at the lower protocol levels, but appears as just initiator and acceptor
at the GSS-API for the application.

Any additional complexity necessary to implement a "gss-api mechanism"
can only use the initial token exchange between client/initiator and
server/acceptor, and the gssapi mechanism must do all other communication,
that might be necessary, under the covers.  In special situations, it
could be a communication to a third party that a client needs, but which
can only be performed by the server.  So a special gss-api mechanism
could extend the authentication token exchange to first forward the
request from client to server, have the server perform the communication
with the third party under the covers during gss_accept_sec_context()
and return the result in a gssapi context token to the client.

One such example is "Initial Authentication for Kerberos (IAKERB)"

http://tools.ietf.org/html/draft-ietf-krb-wg-iakerb-02

-Martin

-Martin

---

From: Simo Sorce <[email-masked]>
Date: Wed, 18 Jul 2012 12:29:53 -0400

> at the GSS-API for the application.

My time to apologize, I misunderstood your point.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2012 11:35:30 -0500

> I'm sorry for the misunderstanding, I did not intend to offend anyone.

I was not offended...  However, I do think that you're missing
context.  And, of course, to the extent that you dislike all GSS
extensions (all outside RFCs 2743/2744, since my proposal depends on
some, you might not like it (but the extensions ship has sailed).

> such an exchange does not exist.

Indeed.  However, one can build applications that work in this way.

The problem I have with Nathan's scenario is that I doubt he envisions
authorizing access to every resources in this way.  Instead I suspect
that this only happens occasionally in his scenario.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 18 Jul 2012 18:58:19 +0200 (CEST)

Nico Williams wrote:
>
> Martin Rex <[email-masked]> wrote:
>> 

I'm OK with extensions of the GSS-API!

I just want to point out which of the extensions that you mentioned
are typically unavailable in the installed base of GSS-API mechanisms.

While support for hostbased service names is available in pretty much
all Kerberos and Kerberos-derived GSS-API mechanisms in the installed
base, none of the other functionality is.

With installed base, i mean Microsoft Kerberos in Win7/2008R2, Vista, older,
Kerberos included in (Enterprise) Linux Distros,
Kerberos included in HP-UX 11.31, SunOS 5.10, AIX 6.1, ...
Quest's Vintela, DCE (where it isn't extinct) ...

> Indeed.  However, one can build applications that work in this way.

But that has nothing to do with GSS-API then.

Of course one can extend the GSS-API in various proprietary and mechanism-
specific ways, but that usually means that no "portable application" that
was designed to use GSS-API for authentication, will use/work with such
extensions.

And if your application protocols are made vitally dependent on such
extensions being available, you'll run into problems if you try to
plug'n'play other GSS-API mechanisms as alternatives that do
not support these extensions.

-Martin