Subject: prot_ready and server subkeys

From: [email-masked] (Sam Hartman)
Date: Fri, 5 Sep 2003 17:15:53 -0400 (EDT)

As an aside, I'm getting worried about the number of issues Nico and I
keep running into.  We seem to be digging through all the defects in
RFC 1964 and trying to fix them.  I think this is a good idea, but I'm
concerned that it may slow down the AES work, which is also
important.  Advice on how to balance this would be appreciated.

The current RFC 1964 does not speak to the prot_ready flag.  Should
the Kerberos mechanism support the prot_ready flag?

Also, what should happen if the server subkey field is filled in the
ap_rep token?

Note that if a server is allowed to assert a subkey, we can avoid the
need for a replay cache and thus the need for time synchronization for
some protocols.

However if we do this we cannot support prot_ready.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 15:27:53 -0700

> important.  Advice on how to balance this would be appreciated.

Heh.

> the Kerberos mechanism support the prot_ready flag?

I think it should.

> need for a replay cache and thus the need for time synchronization for

If the server asserts a subkey, the subkey should win and it should be
used for both directions.

Should we mandate server-sets-subkey?

Note:  Because clarifications doesn't specify the subkey negotiation
       the mech has to, which is unfortunate because we'll need to
       update the mech later to explain that the original text on
       subkey negotiation no longer applies when using Kerberos V
       extensions w/ PFS.

> However if we do this we cannot support prot_ready.

No, we can.  We just need a one-bit flag the per-msg tokens indicating
whether the token was made before the context was fully established.
And when an acceptor processes a per-msg token with this flag set the
acceptor then MUST check the AP-REQ token against a replay cache.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 17:07:42 -0700

> need for a replay cache and thus the need for time synchronization for

Note that we can forgo the replay cache when the server asserts a subkey
AND several constraints are met.  E.g., if a given acceptor principal is
used with non-mutual authentication or if it's used in non-GSS-API apps
(such as telnet, rsh, etc...) either w/o mutual auth or with mutual auth
but no server asserted subkey and/or w/o integrity/confidentiality
protection for the session, then that AP-REQs for that principal MUST
always be replay cached, even where the server asserts sub-keys.

This probably means that we just can't get rid of the replay cache in
1-round-trip Kerberos V mechanisms, even with PFS, at least for apps
that don't use the per-msg tokens (but how is the mech implementation to
know?)  The I-D should lay this out and say that acceptors MAY forego
the replay cache if configured to do so for specific principals.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 06 Sep 2003 13:05:46 -0400

> the replay cache if configured to do so for specific principals.

That sounds like asking for trouble.  People will turn off the replay cache 
because they don't understand what it's for, or because it leaves files 
lying around that they don't understand, or for any number of other 
reasons.  And system administrators won't read the I-D.

I don't know how to do this, but I'd feel much better if the application 
protocol could somehow signal that it doesn't need replay protection, so 
that this descision is left in the hands of application protocol designers 
rather than system administrators.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 6 Sep 2003 13:54:37 -0700

> rather than system administrators.

That's not enough.  SSHD couldn't know if rshd is using the same service
principal - it can only know that rshd might.

It may be that the only safe way to turn of the replay cache is where
the implementor knows it's ok.  And it's ok to turn off the replay cache
when a principal is used only by applications where the server asserts a
subkey and where the client must make further use of an established
context before getting anything useful done by the server.

