Subject: Comments: draft-williams-gssapi-prf-00.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 1 Nov 2004 00:59:34 -0800

1) please describe why is undesirable to export the raw session
key/subkey directly: aka why not a gss_export_key() extension.

2) add an GSS_Session_key_info() extension to desribe the native key
size information and algorithms. The callers may want to know the true
attack resistance strength of the output when using this PRF extension.
A DES key of 8 bytes may only have 56 bits strength thus the algorithms
may matter.

3) add the desired PRF output length to GSS_Pseudo_random(), so that the
callers do not have to do further composition to get the desired output
length. We do not give application protocols a chance to create a
security weakness. A good example of bad key derivations is provided in
RFC 3766.

-- larry

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 1 Nov 2004 11:33:46 -0600

> key/subkey directly: aka why not a gss_export_key() extension.

You mean, in the I-D?  Explain why GSS_Pseudo_random() instead of
GSS_Get_key()?

Ok, it's easy enough.

> A DES key of 8 bytes may only have 56 bits strength thus the algorithms

This dos not belong in this I-D.

The GSS-API provides a [lame] facility for this: the Quality of
Protection values.

Unfortunately the GSS-API's QoP notion is badly broken for a number of
reasons.  I do not, however, count inability to compare QoPs as such a
reason, mostly because it's really, really hard to quantify the strength
of a given cryptosystem.

Is an AES-128 in CBC mode with HMAC-SHA-1 stronger than AES-128 in GCM
mode?  Who knows?  At such key lenghts performance may be a better way
to decide which cipher/mode to use.

The GSS-API provides no way to influence the QoP that will be negotiated
in a context token exchange, *that*, IMO, is a bigger deal.

This is all fodder for a separate I-D.  Let the GSS_Pseudo_random()
remain simple, so we can last-call it soon.

> security weakness. A good example of bad key derivations is provided in

This needs to be decided here.  I suggest that arguments pro and con be
posted and then we can have a consensus call on the matter unless we all
come to be obviously in agreement.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Nov 2004 16:27:12 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    >> 3) add the desired PRF output length to GSS_Pseudo_random(), so
    >> that the callers do not have to do further composition to get
    >> the desired output length. We do not give application protocols
    >> a chance to create a security weakness. A good example of bad
    >> key derivations is provided in RFC 3766.

    Nicolas> This needs to be decided here.  I suggest that arguments
    Nicolas> pro and con be posted and then we can have a consensus
    Nicolas> call on the matter unless we all come to be obviously in
    Nicolas> agreement.

pro: Makes it easier to design secure applications.

Unless there are strong con arguments I support this for the stated
reason.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Nov 2004 15:35:53 -0600

> Unless there are strong con arguments I support this for the stated

And what should specify the mechanism's PRF?  An update to the mech, or
an update to the mech _and_ kcrypto?

What should the PRF be?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Nov 2004 16:39:05 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> What should the PRF be?

Some sort of counter mode should be reasonable.  That will form a
valid PRF provided that you hold the length constant.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Nov 2004 15:40:48 -0600

> valid PRF provided that you hold the length constant.

Why not do that at the GSS layer, with a GSS_Pseudo_random_plus() that
uses GSS_Pseudo_random()?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Nov 2004 16:52:27 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Nov 02, 2004 at 04:39:05PM -0500, Sam Hartman
    >>  Some sort of counter mode should be reasonable.  That will
    >> form a valid PRF provided that you hold the length constant.

    Nicolas> Why not do that at the GSS layer, with a
    Nicolas> GSS_Pseudo_random_plus() that uses GSS_Pseudo_random()?

Why do you need both functions exposed at the GSS layer?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Nov 2004 15:56:18 -0600

> Why do you need both functions exposed at the GSS layer?

Only to simplify specification of the generic PRF+ in terms of
mechanisms' PRFs.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Nov 2004 17:55:55 -0500

> Why do you need both functions exposed at the GSS layer?

I think Nico is suggesting that GSS_Pseudo_random() be provided by the 
mechanism, while GSS_Pseudo_random_plus() is implemented in a 
mechanism-independent manner in terms of GSS_Pseudo_random().

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Nov 2004 17:09:10 -0600

> mechanism-independent manner in terms of GSS_Pseudo_random().

Yes, mostly to avoid any battles over the correct way to deliver a PRF+
for the Kerberos V mech: as an update to the mech, or as an update to
the mech and kcrypto.

Anyways, Sam convinces me that we can just update the mech and be done
and have the GSS-API just provide an interface to the mechs' PRF+
functions.

Larry seems to be proposing exactly as much, so I think we can consider
the matter settled, unless someone else has a different opinion.

Nico
--