Re: [kitten] sasl saml and sasl openID

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Mon, Nov 15, 2010 at 06:26:39PM -0500, Sam Hartman wrote:
> > 
> > OK, then I'd probably vote against supporting CB for SAML20.
> > My concern is that if we do, it will discourage apps from using CB
> > because it will significantly decrease their interoperability.
> 
> What apps are we talking about?  Remember, SASL/GS2 does make CB
> negotiable, while straight GSS-API makes it non-negotiable.

As I tried to explain here:
http://www.ietf.org/mail-archive/web/kitten/current/msg02121.html

it is definitely possible for GSS-API to use optional channel bindings,
i.e. negotiate the use of channel bindings.

You might, however, create a security problem for you protocol if
you outsource the protection of your network communication to some
other protocol instead of using GSS-API message protection primitives.

And one means to prevent the total disconnect of authentication from
the protection of the network communication is a concept called
"channel binding".  The GSS-API channel bindings facility is
a very specific subset of the "channel binding" concept.


In the original GSS-API design, there did not exist the idea of
gss-api mechanism that are authentication only or worse, out-sourcing
of message protection facilities to some other protocol.

Although I just noticed in the San Diego IETF meeting minutes March 1992
of the CAT working group the question:

  Discussion:
    . GSS-API:  for authentication only ?


but I also remember a presentation from Sanra Murphy (TIS) in the
CAT WG session on IETF 33 (July 1995 in Stockholm) and a very notica
suprize by many CAT fanciers about the very first GSS-API mechanism
that does not support message protection at all ... and a few resulting
clarifications to the GSS-API v2 I-Ds.

   http://tools.ietf.org/html/draft-ietf-cat-fipsjjjgss-00

And as it's primary purpose of this PKI-based mechanism was unidirectional
authentication of the initiator to the target, that initial proposal
is completely silent about naming, in particular possible or anticipated
values for the target_name parameter of gss_init_sec_context().

But similar to SPKM and DEC DASS, the concept of X.509 identities
back then was nothing like hostbased service names.

As I've previously mentioned, during the last 14 years we have been
offering interoperability certification for third-party single sign-on
solutions provided as plug-n-play shared libraries based on GSS-API v2.
I've seen ~20 different SSO-solutions, 5 of them were implementations
of Kerberos 5,  two were completely proprietary and the rest based
on X.509/PKI.  Only the Kerberos implementations recognized the
hostbased service name nametype, all other implementations rejected
it upfront with "GSS_S_BAD_NAMETYPE".


And when you're doing distributed apps, then being able to identify
apps completely independent of hostnames facilitates a lot of things.
There could be easily be running 5 or 6 apps independently using the
same protocol on a single host (HumanResource,Financials,ProcessIntegration,
MaterialsManagement,SupplyChainManagement, plus seperate apps development,
integration and test systems of each) and alternative instances of the
same app on 10 more hosts for distributing load, background and
batch processing.  Most X.509 based authentication schemes use 3-way
or 4-way authentication exchanges (signed challenge/response), so
that all distributed instances of a single application can share the
PKI credential and it is irrelevant for the user to which particular
host and which particular port it connects as long as the user
knows what system it wants to talk to, e.g. "Human Resources",
and neither the "Human Resources (Test)", "Customer Support"
nor "Financial (apps development)" system.  Also the ACLs that
all AppServers of a single system use to talk among each other
are pretty short with only one single entry.

If you are using Kerberos, things get difficult and complicated,
because every seperate instance has to be managed individually
and every move of an application instance to a different host
requires updates to all ACLs.  And you still need to devise
some scheme to distinguish several different entities of apps
that are based on the same protocol on a single host.


When you adapt the IETF robustness principle to application design
for GSS-API then it works like this:
"be liberal in characteristics and implementation choices
 that gssapi mechanims may exhibit, be conservative in
 the GSS-API features that you require for interoperability."

and host-based service names are nowhere close.

-Martin