Subject: Re: low-infrastructure GSS mechanisms?

From: Michael Smith <[email-masked]>
Date: Tue, 22 Dec 1998 00:28:50 -0500

At 03:40 PM 12/21/98 -0500, "Linn, John" <[email-masked]> wrote:
>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.

Here at TIAA-CREF, we've implemented a flavor of the DAA challenge-response
mechanism specified for HTTP, under GSS -- well, sort of. We've done it 
in Java, and of course the Java binding of GSS is still under discussion. 
There's some info on our work at <http://www.panix.com/~jlefevre/GSS>.
This site concentrates on the Java-GSS aspect, but if there's any interest
in the mapping of DAA functionality to GSS semantics, I'll post a bit more
information in a day or two. -- Yuletide craziness, you understand. 

--Michael Smith
  [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: Tue, 22 Dec 1998 18:07:29 -0500

Yesterday I promised a bit more detail 
about our use of the HTTP DAA mechanism 
under GSS (or, at least, our Java flavor 
of it). 

A little Java program that illustrates
how we use this can be found at 
<http://www.panix.com/~jlefevre/GSS/org/tiaa_cref/pseudo.java>.
This should be read in conjunction with the javadoc 
for our GSS Java binding, 
<http://www.panix.com/~jlefevre/GSS>. 

In a nutshell: the mechanism is intended to be 
used by reverse proxies and/or endpoint application
Web servers, which receive an HTTP request; this is 
either authenticated by DAA, or not. If not, then 
the attempt to establish a security context 
returns CONTINUE_NEEDED and a challenge, which 
are then sent back to the requester. If the request
arrived with authentication information, the 
context-establishment call returns COMPLETE and 
'unwrap' can then be called on it. 

An interesting wrinkle is that this process can 
disgorge a RACF passticket for a subsequent 
mainframe request, using the derived-credential 
output of the context object.

The context-establishment and unwrap methods of 
the context will accept either a byte[] or a 
servlet-request object as tokens. 

Don't ask how an HTTP request is represented 
as a byte[] -- it's ugly, ugly. 

The actual mechanism code under the GSS-API 
makes a CORBA call to an "authentication server"
in order to check the correctness of the challenge
response (and, for that matter, in order to get a 
challenge), as well as to get the RACF passticket. 
If anyone is interested in this gross anatomy, 
let me know and I'll describe it at greater 
length. The IDL for the CORBA objects is at 
<http://www.panix.com/~jlefevre/GSS/org/tiaa_cref/DCAAF1_0.idl>.

Anybody who wants to browse the source is welcome to 
do so. Just add the obvious pathname for the source 
module of interest to the URL base 
<http://www.panix.com/~jlefevre/GSS/>. Warning:
it's still fairly brutish. This is a kind of 
proto-prototype. 

Comments and criticisms are most eagerly welcomed. 

--Michael Smith
  [email-masked]

---

From: Paul Leach <[email-masked]>
Date: Tue, 29 Dec 1998 17:24:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 29, 1998 5:20 PM
> To: Paul Leach
> 
>      Why just an informational RFC and not in the standards track? 
> 

It may be standards track; I'm not sure about that it was informational. I
am not one of the SASL developers, so I wasn't at the lunch. If I had to
guess, it is informational, and because most APIs done in an IETF context
have been informational.

Paul