Subject: Adding a PRF to GSSAPI V3

From: [email-masked] (Sam Hartman)
Date: Thu, 5 Aug 2004 16:52:45 -0400 (EDT)

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.

If the list believes that this would be a good idea, I request any
changes that are necessary be made to the proposed charter.

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: "Douglas E. Engert" <[email-masked]>
Date: Thu, 05 Aug 2004 16:16:06 -0500

> changes that are necessary be made to the proposed charter.

Great idea.

--

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

---

From: Love <[email-masked]>
Date: Tue, 10 Aug 2004 17:38:41 +0200

> changes that are necessary be made to the proposed charter.

I find this a good idea as is would be used for the equallent of channel
bindings for layer on top of gssapi.

What was your intended usage for it ?

Love

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2004 13:21:51 -0400

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> I find this a good idea as is would be used for the
    Love> equallent of channel bindings for layer on top of gssapi.

    Love> What was your intended usage for it ?

It could be useful for an EAP GSS mechanism.  IT could make the ssh
key exchange draft more efficient for mechanisms with PFS support.  It
could be useful for things like ipsec that really want their own
crypto.

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Aug 2004 21:56:32 +0200 (MET DST)

> 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

---

From: Von Welch <[email-masked]>
Date: Tue, 10 Aug 2004 15:14:44 -0500

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 01:56:41 -0500

> changes that are necessary be made to the proposed charter.

I particularly like the ease with which this extension can be defined,
both generically and for the Kerberos V mechanism specifically.

Cheers,

Nico