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

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 18:04:52 -0500

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

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

    Martin> That would make it a FUBAR gssapi mechanism.

Why?  How would it violate the GSSAPI specification?
-

You keep making assertions--for example your claim about what it means
to re-use an OID and this claim here--that you do not adequately
support.  PLease actually communicate with the rest of the working
group and explain what you mean and why you believe your statements
are true.  We all know you have a lot of GSSAPI experience and would
like to get your input, but well-reasoned arguments will be more
useful to everyone involved than one-sentence assertions.

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Oct 2003 23:55:11 +0100 (MET)

> per-msg tokens that don't use the acceptor asserted subkey.  I mis-wrote.

That would make it a FUBAR gssapi mechanism.

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

You're trying to stuff to much "policy"-type decisions into the gssapi
mechanism.  That's not where those decisions belong in the gssapi
architecture.

The application is the one to decide not to use a security context that doesn't
have the attributes it desires, however to know about an acceptor-asserted
subkey the application would need some meta-knowledge about the underlying
gssapi mechanism exceeding the portable GSS-API spec.

Some of the stuff that people want to do are simply not compatible
with rfc-1964 and its mechanism OID.  You should clearly seperate
the CFX enhancements that are FULLY backwards compatible with
rfc-1964 from the stuff that is NOT, and define a new mechanism
and mechanism OID for that incompatible stuff.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 13:39:37 -0800

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

Cheers,

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 30 Oct 2003 13:39:18 -0800

use a 
use 

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 1:27 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:18:51PM -0800, Liqiang(Larry) Zhu wrote:
> Sam Hartman wrote:
> >> I actually think it is required for security; I agree it is not
> >> required for interoperability.
> 
> The acceptor MUST insist on the acceptor-asserted-subkey (the acceptor
> knows if there is replay cache), but the initiator might already send
> out messages protected with the initiator-subkey at that point. Thus I
> do not think we can enforce it in a meaningful way. I have updated -03
> with "SHOULD" instead.

Seems reasonable and is necessary if we're to support prot_ready.

>                         I do not think the acceptor-asserted subkey
> works well prot_ready. One possible solution is to use a different OID
> for the acceptor-asserted subkey that will also turn off prot_ready
> support for the initiator. 

I disagree with this.  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.

I don't see any harm in the initiator being able to force the acceptor
to use a replay cache; even w/o prot_ready some (many? most?) rfc1964
acceptors have to use a replay cache anyways.

Cheers,

Nico
--