Subject: low-infrastructure GSS mechanisms?

From: "Linn, John" <[email-masked]>
Date: Mon, 21 Dec 1998 15:40:49 -0500

CAT fanciers: 

At several points during the Orlando IETF meeting, culminating at the EAP
BOF on Friday morning, I heard interest expressed in the availability of
"low-infrastructure" mechanisms under GSS-API.  Most of the mechanisms which
have been discussed within CAT require fairly substantial infrastructures to
be deployed in order to operate. Simpler technologies (e.g.,
challenge-response mechanisms, some of which have been designed for use at
the SASL layer), have been considered easier to apply but may not offer the
same range of security services or resist the same range of attacks. If such
mechanisms were to be implemented under GSS, it could become possible to
port GSS caller applications to a broader range of environments.
Particularly given the fact that RFC-2478 now provides a Proposed Standard
means for negotiated mechanism selection, an important feature for framework
construction, a broadened range of mechanisms could serve a broadened range
of consumer applications and environments. 

I'd like to open a list discussion topic for the WG: what level of interest
exists within the CAT community in specifying and implementing one or more
lower-infrastructure mechanisms under the GSS interface?  Thanks in advance
for any comments. 

--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: Mike Eisler <[email-masked]>
Date: Mon, 21 Dec 1998 17:15:15 -0800 (PST)

> lower-infrastructure mechanisms under the GSS interface?  Thanks in advance

This interests me as long it is recognized that "lower-infrastructure"
most likely means lower quality of protection. 

One lower-infrastructure mechanism that I'd to see is one where the acceptor
has a public key certificate but the client does not (the typical scenario
when using a web browser to do e-commerce via SSL and HTTP). Instead, the
client (the initiator) would provide a password to authenticate itself to the
acceptor. This password could be encrypted with a session key encrypted with
server's public key, or something like the Digst Access Authentication scheme
of RFC 2069 could be used.

	-mre