Subject: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Apr 2005 15:12:16 -0400

Today begins a Working Group Last Call on the working group
drafts:

 * draft-ietf-kitten-gssapi-prf-02.txt
 * draft-ietf-kitten-krb5-gssapi-prf-02.txt

There are known issues related to ID-Nits failures which will
be addressed at the end of the working group last call period
prior to submission to the IESG.

* draft-ietf-kitten-gssapi-prf-02.txt:

  - The IANA Considerations section is missing

  - The boilerplate must be updated to RFC 3978

  - The IPR disclosure must be in conformance with BCP 79.

* draft-ietf-kitten-krb5-gssapi-prf-02.txt:

  - The Introductions section is missing

  - The IANA Considerations section is missing

  - The boilerplate must be updated to RFC 3978

  - The IPR disclosure must be in conformance with BCP 79.

In addition, there are two issues which must be addressed
for there to be a successful completion of the WGLC.

(1) Language Bindings for Java and C# should be provided as part
    of draft-ietf-kitten-gssapi-prf

(2) Appropriate text specifying how the key usage for the Krb5
    PRF function will be determined must be added.

This WGLC will end on April 28, 2005.

Jeffrey Altman

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Apr 2005 16:56:25 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> (2) Appropriate text specifying how the key usage for the
    Jeffrey> Krb5 PRF function will be determined must be added.

RFc 3961 does not have keyusage for PRF.

Like Nico, I am concerned that our decision not to support prf_ready
for the krb5 prf may be problematic.  I am not advocating a change
now, but I'm concerned that the issue needs more consideration.
Clearly as one of the people asking for the PRF documents to move, I
should try to form a better opinion during the WGLC.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Apr 2005 16:16:27 -0500

> RFc 3961 does not have keyusage for PRF.

Note that the key usage in question is for the krb5 _mechanism_'s GSS
PRF, not the kcrypto PRF.  Given that, what impact does the lack of a
key usage for the kcrypto prf have, in your opinion, on this I-D?

> should try to form a better opinion during the WGLC.

Please do :)

Due to the fact that for the krb5 mechanism there is no such thing, on
the _acceptor_ side, as a partially established security context, the
only ways I can see to specify a PRF_READY feature would be to either
add an argument to GSS_PRF() so a pre-full-establishment key can be
used, OR a mechanism-specific extension.

I agree that, in light of the recently discussed complication created by
SPNEGO, it would be nice to have a PRF_READY feature.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Apr 2005 17:37:19 -0400

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

    Nicolas> On Thu, Apr 14, 2005 at 04:56:25PM -0400, Sam Hartman
    >>  RFc 3961 does not have keyusage for PRF.

    Nicolas> Note that the key usage in question is for the krb5
    Nicolas> _mechanism_'s GSS PRF, not the kcrypto PRF.  Given that,
    Nicolas> what impact does the lack of a key usage for the kcrypto
    Nicolas> prf have, in your opinion, on this I-D?

The kcrypto prf takes a protocol key not a derived key.  You don't
stick in a key usage number anywhere.  Your draft at least claims to
use the kcrypto prf in a prf+ construction.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Apr 2005 16:45:34 -0500

> use the kcrypto prf in a prf+ construction.

Sure, but my I-D can still mandate the use of a derived key, with some
key usage, to be used as input to the kcrypto prf.  Correct?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Apr 2005 17:51:22 -0400

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

    Nicolas> Sure, but my I-D can still mandate the use of a derived
    Nicolas> key, with some key usage, to be used as input to the
    Nicolas> kcrypto prf.  Correct?

Not as such.  You can mandate anything consistent with RFC 3961.  Go
look back at the kcrypto operations and make the types match.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Apr 2005 17:03:52 -0500

> look back at the kcrypto operations and make the types match.

Ok, well, given that the RFC3961 prf accepts only a protocol-key, then I
think we have no choice but to remove the words "and key usage X (TBD)"
from the end of the first paragraph of section 2 of
draft-ietf-kitten-krb5-gssapi-prf-02.txt.

Agreed?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Apr 2005 19:58:29 +0200 (MET DST)

> SPNEGO, it would be nice to have a PRF_READY feature.

Just a few observations:

- When SPNEGO is used, then the PROT_READY option in not available.

- Although gss-cfx does not specify a semi-established security context
  on the acceptor side for the Kerberos GSS-API mechanism,  there is 
  an installed base that implements acceptor-side semi-established
  security contexts (but I don't know whether it supports prot_ready...):

    Microsoft's user2user authentication, which has been available
    since original Windows 2000, and had once been documented in
     "draft-swift-win2k-krb-user2user-xx.txt"
    Strange--I can only find a -03 document in my archives from oct-2001,
    but no informational RFC nor a newer draft...

- How about adding a parameter which the **application** caller can use to
  indicate (on the acceptor side) whether it requires a key in sync
  with the initiators' prot_ready key, or whether it wants a key
  that is based on the fully established context (i.e. which could
  be a server-asserted subkey that was established later in the
  context establishment handshake).

  The key based on the fully established handshake should be the default.

  I think this would be a manageable burden for the application writers
  that want to do krypto on their own to know whether the initiator
  takes advantage of prot_ready or not.

  I even think it should be ok for the initiator to *insecurely* tell
  the acceptor which key/prf to expect (in case there really was
  ambiguity, which I think there isn't).  I do not consider the
  potential DoS a security problenm, that an active attacker may
  change an unprotected indicator which key/prf the acceptor should request.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Apr 2005 14:04:00 -0500

> - When SPNEGO is used, then the PROT_READY option in not available.

Right, but that's not the issue here.

See Sam's e-mail with the Subject: "Bill told us so: stackable mechs,
SPNEGO and substitutions."

Basically, in order to construct composite mechanisms which do not cause
problems with the new SPNEGO we need to be able to construct their
context tokens so that they are cryptographically protected from being
turned into context tokens of their underlying mechanisms.
Alternatively, where that can't be ensured, SPNEGO either MUST require
the MIC exchange or MUST NOT negotiate such composite mechanisms.

So, it'd be nice if we could consider building stackable pseudo-
mechanisms such that composite mechanisms made by stacking them over
Kerberos V have that cryptographic property mentioned above.

In the case of the Kerberos V mechanism we could do that, at least for
the reply token, if we had a PRF_READY feature for the GSS_PRF().  But
the current form of the GSS_PRF() function does not allow it.

>     but no informational RFC nor a newer draft...

But u2u is a different mechanism.

>   context establishment handshake).

That is one alternative.  I asked whether folks support this.

>   The key based on the fully established handshake should be the default.

Right.

>   takes advantage of prot_ready or not.

I agree.

>   change an unprotected indicator which key/prf the acceptor should request.

Probably so.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Apr 2005 17:49:36 -0500

>   - The IANA Considerations section is missing

I propose to add such a section claiming that "[this] document has no
IANA considerations."

>   - The IPR disclosure must be in conformance with BCP 79.

This will be done.

>   - The Introductions section is missing

I propose the following:

2.  Introduction

   This document specifies the Kerberos V GSS-API mechanism's pseudo-
   random funtion corresponding to [GSS-PRF].  The function is a "PRF+"
   style construction.

Alternatively I could rename the section currently named "Kerberos V GSS
Mechanism PRF" to "Introduction" :)

>   - The IANA Considerations section is missing

I propose to add such a section claiming that "[this] document has no
IANA considerations."

>   - The IPR disclosure must be in conformance with BCP 79.

This will be done.

>     of draft-ietf-kitten-gssapi-prf

I have sent Seema and Juan Carlos proposed text, which I include here

>     PRF function will be determined must be added.

Sam pointed out, indirectly, that no such key usage is needed.  I
proposed the removal of the text "and key usage X (TBD)" from the the
end of the first paragraph of section 2 of draft-ietf-kitten-krb5-
gssapi-prf.

> This WGLC will end on April 28, 2005.

Thanks.

I will make a proposal on the PRF_READY issue in a separate post.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Apr 2005 17:55:09 -0500

> (ignoring the PRF_READY thread):

Argh -- I forgot to paste that in.  Here:

How about, for Java:

   public byte[] prf(byte inBuf[], int outlen) throws GSSException

And for C#:

   public byte[] prf(byte inBuf[], int outlen)

?

Nico
--