Re: Adding a PRF to GSSAPI V3

 > That might be useful for those who want to use gssapi for authenication
 > but do the actual crypto on their own.

Just wanted to mention that when we were looking at implementing a
GSSAPI-based Web Services SecureConversation, we wanted to do just
this - GSSAPI tokens for the authentication, generate a session key
and then do standard WS-Security after that (basically to leverage
existing GSSAPI libraries in WS).

So, this sounds useful.

Von

Martin Rex writes (21:56 August 10, 2004):
 > Sam Hartman wrote:
 > > 
 > > Hi.  Larry, Niico and I would support the idea of adding some sort of
 > > PRF to the  GSSAPI.  
 > > 
 > > The intent of this would be that you have gss_prf that takes a context
 > > and some goop as input and returns some psuedo-random goop as output.
 > > The output would be constant for a given context and given input goop.
 > > This would presumably be a optional feature of GSSAPI.
 > 
 > You mean cryptographically strong pseudo-random goop as output --
 > similar to SSL/TLS deriving session-keys from a shared master secret?
 > 
 > That might be useful for those who want to use gssapi for authenication
 > but do the actual crypto on their own.
 > 
 > Having this as an optional extension should be OK.
 > 
 > There may be technical and policital reasons why one mechanism
 > or another will not adopt this functionality.
 >  
 > The political reasons may be that a gssapi mechanism should be
 > authentication only or authentication plus integrity but no confidentiality
 > (this was how DCE implemented the former US crypto export regulations).
 > Providing cryptographically strong shared secrets to the communication
 > peers of an established security context was incompatible with
 > that regulation.
 > 
 > Technical reasons may be that the gssapi mechanism provides authentication
 > only and no means to establish a cryptographically strong shared secret
 > between the communication peers during authentication which could be
 > used as a master secret.  Simple challenge-response schemes such
 > as Microsoft's NTLM authentication come to mind.  Or authentication
 > based on DSA-certificates.
 > 
 > -Martin
 > -++**==--++**==--++**==--++**==--++**==--++**==--++**==
 > 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 protected]
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 protected]