Subject: RE: prot_ready and server subkeys

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 12 Sep 2003 13:41:37 -0700

Nicolas Williams wrote:
>> Now, perhaps we should just abandon the acceptor-asserts-sub-key
proposal.

Or abandon "prot_ready" as Sam suggested a few days back.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Friday, September 12, 2003 10:51 AM
To: Martin Rex
Cc: [email-masked]
Subject: Re: prot_ready and server subkeys

On Fri, Sep 12, 2003 at 07:32:37PM +0200, Martin Rex wrote:
> If you don't mind then I'll supply a memory dump of the birth
> of GSS_C_FLAG_PROT_READY and my take one the proposed approach.

Thanks!

[...]

> Nicolas Williams wrote:
> > There are two asymmetries to PROT_READY:

[...]

> >  - The second asymmetry relates to the availability of session keys
for
> >    both directions, or the availability of a temporary key for one
> >    direction.  Here one side may possess the necessary session key
> >    material to make per-msg tokens that can be processed by the
other
> >    side [when it becomes PROT_READY] while also lacking the
necessary
> >    session key material to process per-msg tokens from the other
side.
> 
> Most if not all gssapi mechanism need a full roundtrip communication
> to get hold of a session that can be used for message protection
> for a communication.  With Kerberos, this roundtrip is traditionally
> not performed among the actual communication peers, but between
> the initiator and the KDC during the first call to
gss_init_sec_context()
> (minus cached tickets) and that only works because the initiator must
> know a-priori whom it is going to talk to and it must supply
> that name as input to gss_init_sec_context().

Actually, there's more to it.  With rfc1964 the initiator can specify a
sub-session key and that is used for all per-msg tokens (modulo key
derivation) - the ticket's session key then is used only to protect the
authenticator in the AP-REQ.

But with the new mech we have a proposal to have the acceptor specify a
sub-session key in the AP-REP encpart that overrides the key requested
by the initiator.  So now we have two sub-session keys, one is selected
by the initiator which can be used for per-msg tokens, but only until
the acceptor's reply token is received, at which point only the
acceptor's sub-session key is to be used (modulo key-derivation).

So with this acceptor-asserts-sub-key proposal the acceptor would never,
ever make per-msg tokens with the initiator's proposed sub-key, but the
initiator could make some per-msg tokens with it's proposed sub-key
until the context establishment completes.

Which means that the initiator could be PROT_READY while
GSS_S_CONTINUE_NEEDED but only for making per-msg tokens, and it would
not be PROT_READY for processing per-msg tokens until the context
becomes fully established.

But, so what, right?  Do we care to deal with out-of-order delivery of
the acceptor's reply context token with respect to its subsequent
per-msg tokens?

What a mouthful.

Now, perhaps we should just abandon the acceptor-asserts-sub-key
proposal.

> 
> > 
> > Neither rfc2743 nor rfc2744 deal with either of these asymmetries in
> > sufficient detail or at all.  The first asymmetry is obvious and not
> > problematic.  The second asymmetry is not really a problem either
> > because GSS-API applications that use PROT_READY w/ partially
> > established contexts use it to make per-msg tokens prior to full
context
> > establishment but still intend to process incoming context tokens
prior
> > to processing incoming per-msg tokens - no, the RFCs don't say this,
but
> > it's hard to see how the authors could have intended otherwise.
> 
> Although gss_wrap() and gss_getmic() may become available before
> the security context is fully established, an application should
> not expect gss_unwrap() or gss_verifymic() to be usable before
> the local context establishment call has returned GSS_S_COMPLETE.
> It would be impossible for a gssapi mechanism "withdraw" the validity
> from a gss_unwrap() or gss_verifymic() call if a later security
> context establishment call failed.  I raised that issue on the
> CAT-IETF list on 01-May-1998 and got the following reply:

Exactly.  Thank you!

PROT_READY while GSS_S_CONTINUE_NEEDED has to mean "ready to make
per-msg tokens" and _may_ mean "ready to process per-msg tokens" _only_
when the other side is also PROT_READY  (which by which time should be
GSS_S_COMPLETE and the first side should become so after processing the
last context token).

