FW: Talking with Kerberized services using GSS-API

[Ken Hornstein]

>Secondly, I understand SASL can offer up one mechanism (GSSAPI) on a 
>session and an additional session/mechanism such as EXTERNAL.
>Why not provide for future flexibility?  If I can offer up PKI via EXTERNAL 
>in addition to GSSAPI does it defeat the purpose of PKINIT?  I believe their
>is a lot to be said for the SASL (GSSAPI) layer in the design of any API.
>
>I'm just exploring this area and hopefully not off the thread, why wouldn't
>one write to the GSSAPI API?  Thoughts?

I've written GSS-API apps, SASL apps, and raw Kerberos apps, so here's
my $0.02:

- Generally, I try to write to whatever security framework already exists.
  For example, if you're doing a Kerberized FTP implementation, that framework
  uses GSS-API, so it makes sense to use GSS-API.  Things like SMTP use
  SASL, so SASL makes sense in that framework.

- If you _ever_ think you might want to use another authentication mechanism,
  then GSS-API or SASL is the way to go.  I might even lean toward SASL in
  that case, because I think that mechanism negotation in SASL actually
  works (IMHO GSS-API lags on this).

- If I'm just writing something internally that has it's own protocol,
  then I generally just use the raw Kerberos API, as I've found that's
  _much_ simpler.  Note that not everyone agrees with me on this one.

- There are things you can do via the Kerberos API that you can't currently
  do via GSS-API or SASL.  Most people don't need to do these things,
  but occasionally I've run into cases where I do.

--Ken