Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

From: Martin Rex <[email-masked]>
Date: Fri, 31 Oct 2003 13:03:09 +0100 (MET)

Liqiang wrote:
> 
> Nicolas Williams wrote:
> >> It is too late to reject the context, but the acceptor could reject
> all
> >> per-msg tokens that don't use the acceptor asserted subkey.  I
> mis-wrote.
> 
> When the initiator says "prot_ready", it can not be authoritative,
> because the authentication/context-establishment may eventually fail.
> With this extension, it goes one step further, namely the
> context-establishment may succeed, but message protection may fail.
> This might be obvious, but I want to spell it out here to make sure such
> behavior is understood and acceptable.

Could you please address the issue of unidirectional one-token security
context establishment (which is purely at the discretion of the initiator
in rfc1964).

If you want to entirely prohibit one-token security context establishments
and prot_ready then spell it out in the CFX spec.  The gssapi mechanism
at the acceptor side MUST NOT fail security context establishment because
it doesn't like some of the attributes, that would be a clear violation
of the GSS-API architecture where both peers gssapi mechanism should
do its best to establish a security context even if the attributes
of this context does not fully match the **APPLICATION'S** desires,
but it is completely up to the application to make such a decision.

You will have to design the CFX mechanism in such a fashion that it
works correctly within the GSS-API architecture, and if you want
the acceptor to be able to modify the initiators context establishment
request then you will need a negotiation and will have to prohibit
one-token security context establishments and prot_ready.

Both of these characteristics were regarded as useful by at least
some users of rfc-1964 (the original proposal for prot_ready came
from IBMs development), so such a design choice may make CFX
unattractive for some consumers and entirely unusable for specific
uses.

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 30 Oct 2003 17:00:27 -0800

all
mis-wrote.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 1:40 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; Jeffrey Hutzelman; Ken Raeburn; [email-masked];
Douglas E. Engert
Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

On Thu, Oct 30, 2003 at 01:39:18PM -0800, Liqiang(Larry) Zhu wrote:
> Nicolas Williams wrote:
> >> If the initiator uses prot_ready-before-complete the acceptor MUST
> use a 
> >> replay cache or reject the context, else the acceptor MAY forego
the
> use 
> >> of a replay cache under very special circumstances.
> 
> It might be too late to reject the context (imagine
> gss_accept_sec_context with acceptor-asserted-subkey succeeds and then
> you receive a message protected with initiator-asserted-subkey because
> of prot_ready support on the initiator side).  

It is too late to reject the context, but the acceptor could reject all
per-msg tokens that don't use the acceptor asserted subkey.  I
mis-wrote.

> The acceptor can reject all messages that are not flagged as
> acceptor-subkey (in other words, protected with
> acceptor-asserted-subkey).  This way we can add back the "MUST" and it
> is also enforceable (granted it does not have to).  What do you think?

Yes.  Of course, pure GSS-API acceptor applications can't ask for such
behaviour, however, the mechanism can be configured to behave that way
for certain acceptor principals (e.g., nfs@*).

Cheers,

Nico
--