Subject: RE: low-infrastructure GSS mechanisms?

From: Paul Leach <[email-masked]>
Date: Wed, 6 Jan 1999 09:44:36 -0800

I'll help, too. I've written a draft on the use of Digest as a SASL
mechanism; a definition for its use as a GSS mechanism would be good, too.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 06, 1999 9:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: low-infrastructure GSS mechanisms?
> 
> 
>      I'm willing to put some time into a "low-infrastructure" 
> GSS mech 
>      draft if others are willing to look at it and are 
> thinking of possibly 
>      implementing it.  
>      
>      There is still the question of what the mechanism(s) should be. 
>      Originally I was thinking of SCRAM or DIGEST-MD5 as a 
> possible mech 
>      because they are lightweight and fit some definitions of low 
>      infrastructure. Another possibility are variants on DH 
> (Signed DH, 
>      EKE, SPEKE, SRP), however I'm not sure they can be as 
> lightweight and 
>      they also need some work on the protocol description 
> (there is an SRP 
>      draft, I'm not aware of any IETF work on the others).  I believe 
>      another proposed option was plaintext passwords within 
> an SSL session, 
>      while this is not quite lightweight, it appears to be 
> widely used.
>      
>      So vote for your favorite mech.  If there are any votes 
> then I'll take 
>      that as interest in this work.  If for some reason you 
> feel the need 
>      to vote and you do not think this is a worth while 
> effort then please 
>      say so.
>      
>      My vote is for a Digest mechanism.
>      
>      Joe
> 
> 
> ______________________________ Reply Separator 
> _________________________________
> Subject: RE: low-infrastructure GSS mechanisms?
> Author:  jlinn ([email-masked]) at internet
> Date:    1/5/99 7:30 AM
> 
> 
> 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]
> 
> ==============================================================
> ============
> 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]
> 
==========================================================================
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: Michael Smith <[email-masked]>
Date: Wed, 06 Jan 1999 13:22:13 -0500

At 09:09 AM 1/6/99 -0800, [email-masked] wrote:
>     I'm willing to put some time into a "low-infrastructure" GSS mech 
>     draft if others are willing to look at it and are thinking of possibly 
>     implementing it.  

I'd be happy to help with a draft.

>     My vote is for a Digest mechanism.

Mine too. We have done a version of Digest authentication
(as specified for HTTP) here; may I suggest that, or something 
similar? 

--Michael Smith
  [email-masked]