Subject: RE: Planning for DC IETF CAT session

From: Matt Hur <[email-masked]>
Date: Fri, 31 Oct 1997 08:29:22 -0800

Take another example:
LDAP specifies the use of SASL for authentication negotiation, and I
believe that they intend to use SSL/TLS for encryption (i.e. run an LDAP
session over SSL).  LDAP seems to be a likely candidate for the
evangelizing of current technologies that Mike suggests.  They already, use
ASN.1 encoding.  So, why is SASL seen as a better alternative to GSS-API?
Is it because SASL is perceived to be easier and offer more flexibility?

The SASL draft (draft-myers-auth-sasl-13.txt) is an interesting read.  It
doesn't specify a protocol.  I'm not really sure what it specifies.  It
suggests that security mechanisms be registered, but it provides for no
peer review of these mechanism (i.e. via an IETF working group).  It seems
to me that we could improve on this.

--Matt Hur

At 06:37 PM 10/30/97 -0800, Mike Swift (NT) wrote:
>At the last IETF meeting there was a BOF for designing a new authentication
>protocol/ interface because GSS-API was seen as too difficult to use. TLS
>doesn't use GSSAPI. IPSEC similarly is developing authentication protocols /
>key exchange protocols without using GSSAPI. While there are many protocols
>that do use GSSAPI (IMAP, SASL) for example there is still a widespread
>perception that it is too hard and cumbersome to use. Perhaps there is a
>need for some simple non-ASN.1 authentication mechanisms that are more
>usable, such as a simple challenge-response protocol, or a set of good
>examples of how to correctly call GSS-API.
>
>- Mike Swift
>
>> -----Original Message-----
>> From:	Dennis Glatting [SMTP:[email-masked]]
>> Sent:	Thursday, October 30, 1997 6:22 PM
>> To:	Mike Swift (NT)
>> Cc:	Linn, John; 'CAT-WG List'
>> Subject:	Re: Planning for DC IETF CAT session
>> 
>> 
>> From: "Mike Swift (NT)" <[email-masked]>
>> Date: Thu, 30 Oct 1997 11:35:58 -0800
>> 
>> > There are far too many groups that are inventing their own
>> > authentication and security negotation mechanisms and I
>> > believe the CAT group should either do more evangelizing of its
>> > current technologies or really look at why what it has today
>> > doesn't work and come up with some plans to address their
>> > issues.
>> >
>> 
>> Such as...?
>> 
>> 
>> -dpg
>
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Nov 1997 22:35:46 +0100 (MEZ)

> Is it because SASL is perceived to be easier and offer more flexibility?

GSS-API is not a complete on-the-wire protocol.  It provides
a standardized API for easy application portability and a standarized
token framing.  It can be integrated into many different existing
communication protocols.  The gssapi framing will automatically interoperate,
the different application protocols will most probably not.

Availability of public key based implementations is probably the
major issue in the case of LDAP.   There are a lot more SSL implementations
available and deployed than there are SPKM implementations.  And they
come with a completely defined on-the-wire protocol.

-Martin

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 8 Nov 97 17:07:21 -0800

From: Martin Rex <[email-masked]>
Subject: Re: Planning for DC IETF CAT session

> GSS-API is not a complete on-the-wire protocol.  It provides a
> standardized API for easy application portability and a
> standarized token framing.  It can be integrated into many
> different existing communication protocols.  The gssapi
> framing will automatically interoperate, the different
> application protocols will most probably not.
>

That's a little strong, IMO. Yes, the "framing" may
interoperate but that matters not if the acceptor and
initiator do not have the same mechanism set.

> Availability of public key based implementations is probably
> the major issue in the case of LDAP.   There are a lot more SSL
> implementations available and deployed than there are SPKM
> implementations.  And they come with a completely defined
> on-the-wire protocol.
>

Of course there is more SSL than SPKM. There is a greater
quantity of product being sold to absorb the RSA license fees.

Hmm...

How about dumping the RSA in SPKM in lieu of DH/DSS?

-dpg

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 Nov 1997 10:56:23 +0100 (MEZ)

> initiator do not have the same mechanism set.

That's required with SSL as well, so I didn't count it.

(I don't know SSL, so I'm slightly guessing:)
If I issue myself a Certificate with my own CA or if I use a
DSA-based Certificate, most SSL-Implementations will not be
able to authenticate me.  They still may provide an encrypted
channel.  The GSS-API idea is to provide secure authentication,
integrity and confidentiality is added value.

> How about dumping the RSA in SPKM in lieu of DH/DSS?

Why dumping?  You could add DH/DSS to the current spec,
or you could define a new mechanism in the SPKM family
that used DH/DSS as mandatory and default and RSA only
as optional.

-Martin

---

From: Dennis Glatting <[email-masked]>
Date: Mon, 10 Nov 97 06:46:31 -0800

From: Martin Rex <[email-masked]>
Date: Mon, 10 Nov 1997 10:56:23 +0100 (MEZ)

> that used DH/DSS as mandatory and default and RSA only

Agree. But thinking about it a little more I think my thought is
dumb: by the time we go through the process of creating a new SPKM
or modifying the old, the patent will probably have expired.
After the patent expires, does a DH/DSS SPKM have value?

-dpg