Subject: Comments on draft-ietf-kitten-krb5-gssapi-prf-00.txt

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Dec 2004 06:17:40 -0500

I think all the Kerberos enctypes support at least 2**32 blocks,
although admittedly that's getting dangerous for DES.

I'd propose a four-byte length rather than a two-byte length.

I think the call to random-to-key and k-truncate are misplaced.
random-to-key is just wrong in the context of a PRF; you want random
strings not keys out.

You do need to truncate the output, but I don't think k-truncate is
all that well understood in this context.

I'd recommend explicitly saying that we truncate to the output length.

The text is not clear on which key is used.  Keep in mind that CFX
involves subkeys and the keying for RFC 1964 is kind of complicated.
You need to cover both cases.

I think that the security considerations text should explicitly call
out concerns with DES.

--Sam

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Dec 2004 12:25:45 -0600

> I'd propose a four-byte length rather than a two-byte length.

Ok.  There should, though, be a minimum output length that
implementations must support -- 2^16 octets seems like reasonable such
minimum, though perhaps a bit long.

> all that well understood in this context.

Woops, that is an editing mistake -- yes, that's no PRF+.  An editing
error, I think, from the earlier version that didn't have a PRF+.

The new PRF+:

k5-gss-prf+(K, S, L) = truncate(L, T1 || T2 || .. || Tn)

where Tn = pseudo-random-function(K, n || S)

and where pseudo-random-function() is the function defined in
draft-ietf-krb-wg-crypto.

> I'd recommend explicitly saying that we truncate to the output length.

See above.

> You need to cover both cases.

This gets at an issue brought up by Love: should there be a
GSS_C_PRF_READY?  Should PROT_READY apply to the PRF?

It's easier if we answer no, and no.

> I think that the security considerations text should explicitly call

Will do.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Dec 2004 16:23:47 -0500

> It's easier if we answer no, and no.

I think PROT_READY is something of a kludge, and will not be particularly 
sad if things stop supporting it.  In that vein, I don't think we need a 
GSS_C_PRF_READY.

As for the second question, I don't think it matters.  I'm having trouble 
imagining a mech which could report PROT_READY and not also be ready to run 
the PRF.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Dec 2004 15:40:39 -0600

> imagining a mech which could report PROT_READY and not also be ready to run 

The Kerberos V GSS mech's PRF could not be ready when the context is
PROT_READY *if* we specify the use of the acceptor's sub-session key as
the key for the PRF.

One way to define PROT_READY is thus: the key material for the context
has been exchanged/agreed upon, though it may not be authenticated until
the context is fully established.  By such a definition the Kerberos V
mechanism's contexts can't be PROT_READY and not also be fully
established.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Dec 2004 18:00:11 -0500

On Monday, December 13, 2004 15:40:39 -0600 Nicolas Williams 
<[email-masked]> wrote:

>> As for the second question, I don't think it matters.  I'm having
>> trouble  imagining a mech which could report PROT_READY and not also be
>> ready to run  the PRF.
>

Indeed, I stand corrected.

In which case, it simplifies things quite a lot if we specify that the PRF 
cannot be used until the context is fully established.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Dec 2004 17:14:45 -0600

> cannot be used until the context is fully established.

Yes, but for potential future mechanisms this could be a bad compromise.

Looking at: a) how prot_ready was added to the GSS-API and, b) the text in
RFC2744 about the flags output parameter of the GSS context
establishment/inquiry functions I do believe we could add
prf_ready/GSS_C_PRF_READY to the GSS-API.

But we could also add prf_ready/GSS_C_PRF_READY later, when it's
actually needed, the same way that prot_ready was added.

Anyways, this is an interesting excercise is figuring out what
PROT_READY really means.  Knowing what I know now, a) PROT_READY should
have meant and should mean, if we could figure out how to make it so,
that the key material for the context has been fully exchanged/agreed to
though not authenticated until the context is fully established.  But
that would mean taking out support for PROT_READY from CFX.  Fun.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2004 20:48:28 +0100 (MET)

> mechanism's contexts can't be PROT_READY and not also be fully

PROT_READY was meant to allow an authenticated communication
(i.e. context establishment plus application request reply)
with a single application-level message exchange.

So the (application level) request carries the initial context token
plus protected messages with the application request,
and the (application level) reply carries an optional reply context
token plus protected messages with the application reply.

This feature was specifically requested for use with rfc1964
Kerberos and both, unidirectional and mutual authentication
by IBM to protect communication with stateless servers without
having to change the architecture (the statelessness).

We discussed the acceptor-asserted subsession key before --
it is somewhat incompatible with generic PROT_READY facility,
and it is entirely incompatible with the target-only context
establishment exchange.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Dec 2004 14:54:55 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> We discussed the acceptor-asserted subsession key before
    Martin> -- it is somewhat incompatible with generic PROT_READY
    Martin> facility, and it is entirely incompatible with the
    Martin> target-only context establishment exchange.

What is this facility?  I'm missing or at least misplacing the
reference.

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2004 22:11:15 +0100 (MET)

> What is this facility?  I'm missing or at least misplacing the

What I meant is the following:

1) with the single token security context establishment that rfc1964
   uses for unidirectional authentication there is no place for
   the acceptor to assert a subsession key

2) With PROT_READY, it may be difficult (or impossible) for the
   acceptor to determine (at the gssapi level) at which point
   the initiator is in possesion of an acceptor-asserted subsession key,
   and should no longer be using the initiator-asserted subsession key
   for message protection.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2004 15:51:37 -0600

>    and should no longer be using the initiator-asserted subsession key

Yes, in CFX we had that problem.

This would all be fixed by settling for the semantic I mentioned
yesterday, that PROT_READY indicates that all key material has been
exchanged, while GSS_S_COMPLETE indicates that all key material has been
exchanged and authenticated and authentication is complete.

That would mean that Kerberos V contexts can never be PROT_READY and
also NOT fully established.

But we've already made the mistake of giving the new mechanism a
PROT_READY feature (and for this I must take blame).

Nico
--