Re: [kitten] sasl saml and sasl openID

[Martin Rex <[e-mail]>]

Sam Hartman wrote:
> 
> You've certainly seen a lot of GSS-API mechanisms.  However those
> mechanisms were not proposed for standardization within the IETF.

Actually, it is just the opposite.

  http://tools.ietf.org/html/draft-ietf-cat-kerb5gss   (->rfc1964)
and
  http://tools.ietf.org/html/draft-ietf-cat-spkmgss    (->rfc2025)

have about the same age.

rfc-2743, section 5.3
  http://tools.ietf.org/html/rfc2743#page-90
was already part of the very first GSS-API v2 draft
  http://tools.ietf.org/html/draft-ietf-cat-gssv2-00

and described the architecture of a real implementation/product
that we certified for interop with our app in 1998.

So the architecture for X.509/PKI gssapi mechanism related to SPKM
existed at least one year before I first heard about the existence
of GSS-API.


During the design of the GSS-API support by our application, I tried
to accomodate for the _published_ characteristics, because it was clear
that we were _not_ going to build and ship Single Sign-On solutions
ourselves, but instead rely solely on third-party products and
therefore be portable as much as our own architecture allowed.

Adding an addtional target-identity paramter to all connection APIs,
command lines and configurations was actually trivial compared to the hoops
we had to jump through in order to account for Kerbgss shortcomings.


The non-obvious Kerberos 5 gssapi mechanism problems:

    - enforced security context expiration.  Our app is the only app I know
      that implements a security context refresh logic in order
      to replace an expiring gssapi security context with a new
      one for longterm communication links

      For a very short time in Windows2000 Beta3 Microsoft enabled
      security context expiration and realized that they couldn't
      handle it, so they are ignoring it ever since.

      Some SPKM mechanisms offer lifetime-limited security contexts
      at request by the application.

    - initiating credentials expiration requiring frequent out-of-band
      refresh operations.  The side-effecting of credentials lifetime
      on security context lifetime is a challenge for automatic
      security context refresh logic.

      Other than TLS, security context refresh is burdened completely
      onto the caller above GSS-API, who has to establish a seperate
      security context, check whether the lifetime of the new is
      longer than the remaining of the old and then synchronously
      change from using the old security context for message protection
      and unprotection to using the new security context and deleting
      the old.

      Expiring initiating credentials required admins of distributed apps
      to configure e.g. a frequent cron-job "kinit -k app-abc/host.f.q.d.n"
      to refresh initiating creds, because many kerb-libraries on unix
      didn't simply do this themselves and didn't document this necessity
      anywhere either.  Microsoft Kerberos was the first Kerberos5
      implementation I saw with an acceptable credentials management.

    - users can not acquire accepting credentials
      With SPKM you can initiate trivially in both directions, while
      with Kerberos5, whenever you need a parallel,independent,
      gss-api protected communication link established, you need to
      ensure that the original initiator will also be the initiator
      for all additional parallel communication links.

      With SPKM, no such restriction exists, so an acceptor can
        gss_inquire_context(old_ctx, &src_name, &targ_name);
        gss_acquire_cred(&acc_cred, &targ_name);
        gss_init_sec_context(cred=acc_cred, target=src_name, &new_ctx)
      with ease, while with Kerberos, the app must first define
      and transfer an app request over old_ctx telling the initiator
      to establish a new security context.

      Microsoft Kerberos allows users to acquire accepting credentials.
      Since there is some security problem with allowing rfc-1964 two-token
      authentication with acceptors using password-based keys, Microsoft
      also implemented a (so far not standardized) variant of the
      Kerberos 5 mechanism for the "user2user" or "double-TGT" authentication
      scheme from the Kerberos 5 protocol specification.

    - Kerberos does not work across firewalls and alien address spaces
      Our app client was/is able to traverse proxy chains, e.g. in order
      to access customer systems for remote support.  Securing such logons
      with Kerberos will never work.  There is a proposal for an
      "IAKERB" gssapi mechanism from Microsoft to "out-source" all
      communication between the initiator/client and the KDC to the
      acceptor/server, but there hasn't been much visible progress over
      the last decade.

      SPKM mechanism implementations without a prerequisite of KDC-like
      access to an online directory (as Entrusts product) work just fine
      across any number of app-level proxies and completely independent
      of the low-level network connectivity between initiator and acceptor.


Having to accomodate for the lack of hostbased service names
in your app and app protocol is really a no-brainer.

Accounting for undocumented shortcoming of most Kerberos implementations
in a large distributed application, on the other hand, requires quite
an enormous effort.


I do remeber our first Video Conference with MIT & Ted Ts'o in April 1995,
when we discussed how to make Kerberos Single Sign-On usable for our
application, and I proposed to use GSS-API to interface to MIT Kerberos.

Ted was very explicit that using the native Kerberos API would
be much easier for us -- but I alread had obtained a requirement
to support an X.509/PKI based authentication scheme for specific
other customers, so I chose GSS-API as a common ground for a
unified solution architecture.  And then Ted got me involved
with the IETF.

-Martin