>   John Linn wrote:
>   : Martin Rex wrote:
>   : : (2) use of incomplete security contexts for message
(un)protection
>   : :     due to the "prot_ready_state" indicator.
>   : :
>   : :     The current wording in both rfc2078 (section 1.2.7) says
that
>   : :     both: message protection and message UNprotection will
become
>   : :     available when prot_ready_state is returned by a context
>   : :     establishment call.
>   :
>   : True.  The existing 2078bis text states that TRUE prot_ready_state
is
>   : sufficient to enable usage not only of GSS_Wrap() and GSS_GetMIC()
but also
>   : of GSS_Unwrap() and GSS_VerifyMIC().
>   : 
>   : :     I'm somewhat uncomfortable with message UNprotection being
>   : :     available before the security context is successfully
>   : :     established.  Since we don't make any restrictions on the
>   : :     number of message protection calls an application can do
>   : :     at this stage, the application could theoretically exchange
>   : :     thousands of protected messages before completing completing
>   : :     security context establishment (or even skip context
establishment).
>   : :
>   : :     And what are the semantics when the security context
establishment
>   : :     fails after messages have been unprotected and processed?
It's
>   : :     already to late, the gssapi can not roll back application
actions
>   : :     based on the unprotected messages.
>   : 
>   : I'm not sure that I see this as a problem.  If the application
uses
>   : per-message unprotection upon TRUE prot_ready_state before
GSS_S_COMPLETE,
>   : it's doing so based on the information which is available at that
point;
>   : once returned, only mech_type (I believe) is liable to change upon
a later
>   : call in the context established sequence.  There's already a
warning that
>   : mutual authentication isn't guaranteed until GSS_S_COMPLETE, and
the
>   : anonymity service is a special case of its own; applications which
require
>   : services or information which aren't guaranteed until
GSS_S_COMPLETE are
>   : limited in their ability to exploit the prot_ready_state
optimization.

Sigh.

> As mentioned before, for rfc-1964 Kerberos this is a no-issue at
> the acceptor side, where before the call to gss_accept_sec_context()
> you wouldn't have a usable security context handle, and after
> the call you either have GSS_S_COMPLETE or a fatal error.

Right.  Not so the new mech with acceptor-asserted sub-session keys.

> > 
> > If I can find a citation for the need to process context tokens
before
> > processing per-msg tokens then the matter will be resolved without
> > further ambiguity, as such a requirement would mean that PROT_READY
w/
> > partially established contexts refers to the ability to make per-msg
> > tokens, rather than the ability to process them.  Unfortunately, I
can
> > find a counter example of such a citation: section 1.2.6, second
> > paragraph, second sentence "[callers] of the GSS-API ... may assume
> > that per-message protection ..."
> 
> 
> Well, *I* had asked for this ambiguity to be removed, but I didn't
insist.
> Personally, I'm still convinced that availability of message
UNprotection
> facilities before successful security context establishment is a bad
idea.

I think it's good idea, but only if application developers are warned of
the likely underlying trade-off.  PROT_READY is useful for avoiding an
additional round-trip but should not be used to protect sensitive data,
rather it should be used to protect application-level negotiation data.

E.g., see my proposal to move the rfc1964 checksum data out of the
AP-REQ and use a MIC to protect it, which is a use of PROT_READY, in a
way.

> 
> On the other issue about temporary keys:  I don't see a problem
> with that as long as it's clearly documented in the mechanism
> spec how it's supposed to work and doesn't break interoperability
> with the installed base of rfc-1964 (in case that it uses the same
> mechanism OID).

Right, the temp initiator sub-key is useful only for PROT_READY and its
temporary nature is where the trade-off comes in.

We won't break interop with rfc1964 (see the list archive for details).

Thanks,

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 12 Sep 2003 14:16:57 -0700

Martin Rex wrote:

>> What exactly is the motivation that the server should select
>> the subsession key?  I mean the recommendation for the initiator
>> to include the ticket's session key in the generation of the
>> subsession key should be sufficient.

You can think of multiple services running as the same principal (a
typical scenario is the "web-farms").

How do we prevent an adversary from taking the ticket and authenticator
pair to present to another service under the same principal?  Of course,
you can propose to assert a nonce into the sequence-number field, but
that also requires 1 1/2 round trips.  Distributed replay cache is not
cheap.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, September 12, 2003 1:05 PM
To: Nicolas Williams
Cc: [email-masked]; [email-masked]
Subject: Re: prot_ready and server subkeys

> authenticator in the AP-REQ.

The use of a subsession key ought to be a must.

The reason why the initiator includes a subsession key in the
authenticator is so that messages from an earlier communication
between the same two peers that were authenticated using the
same service ticket can not be inserted into the new communication.
If the session key of the ticket was used for protecting the
messages, this would be possible, because that session key would
be reused each time the ticket is reused.

Having the acceptor select a subsession key would preclude
1-way authentication and 2-way-with-PROT-READY authentication
unless one designs a key replacement.

What exactly is the motivation that the server should select
the subsession key?  I mean the recommendation for the initiator
to include the ticket's session key in the generation of the
subsession key should be sufficient.

Remember: no matter how good the quality of a subsession key
selected by the acceptor might be -- if you don't trust the
client you're lost anyway, because the acceptor can never
keep the client from deliberately leaking information through
every means it wants to.

-Martin