Re: Working Group Last Call:

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Fri, Apr 15, 2005 at 07:58:29PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > 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.
> 
> Just a few observations:
> 
> - 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.

> - 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...

But u2u is a different mechanism.

> - 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).

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

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

Right.

>   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 agree.

>   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.

Probably so.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten