Re: GSSAPI and SSL?

[John Nunneley <[e-mail]>]

Mike -
Thank you for the informative and helpful response.

I guess I am just demonstrating my ignorance of both GSS-API and SSL.  I
had assumed from my casual investigation that GSS-API was ("just") an
API and that it was fully intended for developers to provide specific
mechanisms (such as Kerberos and SSL) underneath.  Further, I'd thought
that the tokens were completely opaque to the application and were
mechanism specific - i.e. it is the role of the specific mechanism to
determine how the authentication/integrity/privacy gets implemented, as
SSL does.

I've also gathered from related postings that Microsoft is attempting
something similiar - i.e. a GSS-API w/ SSL and Kerberos and other things
underneath.  I suppose I'll need to track what's going on with that
side.  Does the MS GSS-API (SSI) have any resemblance to GSS-API? 
Anybody got a spare pointer?

I'm also not sure what SASL is that you refer to?

Judging from the excellent summation of the discussion so far Bill
Buffman made, I suspect I'm not the only one suffering from confusion on
this point.

Thanks, John
*************
Mike Eisler wrote:
> 
> 
> The philosophy of GSS-API is that it creates tokens that the application
> has the freedom to package and transport between network peers as it
> wishes. SSL on the other hand specifies how the transport of signed and/or
> encrypted data works. So any layering you produce has to reconcile the
> two different philosophies. Effectively, you'd have to design a uniform
> protocol for how GSS-API tokens get transported, and also extend your
> application's protocol to switch among GSS-API, SSL, and no security:
> 
>         generic security layer
>                  /      \
>                 SSL     protocol for encapsulating GSS-API
>                  |         |  \
>                  |         |   GSS-API
>                  |         |
>         --------------------------------------------------------------------
>              application protocol (with extensions for switching
>                                         between SSL, GSS-API encapsulation,
>                                         and no security).
> 
> I haven't looked at SASL, but I suspect SASL would work as a way to extend
> most application protocols to switch among security frameworks. Alternatively,
> one could do something like the extensions to FTP for adding GSS-API and SSL.
> Your mileage will vary depending on the application protocol.
> 
> The above looks sufficiently cumbersome (I know of at least one attempt to
> make it work that was abandoned) to make me want to have my application
> protocols use either just SSL (so in your case, take a look at the ID for
> adding Kerberos V5 to SSL), or GSS-API.  Alternatively, wait for IPSEC.  I
> think Dan McDonald of SunSoft ([e-mail]) has put together, or is in
> the process of putting together some IDs (for the Informational track) for an
> API to IPSEC.
> 
> For my application, ONC RPC, I picked GSS-API (see
> draft-ietf-oncrpc-rpcsec_gss-02.txt), simply because RPC already had support
> for encapsulating security parameters and I saw little need to use SSL's
> (politics isn't a good reason to do something redundant). And IPSEC
> authentication doesn't work well with RPC. If I need SSL security, I'll use a
> GSS-SSL mechanism or an equivalent. Personally, I see RPC as the preferred way
> to create new secure protocols that don't want to wait for IPSEC or can't use
> IPSEC, but obviously I have a bias (note affiliation below).
> 
> As to the activity around GSS-API, there's quite a bit. For example, I have in
> my hand a white paper from Microsoft that details their use of GSS-API under
> NT 5.0.
> 
>         -Mike Eisler
>         Solaris NFS Group, SunSoft, Inc.
>         [e-mail]
> 

-- 
------------------------------------------------------------------------
John Nunneley                                Phone: [phone]
DASCOM Inc.                                  Fax:   [phone]
1509 Seabright Avenue                        Email: [e-mail]
Santa Cruz CA 95062                          WWW: http://www.dascom.com/
------------------------------------------------------------------------