Subject: Low-infrastructure mechanism(s) and token encapsulation

From: Michael Smith <[email-masked]>
Date: Thu, 25 Mar 1999 12:30:33 -0500

I should have thought of this earlier. 

I've been implementing a version of Digest Access
Authentication (for HTTP) as a GSS mechanism. After
the discussion of low-infrastructure mechanisms in 
Mineneapolis, I gave some thought to writing up 
an I-D for this. What soon became apparent, however,
was that my present approach was going to be in 
conflict with the requirement for encapsulation of 
the "first" context token. 

What I've been doing is treating the entire 
set of HTTP request headers as the context token:
I just hand these over to GSS_Accept_sec_context
en masse. In fact, since I've been using a prototype
Java GSS binding for this work, I've simply defined 
a flavor of the "accept" method which takes an object 
encapsulation of the request (specifically, an
HttpServletRequest). 

This kind of approach seems logical to me for
mechanisms which are tightly integrated with specific
application-level protocols (as DAA is with HTTP). 
But of course neither the HTTP request nor any 
of its headers comes across the wire encapsulated 
as per GSS. 

Several approaches seem possible: 

1: I could define the "initial" token for context 
establishment as null, and not give the context the 
HTTP headers until a later stage (an unwrap or 
verify_MIC call, for example). 

2:  I could define some sub-component of the 
Authentication: header (e.g. the nonce) as the 
initial token, and make sure that this was 
appropriately encapsulated when it was issued; 
this would require that the code that originated 
the challenge was coordinated with the code 
that verifies the request, an annoying requirement. 
Alternatively, I could encapsulate it after 
extracting it from the header but before handing 
it to Accept_sec_context (ugh). 

3: We could add some language to the spec loosening 
the requirement for encapsulation in some cases. 
E.g., in section 3.1, after the sentence "Use of this 
format is required for initial context establishment 
tokens of Internet standards-track GSS-API mechanisms; 
use in non-initial tokens is optional," we could add 
a parenthetical escape clause along these lines: 
"(The requirement for encapsulation of the initial 
token may be waived for mechanisms which are so 
closely integrated with the application protocol 
that there is no ambiguity as to the mechanism to be 
used.)"  

I invoke the collective wisdom of the list: what's 
the best approach? Are other solutions possible? 

--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]