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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 31 Oct 2003 09:06:29 -0800

Martin Rex wrote:
>> Could you please address the issue of unidirectional one-token
security

>> context establishment (which is purely at the discretion of the
initiator
>> in rfc1964).

In that case, the acceptor won't have a chance to assert a subkey and it
is allowed.

Note in the last IETF interim meeting, we decided not to discuss how to
negotiate acceptor-asserted-subkey and
acceptor-enforced-subkey-without-replay-cache in the CFX draft, and
leave those to the extensions or other future drafts. Unfortunately this
was not mentioned in the meeting minutes.

Does this make sense now?

Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, October 31, 2003 4:03 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

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: Nicolas Williams <[email-masked]>
Date: Fri, 31 Oct 2003 09:42:06 -0800

> Does this make sense now?

Yes, we don't want to specify the conditions under which a 1-round-trip
Kerberos mech context token exchange can be used with no replay cache -
the reason is that it really depends on the applications, and the
mechanism cannot know what applications are using it (or their
characteristics), except through knowledge of target name <-> app
associations.  For this reason it strikes me as rather dangerous to say
much in the CFX I-D about this.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 31 Oct 2003 13:08:12 -0500

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

    >> Does this make sense now?

    Nicolas> Yes, we don't want to specify the conditions under which a 1-round-trip
    Nicolas> Kerberos mech context token exchange can be used with no replay cache -
    Nicolas> the reason is that it really depends on the applications, and the
    Nicolas> mechanism cannot know what applications are using it (or their
    Nicolas> characteristics), except through knowledge of target name <-> app
    Nicolas> associations.  For this reason it strikes me as rather dangerous to say
    Nicolas> much in the CFX I-D about this.

Agreed.  However:

1) We need client MUST use acceptor-subkey to eventually implement
   such an extension or to configure current applications in that
   manner when appropriate.

2) We want the implementation flexibility to avoid the replay cache
    for NFS and certain other applications now.

3) As such, we may need to add enough text to justify the MUST as a
   security/interop issue.

For the most part, enforcing such a MUST is impossible.  It's possible
for protocols in which the client proves knowledge of some message
sent by the server for the server to know that the client has seen the
subkey.  I do not believe building that sort of complexity into an
implementation is appropriate, so I believe that it should remain a
MUST but not be a MUST that we can check without examining client
code.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 31 Oct 2003 10:12:20 -0800

> MUST but not be a MUST that we can check without examining client

Agreed.  Just because this can't be enforced [without knowledge of the
application protocols] doesn't mean that we can't say "MUST."

"MUST" makes the replay cache optimization possible because initiator
implementors will [presumably] follow the spec and implement the "MUST."

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 31 Oct 2003 19:29:07 +0100 (MET)

> much in the CFX I-D about this.

Sorry, but I don't understand.

1st, I was refering to a one-way single token security context establishment,
not a round-trip one as you say above.

If one-way single token security context establishment as defined by
rfc-1964 is to be permitted with CFX as well, then a server-side
replay cache is a MUST.

"conditions under which a one-way single token security context establishment
 can be used with no replay cache" would be a serious violation of
the GSS-API architecture and is definitely a MUST NOT for the rfc-1964
defined enctypes and scenarios.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 31 Oct 2003 10:29:49 -0800

> not a round-trip one as you say above.

I was responding to Larry's comment, not yours.

> rfc-1964 is to be permitted with CFX as well, then a server-side

Did I argue otherwise?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 31 Oct 2003 13:49:57 -0500

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

    Martin> Sorry, but I don't understand.

    Martin> 1st, I was refering to a one-way single token security context establishment,
    Martin> not a round-trip one as you say above.

I just got off the phone with Nico.  We both agree that in the
unidirectional round-trip case, the server never asserts a subk ey, so
the situation never comes up.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 31 Oct 2003 10:52:59 -0800

> implementors will [presumably] follow the spec and implement the "MUST."

I'd like to clarifiy a bit more.  For RPCSEC_GSS (one of the
applications I most care about) the acceptor-asserted subkey actually
doesn't make the replay cache optional - the replay cache is already not
necessary for RPCSEC_GSS with rfc1964, with certain provisions.

So, whether the use of acceptor-asserted subkeys [in the mutual auth
case, of course] is a "MUST" or "SHOULD" is not terribly important to
me.

In general I'd much rather prefer to have a 1 1/2 round-trip option for
the new mechanism.  I'd also like to have a way for the acceptor to
require the use of that option, but, unfortunately there's no req_flags
input parameter for GSS_Accept_sec_context(), and, in any case,
req_flags should be generic, not mechanism-specific.  We still have to
support a 1-round-trip default for mutual auth and 1/2 round-trip for
non-mutual auth.

Perhaps Martin can show us a way to generically negotiate the use of a
1 1/2 round-trip option (or, to put it more generally, an option to not
require replay caches on the acceptor side).  That would be ideal.

Cheers,

Nico
--