Subject: RE: low-infrastructure GSS mechanisms?

From: [email-masked]
Date: Wed, 6 Jan 1999 09:09:49 -0800

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]

---

From: [email-masked]
Date: Fri, 8 Jan 1999 08:29:12 -0500

From: [email-masked]
   Date: Wed, 6 Jan 1999 09:09:49 -0800
	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.  

	draft, I'm not aware of any IETF work on the others).  

I think it would be highly useful for there to be an option where a DH
tunnel is established before doing the digest authentication.  Given
that an implementation of a DIGEST-MD5 GSSAPI mechanism will require
defining a new protocol with the appropriate GSSAPI token framing, the
additional effort to specify and then implement a DH tunnel really isn't
that significant.  DH isn't rocket science, and now that the patent has
expired, we don't have the intellectual property constraints which have
traditionally hindered the deploymeny of PK cryptographic systems.

Furthermore, GSSAPI offers confidentiality and data encryption services,
and I think that it's really important for a low-infrastructure
mechanism to provide these services.  Given that it's not hard to do
this, I think we should add these features.

					- Ted

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 08 Jan 1999 15:43:59 +0100

CAT fanciers,

I am joining the discussion first to thank John from lauching the topic as a
result of the discussion we had in Orlando.

> tunnel is established before doing the digest authentication.

You said "an option". Maybe, maybe not. The first priority is authentication only.
I would like that we focuss on authentication before considering the two other
services. Adding these two other services add some constraints in the choice of
the authentication solutions and I would not like that we discard a solution on
the basis that it is unable to handle integrity or confidentiality.

> Given

I believe it is much harder than doing authentication only. :-)

Denis

---

From: [email-masked] (David P Jablon)
Date: Fri, 8 Jan 1999 12:23:26 -0500

[email-masked] wrote:
> >         EKE, SPEKE, SRP), however I'm not sure they can be as lightweight [...]

Perhaps signed DH requires more infrastructure, but DH, EKE, SPEKE,
SRP, and other password-authenticated DH schemes require no more
infrastructure than what's needed for DIGEST, other than an
exponential arithmetic function.  Exponentiation adds some 
"weight", but in most applications it seems well worth the cost.

Denis Pinkas wrote:
> services.

Ok, but even if we ignore message integrity and confidentiality,
DH and password-authenticated DH schemes still add a lot of value
in preventing eavesdropper and related brute-force password attacks.
Furthermore, when used in this sole capacity, they are freely
exportable.

> I believe it is much harder than doing authentication only. :-)
 
Why the smirk?  I don't believe it's harder at all, and I won't
presume to guess why you do. 

Given access to freely available source, it seems easy to
provide both strong protection for passwords,
plus password-based integrity and/or confidentiality if desired.
Even without using free source, there's plenty of documentation
around on how to verify a password without revealing it, and 
how to use a password-authenticated key to encrypt a session.

Did you have some other difficulty in mind?

------------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
Westboro, Massachusetts
[email-masked]
<http://world.std.com/~dpj/>