Subject: RE: low-infrastructure GSS mechanisms?

From: "Linn, John" <[email-masked]>
Date: Tue, 5 Jan 1999 10:30:58 -0500

It certainly appears that there's WG interest in this topic.  Here's my
sense of where the situation stands:

(1) It appears technically feasible to write GSS mechanism specifications
for one or more candidate mechanisms in the "low-infrastructure" space;
while protocol descriptions exist for several such mechanisms and
GSS-oriented prototype implementations have been cited, no full GSS
mechanism specifications yet exist.  As well as being an appropriate basis
for implementation, the exercise of drafting such specifications would
either confirm their feasibility or identify any problematic issues.  

(2) By design and intent, GSS supports cross-mechanism portability.  It's
not necessary for the group to agree on exactly one mechanism, and demand
may exist for mechanisms with different characteristics and constraints for
different usages.  On the other hand, it would diffuse effort and limit
interoperability if large numbers of mechanisms emerged without clear
criteria for preference and selection.  Further, the IETF process requires a
demonstrated constituency in order to advance a specification on the
standards track; if large numbers of proposals were pursued for
standardization, constituencies would probably be fragmented. 

(3) The current level of GSS adoption by applications appears modest.
Support for low-infrastructure mechanisms could allow integration of such
mechanisms with applications in a uniform way, and could permit coexistence
with and migration to other mechanisms, like those currently implemented
under GSS.  This offers the potential to broaden GSS usage, if mechanisms
specified per (1) become widely implemented and available, and if their
operational characteristics are acceptable to application users. 

(4) Mechanism characteristics aside, the GSS integration paradigm is
considered unfamiliar or complex by some application writers.  Among other
functions, SASL can be used to encapsulate GSS-level calls.  A SASL-layer
API specification, which would provide an alternative API-level integration
strategy to GSS, is under preliminary discussion outside the WG but has not
yet been presented. 

Question: Is anyone interested, willing, and able to undertake the task of
specifying a low-infrastructure GSS mechanism, per (1)? 

--jl 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Chris Newman <[email-masked]>
Date: Thu, 07 Jan 1999 17:27:29 -0800 (PST)

Just to put in my two cents:

On the topic of a DH-based /etc/passwd (and equivalent) backwards
compatible mechanism, I think there is an opening for something
low-infrastructure.  I wrote a draft of a DH based mechanism which could
be used to just send the password (or optionally protect the rest of the
session) in draft-newman-sasl-passdss-01.txt.  The crypto was ripped off
of Secure Shell v2 since that was the best-documented ASN.1-free crypto
that a mere mortal could understand.  I went to some trouble filling
in all the things crypto people take for granted which apps people might
not know.  The effort was killed when I was told I that before
standardization I had to add lightweight re-authentication, wait for
Secure Shell to be standardized, and shouldn't I just use TLS instead.

On the topic of a hash-based lightweight challenge-response mechanism, if
this group does one, please don't invent yet-another server backend format
for password verifiers.  DIGEST-MD5 seems to be gaining rough concensus in
the apps area as the default mandatory-to-implement mechanism for apps
protocols, so compatibility with the backend format it uses would be wise.

I'm not sure it's a good idea to be possible to do SASL+DIGEST-MD5 and
SASL+GSSAPI-mechanism+DIGEST-MD5.  That's two different protocols to
accomplish the same function.  However, having a DIGEST-MD5 GSSAPI
mechanism for use by non-SASL protocols (e.g., PPP, IPsec) seems
like a good idea to me.

		- Chris