For example, we know that we can turn off the rcache for nfs/* princs
because those are not used by any other non-RPCSEC_GSS application and
RPCSEC_GSS provides its own replay protection.  This is generally not
the case with host/* principals (but it might be, in some cases).

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sun, 07 Sep 2003 01:33:01 -0400

> principal - it can only know that rshd might.

Maybe this is an argument for someday defining a way to put
authorization-data into the authenticator saying that this
authenticator is for ssh.  (Oddly enough, if you allow specification
of specific parts of ssh in such authorization data, saying that an
authenticator is for ssh-userauth or for ssh-keyex, that would also
allow the old gssapi userauth mechanism to be secure against the
attacks we've recently become concerned about.  But I bet gssapi
doesn't give you any mechanism-independent way to set and check such
authorization data.)

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 6 Sep 2003 23:55:14 -0700

> doesn't give you any mechanism-independent way to set and check such

Yeah, this is tempting, but it won't work for the reason you point out.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Sep 2003 17:19:43 -0400

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

    >>  However if we do this we cannot support prot_ready.

    Nicolas> No, we can.  We just need a one-bit flag the per-msg
    Nicolas> tokens indicating whether the token was made before the
    Nicolas> context was fully established.  And when an acceptor
    Nicolas> processes a per-msg token with this flag set the acceptor
    Nicolas> then MUST check the AP-REQ token against a replay cache.

I think I had asked for a citation that this was correct behavior.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 20:26:55 -0700

> I think I had asked for a citation that this was correct behavior.

There isn't anything sufficiently specific, but there's a hint in
rfc2743.

There are two asymmetries to PROT_READY:

 - One side (initiator or acceptor) can become PROT_READY when the other
   side is not.  This is true even of the GSS-APIv1, before PROT_READY
   was introduced and should be obvious.

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

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.

Here, in the context of the new Kerberos V mech and acceptor-asserted
subkeys we are dealing with the second kind of asymmetry, so that the
initiator can make per-msg tokens prior to full context establishment
provided that it sets a flag in those per-msg tokens indicating the use
of the initial sub-key, but the acceptor always uses its subkey and
expects the initiator to do so as well once it has processed the last
context token.

As to the "hint" in rfc2743 that I mentioned, it is in section 1.2.7,
first paragraph, in the reference to possession of "the necessary
session key ..."  Another hint is in section 1.2.3, first paragraph,
second sentence "[these] optionally-selectable protection features are
distinct from replay detection and sequencing features applied to the
context establishment operation itself..."

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

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Sep 2003 19:32:37 +0200 (MET DST)

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.

PROT_READY was proposed by Bob Blakley (then IBM)
at the Summer IETF '95 in Stockholm for use with Kerberos.

It should be used for a simple request-reply communication
protected with Kerberos via GSS-API but mutually authenticated
-- no multiple roundtrips, no state on the server.

PROT_READY is a purely optional feature, however a few applications
may actually rely on it so watch out that you don't break any those
apps with an update of your Kerberos software that doesn't support
it anymore.

Actually, PROT_READY shouldn't be necessary at all for rfc-1964
Kerberos unidirectional authentication, since there is only a single
context level token sent from the initiator to the acceptor,
so gss_init_sec_context() returns GSS_S_COMPLETE on the initial call.

>    was introduced and should be obvious.

For PROT_READY to be available you need 2 things: the protocol must allow it,
and it must have been implemented in the mechanism that you use.

Since rfc-1964 Kerberos only has two types of authentications
  1-way = unidirectional/target-only authentication 
  2-way = mutual authentication 
there never was an question how the acceptor would have to
deal with it -- the initial call to gss_accept_sec_context()
either returned GSS_S_COMPLETE or a fatal error.  In both
situations it is clear what that means to piggy-backed protected
messages.

Personally, I think that PROT_READY is only necessary for apps that
want mutual authentication but must complete the communication in a
single round-trip so that the acceptor doesn't need to keep state
information.

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

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

  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.

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.

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

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

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Sep 2003 10:50:55 -0700

> of GSS_C_FLAG_PROT_READY and my take one the proposed approach.

Thanks!

[...]

> > There are two asymmetries to PROT_READY:

[...]

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

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

>   : limited in their ability to exploit the prot_ready_state optimization.

Sigh.

> the call you either have GSS_S_COMPLETE or a fatal error.

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

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

> with the installed base of rfc-1964 (in case that it uses the same

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: Sam Hartman <[email-masked]>
Date: Fri, 12 Sep 2003 14:14:27 -0400

I don't know of any implementations of Kerberos that actually support
prot_ready besides possibly Sun.

Martin, would you support a clarification to the GSSAPI spec that
allowed one side to be prot_ready and thus able to generate
per-message tokens but unable to process incoming per-message tokens
until the remaining context tokens had been processed?

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Sep 2003 22:05:12 +0200 (MET DST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Sep 2003 14:09:26 -0700

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

Yes, of course.

> unless one designs a key replacement.

For one-way authentication the server cannot and does not assert a
subkey so the initiator's proposed sub-key wins.

For two-way authentication w/ PROT_READY there would have to be key
replacement (and a single bit in the per-msg tokens to indicate which
key the initator was using).

> subsession key should be sufficient.

An iffy proposal that would have allowed the acceptor to forego the use
of a replay cache in a certain situations.  Of course, to safely avoid
the use of a replay cache in the general case we'd need a three-message
exchange (1 and 1/2 round-trips).

I'm leaning to discarding the acceptor-asserts-subkeys proposal but
allowing PROT_READY.  I do not want to abandon PROT_READY.

I also think we ought to have an option for a three-message exchange.
But I'm not sure how we could select the option on a per-context basis
other than with a different OID (or new req_flags, which may not be
generic) - but we could have a system-wide acceptor-side setting where
the acceptor requires a third message from the initiator so the acceptor
can forego the replay cache.

> keep the client from deliberately leaking information through

That was not the motivation (see above).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 13 Sep 2003 21:53:19 -0500

> allowing PROT_READY.  I do not want to abandon PROT_READY.

I forgot PFS.  With PFS there will definitely be two session keys if we
want PROT_READY support, one non-PFS key for PROT_READY, one PFS key for
post-context establishment use.

So we should clarify that PROT_READY may mean "ready to make per-msg
tokens, but not ready to process per-msg tokens."

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Sep 2003 23:46:57 +0200 (MET DST)

I'm sorry for not answering -- thanks for reminding me.

> until the remaining context tokens had been processed?

Short answer: yes, sort of.

Clarification?  Are you thinking of an GSS-APIv2 Update2 or BCP document?
Although I could probably contribute a substantial amount of gssapi
experience for a BCP document ... however I'm extremely short of
time and I'm not a particularly fast writer (I write C-code much
better and faster than documentation...).  The advantage of a BCP
would be that it doesn't need to preclude the behaviour, just
caution about the problems and implications, i.e. we could get
away with "rougher" consensus than for a normative change.

My argument is that a *portable* gssapi based application can not
rely on message unprotection facilities being available before the
security context is fully established, even for mechanisms that
support and indicate prot_ready before completion of the security
context establishment handshake, therefore a portable app shouldn't be
designed to require or actually use it -- even if there existed
gssapi mechanisms supporting it.
It's likely going to be implementation specific behaviour.

So it has always been my working assumption that unprotection
would not be af, and in my excerpt from the IETF-CAT discussion
at the beginning of this thread I even requested such a change to
become part of the GSS-API v2 standard.  However, as indicated by
John Linn's reply on my request I couldn't get consensus on such
behaviour (I didn't fight for it either). 

Didn't even Nico say that he liked this possibility?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Sep 2003 15:14:41 -0700

> Clarification?  Are you thinking of an GSS-APIv2 Update2 or BCP document?

Could the clarification come in the form of an RFC that updates rfc2743
but which does not obsolete rfc2743 and so does not have to copy all the
other text in rfc2743?

> away with "rougher" consensus than for a normative change.

I'm not sure a BCP would do since we're talking about a mechanism that
simply can't (not "shouldn't") un-prot (process) per-msg tokens before
full context establishment but is otherwise PROT_READY and can make
per-msg tokens - this violates the letter of rfc2743, but then, we seem
to agree that rfc2743 got this wrong...

> gssapi mechanisms supporting it.

Further, whatever document clarifies this should recommend that
PROT_READY be used only in conjunction with data that needs only
integrity protextion (i.e., is not secret) and mostly as an optimization
for application-layer negotiation (prot_ready allows for a one round-
trip optimization in such cases).

> It's likely going to be implementation specific behaviour.

Mechanism-specific.  Some implementations of a mechanism that supports
prot_ready may not, but the actual behaviour or range of behaviours
should be specified by the mechanism specs.

> behaviour (I didn't fight for it either). 

Yes, I agree: unprotection of messages should only happen after context
establishment.  This does not gut prot_ready - in fact, it makes it
implementable, and considering that prot_ready appears to have been
aimed at the Kerberos V mechanism(s) it really makes sense to fix it so
it can be implemented correctly [to spec] by the Kerberos V
mechanism(s).

> Didn't even Nico say that he liked this possibility?

Very much so.

My question is: what form should the document take?  (RFC2743
obsolescence should be avoided.)

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 26 Sep 2003 15:52:31 +0200 (MET DST)

> but which does not obsolete rfc2743 and so does not have to copy all the

Personally, I would really prefer a BCP, and I think that a BCP
should be perfectly sufficient.

> to agree that rfc2743 got this wrong...

I really don't see a problem here.  rfc-2743/rfc2744 may be underspecified,
but it doesn't require any particular behaviour, and IMHO it would be
perfectly ok if a mechanism spec (like rfc1964bis) mandates a very
specific behaviour, or that the exact behaviour remains implementation
defined in case the mechanism spec is/remains silent that issue.

> trip optimization in such cases).

I disagree, that would severly limit the usefulness of this feature.
When Bob Blackley (sp?) came up with the idea of PROT_READY, he
wanted it for use with Kerberos *with* both confidentiality *and*
mutual authentication.

Presuming that the applied confidentiality protection is secure,
the receipient would only be able to unprotect the information if
he was the legitimate/intended receipient.  Actually -- thinking about it
this comes close to a requirement that message unprotection only
works after successful security context establishment.

Neither an attacker nor an accidentally wrong acceptor should be
able to read the protected data.  PROT_READY was supposed to
cut down the number of roundtrips independent of the sensitivity
of the application data.

Remember, GSS-API has no security context requirements (flags), only context
feature requests -- and the acceptor doesn't even have that.
The GSS-API spec is very explicit that the gssapi mechanism should try
its best to establish a security context, and leave policy decisions
whether the resulting security context attributes (flags) are sufficient
entirely up to the application caller.

Because of this I would actually consider it a serious security problem
if either peer could unprotect prot-ready protected messages of the
opposite peer before the security context is successfully established
(because that is the only way that an application can be sure the
 communication is actually secure.)

> should be specified by the mechanism specs.

I disagree.

rfc2743/rfc2744 say prot_ready is an optional feature.
If a mechanism spec doesn't mandate availability and defines
the exact semantics, then it will definitely be implementation defined.
AFAIK rfc1964 doesn't mandate prot_ready.

> it can be implemented correctly [to spec] by the Kerberos V

I also find it extremely hard to think of a way to implement prot_ready
message unprotection before successful security context establishment
without either creating a security problem or violating GSS-APIs
principle that policy decisions on suitability of the attributes of
a security context should be entirely up to the application.

> obsolescence should be avoided.)

My personal preference would be a BCP.  I can think of a lot of
useful guidance for writers of portable gssapi-based applications,
however I don't think that should preclude applications that are
more tightly entangled with only one or a subset of gssapi mechanisms
and particular mechanism (or even implementation specific) features. 

I don't think that rfc2743 is so badly broken that it requires
a normative update.  Quite to the contrary, I think that GSS-API
is one of most mature specs (2nd after ISO-C on my list) that
I've seen during my life as a software engineer.

-Martin