Subject: [Ietf-krb-wg] FYI: New draft for GSS pre-authentication submitted

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 03 May 2011 13:40:07 +0200

Dear all,

We have submitted a draft proposing a new pre-authentication mechanism 
for Kerberos based on the GSS-API. The abstract of the document is the 
following:

    This document describes a pre-authentication mechanism for Kerberos
    based on the Generic Security Service Application Program Interface
    (GSS-API), which allows a Key Distribution Center (KDC) to
    authenticate clients by using any GSS mechanism.

You can read the document and track its evolution here:
http://tools.ietf.org/html/draft-gss-preauth

Best regards,
Alejandro

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 13:47:11 -0500

A few comments:

a) Is this PA a FAST factor?  I can't quite tell, but it seems very
likely that this is your intention.  If so, then disregard the
following comments.  If not, why not, and if you insist, then check
out the following comments :)

b) Regarding the server-side security context handle and the use of
PA-FX-COOKIE for this... you'll want to call gss_export_sec_context(),
encrypt the result with a KDC-local secret key, slap on a header (to
identify the KDC/key) and use _that_ as the cookie.  If the local
GSS-API implementation does not allow exporting of partially
established security contexts then you'll need to send some cookie
(but NOT just the actual gss_ctx_id_t value!  you must at least MAC it
with a local secret key) to the client and you'll need to process any
reply from the client in the same process, and you'll need a way to
delete old, abandoned, partially established security contexts.

c) You should make use of the GSS channel binding facility to protect
all cleartext in KDC-REQ-BODY, and preferably any other PA data
besides the GSS PA data.  Note that this has state-keeping issues, so
instead of using the KDC-REQ-BODY, use a hash of it and make sure that
this hash is added to the state cookie (and covered by a MAC in the
cookie!).  Of course, a hash has hash agility issues...
Alternatively, if you don't want to use the channel binding input of
the GSS-API, you could send a MIC of such a hash along with the
client's final context token to achieve the same effect.  (And, if for
future extensions related to Kerberos KDC  over TLS messaging, you'll
want to be able to bind in the TLS channel bindings, but let's leave
this for later.)

d) You should use a MIC token in the final KDC->client reply to
protect all cleartext in the KDC-REP, except, of course, for the GSS
PA data.

BTW, I really appreciate this work.  I think it will be quite useful.  Thanks,

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 May 2011 15:06:14 -0400

On Tue, 2011-05-03 at 14:47 -0400, Nico Williams wrote:
> identify the KDC/key) and use _that_ as the cookie.

I'll echo this; if statelessness is achieved by the externalizing the
server-side context into the cookie, the cookie must be protected
against inspection and modification by the client.  You should also
think about attacks where cookies are replayed from unrelated exchanges.
I think that may have been what Nico was getting at with point (c).

>   If the local

That amounts to keeping state in the KDC, which may be undesirable.
Another approach is to store the previous initiator and acceptor tokens
in the cookie and reprocess them; that obviously doesn't scale well for
long exchanges, and might run afoul of replay cache-type protections.

> BTW, I really appreciate this work.  I think it will be quite useful.  Thanks,

I'm kind of curious what some envisioned deployment scenarios are.

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 14:41:19 -0500

> I think that may have been what Nico was getting at with point (c).

I wasn't, actually, but that's a good point.  Any partial security
context export functionality ought to protect against replays OR be
protected against replays by the application that uses such
functionality.  It's much better to require that the mechanism provide
the replay protection.  For a challenge-response mechanism (or any
mechanism with "DCE style" semantics) this is a non-issue.  For a
mechanism like RFC4121 that uses replay  caches that's also not an
issue (as long as the rcaches are shared in the case of shared cluster
keys, say).

> That amounts to keeping state in the KDC, which may be undesirable.

Yeah, but if you can't do partial sec context export then you have no choice.

> long exchanges, and might run afoul of replay cache-type protections.

No, that might not work for a mechanism like GSS-EAP, and it violates
the GSS abstraction.

> I'm kind of curious what some envisioned deployment scenarios are.

Well, consider ABFAB WG's mechanism...  In any case, the use case is
the same as in all other framework bridges: so you can use credentials
infrastructures that already exist.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 May 2011 16:20:10 -0400

On Tue, 2011-05-03 at 15:41 -0400, Nico Williams wrote:
> mechanism with "DCE style" semantics) this is a non-issue.

A challenge-response type mechanism protects against replays because the
acceptor knows that the challenge is fresh.  If the client has the
ability to replay an old exported partial security context and get the
acceptor to import it, the freshness guarantee disappears.

Binding the cookie contents to the armor key might be sufficient
protection.

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 15:22:48 -0500

> Binding the cookie contents to the armor key might be sufficient

Right, you're correct, the fact that the sec context token exchange
protects against replays does not mean that exported sec context
tokens are also protected.  This requires a replay cache, effectively.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Josh Howlett <[email-masked]>
Date: Tue, 3 May 2011 20:27:28 +0000

>infrastructures that already exist.

As it happens, one of the things we've discussed is using the ABFAB
mechanism within this (i.e., GSS EAP over GSS pre-auth).

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 May 2011 23:44:39 +0200 (MEST)

Nico Williams wrote:
> > acceptor knows that the challenge is fresh. Â If the client has the

There certainly is no such thing as a "replay protection" on
exported security context tokens in GSS-API.

And the gibberish in the spec about "encryption of the exported context
token" is at least midly confusing, because the only place where this
could make any sense is with GSS-API mechanisms that live within
the TCB and want to remain stateless about exported security contexts.

Encrypting the exported security context token does not make any
sense in architectures where the gssapi implementation is a mere
service library that lives entirely in the process space of the app
along with all of the crypto keys.  Encrypting an exported security
context token in such environments will primarily penalize application
callers that have a multi-process server architecture for passing
around the security context between processes.

An exported security context token is not guaranteed to be portable
or meaningful beyound the current machine and even accross different
revisions of the same gssapi mechanism implementation even on the same host.

If you really want to externalize security context state for the purpose
of creating a "session cookie" that can be off-loaded to the client
to facilitate a stateless server, you should really define _new_ gss-api
functions for that particular purpose.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 17:26:13 -0500

> exported security context tokens in GSS-API.

We know.  You keep reminding us that the v2u1 API doesn't even allow
for exporting partially established security contexts.  That's all
irrelevant here because any KDC using this will have to support such
things, whether you like it or not.  For a number of reasons we
_really_ _badly_ need partial security context export, and many of us
believe there's no fundamental reason why it couldn't work (in the
worst case by actually keeping open state on the acceptor and
outputting a reference that can be used to obtain access to it again,
probably via IPC).  Also, see below.

> the TCB and want to remain stateless about exported security contexts.

It's not gibberish.  It's akin to what TLS with stateless session
resumption does, and that's NOT gibberish either.

> to facilitate a stateless server, you should really define _new_ gss-api

Finally I can see that you understand what we're trying to do.

> functions for that particular purpose.

Whether we have to add a new function or not is irrelevant to the
protocol issues that we're trying to work out.

I don't think we need a new function anyways.  What backwards
compatibility issues might arise from applying
gss_export_sec_context() to a partially established security context?
Please explain in detail.

(I don't think any arise, certainly not for the app, which would get
an error if either the mechglue or the mechanism don't support this,
and not for the mechanism either, if it doesn't support it.  Worst
case scenario the mechanism deliberately segfaults the caller, but I
given the text of RFC 2743 and 2744 I think that'd be taking too much
liberty on the part of the mechanism).

Nico

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 May 2011 20:27:24 -0400

> Please explain in detail.

It could produce a host-specific answer, which wouldn't work if the
cookie is presented to a different KDC.

(Using an identifier for a saved context also fails in a multi-KDC
scenario.)

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 May 2011 04:12:36 +0200 (MEST)

Nico Williams wrote:
> >> tokens are also protected. Â This requires a replay cache, effectively.
> >
> for exporting partially established security contexts.

First of all, the purpose of the GSS-API v2 call
gss_export_sec_context() and gss_import_sec_context() is clearly
defined and limited to interprocess context transfer within a single host.

See rfc-2743  1.2.10: Interprocess Context Transfer

  http://tools.ietf.org/html/rfc2743#page-28

There are a number of requirements imposed by the GSS-API architecture
through the design of the context establishment loop that will, in
general, preclude the transferability of a partially established
security context.

A fully established gssapi security context only needs "traffic keys",
and no more access to credentials, similar to a cached TLS session
or a TLS session cookie (unless it follows the braindead design
of SPKM (rfc-2025) to use digital signatures with longterm credentials
for message integrity protection services).

At what point during the context establishment loop a gssapi mechanism
accesses credential handles supplied to the context establishment
iterator function is undefined at the GSS-API level.
The Caller is required to supply the exact same credentials handle on
_ALL_ iteration calls during context establishment -- something that cannot
be done for a partially established security context (unless maybe,
when the caller provides GSS_C_NO_CRED instead).

In general, the access to a credential may be extremely limited --
like when it is on a hardware token.  With hardware tokens and HSMs
access to the credential must usually be serialized (AFAIK that is
a design restriction for the PC/SC smart card interface on Microsoft
Windows platforms, and may similarly apply to hardware tokens and HSMs
accessed through PKCS#11 on other platforms).

The requirement to supply the exact same parameter on all iteration
calls during context establishment applies to quite a number of function
parameters of the context establishment iterators:

gss_init_sec_context():
    inputs:  target_name, cred, mech, req_flags, chan_bindings, time_req
    outputs: actual_mech, ret_flags, time_rec

gss_accept_sec_context():
   inputs:   cred, chan_bindings
   outputs:  src_name, acutal_mech, ret_flags, time_rec, deleg_cred

Which is why RFC2743 says (bottom of page 59):
   http://tools.ietf.org/html/rfc2743#page-59

                                                                   The
   GSS_Export_sec_context() operation is defined for use only with
   security contexts which are fully and successfully established (i.e.,
   those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
   have returned GSS_S_COMPLETE major_status).

and later

   The internal representation contained within the interprocess token
   is an implementation-defined local matter.  Interprocess tokens
   cannot be assumed to be transferable across different GSS-API
   implementations.

An interprocess context token may not be transferable to a different
machine (same OS&-Version, same CPU -- or different OS & different CPU
byte order).  Acutally, it might _not_ be transferable between 32-bit
and 64-bit processes on the same host.

AFAIK, on Microsoft Windows, where ExportSecContext and ImportSecContext
is available in SSPI, the interprocess token is a mere handle, it does
not contain any crypto state itself.

>
> That's all irrelevant here because any KDC using this will have
> to support such things, whether you like it or not.

GSS-API and its semantics should be entirely irrelevant to the KDC.

> For a number
> of reasons we _really_ _badly_ need partial security context export,
> and many of us believe there's no fundamental reason why it couldn't
> work (in the worst case by actually keeping open state on the acceptor
> and outputting a reference that can be used to obtain access to it again,
> probably via IPC).

I think you have it all backwards.  I would really appreciate if you
could first describe the exact necessities and constraints for the
facility that you need, before looking at whether an how such a
facility could be provide at the GSS-API level.

The above bears some resemblance with the saying
"If the only tool you know is a hammer, everything looks like a nail to you."

> resumption does, and that's NOT gibberish either.

TLS does _not_ have a facility to offload the TLS session state
in a session cookie _before_ the TLS handshake is complete!

And in the TLS session cookie case, the independent TLS server need
only to share the keying material that is used to encrypt the session
cookie, while the servers might have differing credentials.

> protocol issues that we're trying to work out.

I disagree.  I believe you should focus more on the the true problem
that you are trying to solve and stop struggling with how to get
the square interprocess token pegs into your round session cookie holes.

I'm afraid this may sound quite rude, but that is not my intention.
I do assume that you are looking at a real problem that you want to
solve, although I'm still puzzled/clueless (or maybe dense) what
it is about and what it has to do with GSS-API.

> Please explain in detail.

There are GSS-API mechanisms, which actually use TLS internally,
and put TLS handshake messages into GSS-API context level tokens --
which is a perfectly sensible design.

Look the TLS handshake at the top of this page:
https://tools.ietf.org/html/rfc5246#page-36

  1st context token  Initiator->Acceptor
       "ClientHello"
  2nd context token  Acceptor->Initiator
       "ServerHello+Certificate+CertificateRequest+ServerHelloDone"
  3rd context token  Initiator->Acceptor
       "Certificate+ClientKeyExchange+CertificateVerify+CCS+Finished"
  4th context token  Acceptor->Initiator
       "CCS+Finished"

Your suggestion means that the Acceptor would externalize its state
and piggy-back it on the 2nd context token above to off-load it to
the client, and expect to get that state back form the client,
piggy-backed on the 3rd context level token above.
You could not use the TLS session cookie facility to do this.
I assume it would require major surgery to your TLS implementation
to support something like this, and I have doubts that it would be
sensible to do this.

For transfering security contexts after gssapi security context 
establishment, you might be able to re-use most the TLS session cookie
facilities.

> liberty on the part of the mechanism).

Different to GSS-API context establishment tokens, there is no such
thing as a generic framing for interprocess tokens, and you should
not expect much error checking within gssapi mechanisms on the
interprocess token.  It would not surprise me the least if you
get crashes when passing corrupted or arbitrary data as interprocess
tokens into gss_import_sec_context() with many mechanisms.
In the original gssapi design, applications are required to ensure
the confidentiality (and integrity) of the interprocess tokens.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 22:14:27 -0500

> (Using an identifier for a saved context also fails in a multi-KDC

Sure, but a) I don't think it's too much to expect homogeneous KDCs for any
one realm (though I'd rather not require it), and b) I don't think there's
any reason we couldn't have interoperable exported security context tokens
(with room for implementation-specific blobs along with well-defined
payloads).

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 09:56:17 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Tue, 2011-05-03 at 15:41 -0400, Nico Williams wrote:
    >> I wasn't, actually, but that's a good point.  Any partial
    >> security context export functionality ought to protect against
    >> replays OR be protected against replays by the application that
    >> uses such functionality.  It's much better to require that the
    >> mechanism provide the replay protection.  For a
    >> challenge-response mechanism (or any mechanism with "DCE style"
    >> semantics) this is a non-issue.

    Greg> A challenge-response type mechanism protects against replays
    Greg> because the acceptor knows that the challenge is fresh.  If
    Greg> the client has the ability to replay an old exported partial
    Greg> security context and get the acceptor to import it, the
    Greg> freshness guarantee disappears.

    Greg> Binding the cookie contents to the armor key might be
    Greg> sufficient protection.

Speaking as an individual, I'm not sure this binding is sufficient.
The client's contribution to the armor key comes from the subsession key
so it is reasonably fresh.
The KDC's contribution comes from the TGT session key which is fresh on
the order of hours not conversations.
If you can show that a client has nothing to gain from a replay, then
the armor key might be sufficient.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 09:25:34 -0500

> the armor key might be sufficient.

Well, it's generally been the case that KDC replays are not a problem.
 If an attacker replays an AS-REQ and were to get a fresh AS-REP, he'd
still have to know the reply key.

What concerns me is that a GSS mechanism might be secure assuming that
acceptor-side state is not replayed yet not be secure if acceptor side
state is replayed.

A few thoughts regarding all this:

 - There's no way to make a "ticket" out of exported sec contexts,
only "cookies", because there's no shared secret key material at this
point with which a client could make -and the KDC verify- an
"authenticator".

 - A KDC could be expected to have a reasonably good (secure and
performant) replay cache, but a replay cache shared by all of a
realm's KDCs?  Not likely.

which thoughts lead me to these other thoughts/conclusions:

 - I don't mind binding GSS PA multi-round-trip exchanges to the KDC
where the initial context token went.  If that KDC drops off and the
client falls back on another, well, it's time to restart the GSS PA.
I realize that clients don't work this way today, but GSS PA doesn't
exist today either.

 - I also note that the TLS extension requires multiple I/O
round-trips between a client and a KDC.  One might argue that GSS is
more like TLS in this sense, and thus that we should use a
KDC-over-TCP extension to base the GSS PA on -- I certainly wouldn't
object.  But I could also see that the proponents might sorely need
GSS PA to work over UDP (do you?), in which case... see the prior
thought.

There's implications for other protocols where we'd like to use
encrypted exported sec context tokens as cookies for the purpose of
reducing server-side state: namely that the server must protect
against replays of such cookies in general.  This leads me to think
that we'll want a new GSS function for producing and importing these
cookies so as to improve code reuse (and also, some mechanisms might
be secure even in the face of state replay, in which case the
mechglue+mech could arrange to avoid the use of a replay cache.

A thought on replay caches: eneric, secure, high-performance replay
caches will probably be something we'll continue to need for a long
time.  We should still strive to reduce the need for replay caches,
but since I do believe that it's possible to have at least _local_
secure and high-performance rcaches, I don't think we should consider
the need for a replay cache to be fatal to a protocol design.

Finally, I thought I should mention an idea I had recently regarding
replay caches and clustering: use memcached -- it can probably be made
reliable enough (note that rcaches don't necessarily need persistence
so much as reliable detection of rcache data loss) and fast enough for
many applications, and certainly it'd be async, so that even if single
operation latencies were high one could still get many more operations
per-time unit than the inverse of per-operation latency.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 11:49:23 -0400

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

    Nico>  - I don't mind binding GSS PA multi-round-trip exchanges to
    Nico> the KDC where the initial context token went.  If that KDC
    Nico> drops off and the client falls back on another, well, it's
    Nico> time to restart the GSS PA.  I realize that clients don't work
    Nico> this way today, but GSS PA doesn't exist today either.

I'll note that this issue has come up multiple times before: in
discussions of the FAST draft (now RFC 6113), and in discussions of the
OTP draft.  I believe it actually came up a number of times during the
discussion of fast.

I don't feel comfortable speaking as chair here, because I was an author
of FAST, but it is my understanding that each time we've had a consensus
that KDCs should remain stateless and that clients should be able to
contact any KDC.

You can of course re-open that discussion, but my understanding is we've
discussed this issue several times before.
If you do want to reopen it, I suggest  spending some time summarizing
the past discussions on this topic as a starting point.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 11:11:15 -0500

> the past discussions on this topic as a starting point.

I believe I understand the rationale for desiring that KDC exchanges
with multi-round-trip PA require neither server-side state nor that a
signle KDC be used for all round-trips.  I'm not saying that there's
anything wrong with that.  I'm saying that we may need to consider
that that may not be realistically feasible for all PA, particularly
GSS PA (note though that we're not ready to conclude as much).

I'm not ready to reach any such conclusions, therefore I'm not ready
to re-open the question of statelessness, therefore it's too early to
go dig into the FAST discussions.  But also, if we did reach such
conclusions I don't think the FAST discussions would help us in any
way other than beyond, at most, ruling out GSS PA as such (but not as
a KDC-over-TCP extension).

Nico

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 May 2011 18:25:59 +0200

> On May 3, 2011 7:27 PM, "Greg Hudson" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> Sure, but a) I don't think it's too much to expect homogeneous KDCs 
> for any one realm (though I'd rather not require it), and b) I don't 
> think there's any reason we couldn't have interoperable exported 
> security context tokens (with room for implementation-specific blobs 
> along with well-defined payloads).
>

Hello all,

first of all, after a suggestion from Sam, I resubmitted the draft with 
the name draft-perez-krb-wg-gss-preauth-00. You can find it at 
http://tools.ietf.org/html/draft-perez-krb-wg-gss-preauth-00.

After reading the discussion, there is an important point that we would 
like to clarify. What we propose is to
include the value of context_handle in the PA-FX-COOKIE, not the 
complete context of the authentication. Thus the use of 
gss_export_sec_context() is not necessary. With the context_handle value 
received by the KDC (within the PA-FX-COOKIE), the KDC involved in the 
GSS-API based pre-authentication (let's talk later about what happens 
when a client selects a different KDC during a possible multi-round trip 
pre-authentication process) will be able to perform the proper calls to 
the GSS-API over the right context and continue the authentication 
process. Please refer to Section 6 in draft-perez-krb-wg-gss-preauth-00.

Another question is is whether this value should be sent encrypted or 
not. As far as we understand, Nico and others have commented that it 
would be required or at least recommendable. However it is not clear for 
us the security implications of not doing so. What could an attacker do 
with it? Could it motivate any kind of attack other than a DoS. 
Additionally, RFC6113 does not specify anything about protecting the 
contents of PA-PX-COOKIE, which always contains state-related information.
Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 May 2011 18:34:14 +0200

> long exchanges, and might run afoul of replay cache-type protections.

As commented in a previous mail, our intention is not use the 
gss_export_sec_context(), since it may generate tokens too big that 
would make negotiation heavy or even make it fail. Instead, the 
intention is to transport only a handle or reference to the context in 
the acceptor. Note that the state is kept by the GSS acceptor 
implementation, not by the KDC. The KDC itself does not keep state, only 
performs calls to the GSS-API using that handle.

Best regards,
Alejandro

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 11:47:23 -0500

On Wed, May 4, 2011 at 11:34 AM, Alejandro Perez Mendez <[email-masked]> wrote:
> gss_export_sec_context(), since it may generate tokens too big that would
> make negotiation heavy or even make it fail. Instead, the intention is to
> transport only a handle or reference to the context in the acceptor. Note
> that the state is kept by the GSS acceptor implementation, not by the KDC.
> The KDC itself does not keep state, only performs calls to the GSS-API using
> that handle.

The KDC _is_ the acceptor here.  Your proposal makes the KDC stateful.
 I'm not necessarily opposed to that, but we need to be explicit about
this and, as Sam points out, PAs that require KDC-side state require
additional discussion of the statelesness assumption.

(Also, even if we do as you propose, you still need to MAC the context
handle ID.)

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 4 May 2011 18:59:54 +0200

> GSS PA (note though that we're not ready to conclude as much).

I completely agree with Nico. As evident, further discussion and analysis is required here. In fact, as Sam mentioned, maybe a summary
of previous discussions would help. But certainly some particular multi-round-trip PAs may require to complete the process with the same KDC 
during the process. 

> a KDC-over-TCP extension).

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 13:10:09 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> Dear all, We have submitted a draft proposing a new
    Alejandro> pre-authentication mechanism for Kerberos based on the
    Alejandro> GSS-API. The abstract of the document is the following:

Hi.
It's great to see this work.
However, I'd like to understand your goal in submitting this here.

Are you simply seeking review comments for individual work you want to
retain change control of?
Alternatively, are you looking to ask the Kerberos working group to
adopt this and try to standardize this approach, giving up change
control to the IETF in the process?
If you are interested in standardization, would you be interested in
remaining editor of the draft if it were adopted?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 13:26:58 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> I completely agree with Nico. As evident, further discussion
    Rafa> and analysis is required here. In fact, as Sam mentioned,
    Rafa> maybe a summary of previous discussions would help. But
    Rafa> certainly some particular multi-round-trip PAs may require to
    Rafa> complete the process with the same KDC during the process.

IN practice people have adopted one of three strategy to deal with this
issue:

1)  design mechanisms not to be vulnerable to this sort of issue

2) Most of the mechanisms that inherently have this issue are things
like OTP mechanisms. There, the technology generally already has a
distributed authentication service that the KDC can call into.
That's the approach we adopted for the preauth draft: your OTP server,
called by your KDC, must provide coordination if it is needed.

3) SecurID support floating around has included a non-standard extension
to KDCs that causes them to drop a packet on the floor if they would
rather not respond to it.
This has never been proposed for standardization.

4) Some versions of the kerberos-sam draft did propose a way of
referring a request back to a specific KDC, but the WG has moved away
from that.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 04 May 2011 13:39:48 -0400

On Wed, 2011-05-04 at 12:25 -0400, Alejandro Perez Mendez wrote:
> would be required or at least recommendable. However it is not clear
> for us the security implications of not doing so. What could an
> attacker do with it? Could it motivate any kind of attack other than a
> DoS.

It might not be necessary to protect the authenticity of the handle over
the wire.  The KDC will need to manage a list of valid handles
regardless (otherwise stale handles could be used to trick a KDC into
passing an invalid pointer to gss_accept_sec_context) to avoid a
KDC-wide DOS attack.  If you manage to intercept or guess somebody
else's handle, you'll cause their exchange to fail, but there are
generally plenty of ways to do that.

> contents of PA-PX-COOKIE, which always contains state-related

Sure it does.  See section 5.2, specifically the text starting with
"However, the KDC MUST...".

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 4 May 2011 19:49:32 +0200

Hi Greg,

El 04/05/2011, a las 19:39, Greg Hudson escribió:

> the wire.  

Agree

> The KDC will need to manage a list of valid handles
> KDC-wide DOS attack.

Shouldn't the GSS-API report an error when an invalid context handle is provided?. I asked because I do not understand why this list should be managed by the KDC.

>  If you manage to intercept or guess somebody

Exactly, there are plenty of ways. So it is not clear to me the purpose of defining a mechanism just for this case.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 13:01:22 -0500

> Shouldn't the GSS-API report an error when an invalid context handle is provided?. I asked because I do not understand why this list should be managed by the KDC.

GSS-API mechglue/mechanism implementations are not required to
validate values of gss_name_t, gss_cred_id_t, and/or gss_ctx_id_t.
They may, but I don't think they are required to, at least to my
reading of RFCs 2743 and 2744 (but then, those RFCs don't use RFC2119
language, so it's sometimes difficult to discern what's required and
what's optional).  Most implementations don't.

If the API had been constructed with acceptor statelessness in mind
then the specs might have required such handle validation.  And/or
perhaps there might have been a way to get handle values that are
octet strings and include embedded verifiers.  And/or there might have
been a way to get encrypted exported security context tokens for use
as "cookies" to reduce server-side state.  But it's pretty clear that
the GSS-API was not designed with acceptor statelessness in mind :(

Nico

---

From: Greg Hudson <[email-masked]>
Date: Wed, 04 May 2011 14:06:34 -0400

On Wed, 2011-05-04 at 13:49 -0400, Rafa Marin Lopez wrote:
> Shouldn't the GSS-API report an error when an invalid context handle
> is provided?. I asked because I do not understand why this list should
> be managed by the KDC.

None of the GSSAPI mechglues I'm familiar with (MIT krb5, Solaris,
Heimdal, Gnu GSS) perform handle checking; they will all crash if passed
an invalid gss_ctx_id_t.  Passing untrusted values as context handles is
unusual, so it does not make sense to burden everyone with the overhead
and internal complexity of handle validation.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 4 May 2011 20:22:59 +0200

Hi Greg,

> and internal complexity of handle validation.

I completely understand your point. However my question was more something like: does RFC 2743 preclude that?.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 13:23:26 -0500

> and internal complexity of handle validation.

If those implementations used small integers as handles (necessarily
cast to pointers due to the fact that those implementations have long
defined these handle types as pointers)... validation wouldn't be
difficult, and might even require no more synchronization than a
memory barrier (though I'd have to think about this a little more).
But as you say, they don't.  And since they use actual pointers,
validation would be relatively painful (though assuming each handle is
generally referenced in only one thread one could optimize validation
by using thread-locals and minimal synchronization to handle
invalidation -- but that'd be quite a lot of code!).

If we were trying to move RFCs 2743 and 2744 to Draft Standard we'd
have to add all sorts of MUSTs, SHOULDs, and MAYs, and this area
(handle validation) is one that would have to say MAY, at most SHOULD,
validate.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 13:27:01 -0500

> I completely understand your point. However my question was more something like: does RFC 2743 preclude that?.

No, it does not preclude it.  Indeed, RFC2743 (and 2744) defines major
status codes for indication of "invalid handle" errors.  Since these
RFCs do not use RFC2119 language we don't really know whether they
intended to REQUIRE that implementations support handle validation.
We do know that none of the four implementations listed by Greg ever
did handle validation[*].

Requiring that a KDC implementor's GSS-API implementation do handle
validation would probably not help promote GSS pre-auth :(

[*] Well, the MIT krb5 _mechanism_ had handle validation, but the MIT
krb5 _mechglue_ never did, which means that the whole also never did.

Nico

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 May 2011 20:27:26 +0200 (MEST)

Rafa Marin Lopez wrote:
> Greg Hudson wrote:
> is provided?. I asked because I do not understand why this list
> should be managed by the KDC.

Many gssapi mechanism implement gss_ctx_id_t, gss_name_t and gss_cred_id_t
as pointers, and will dereference whatever handles the application caller
passes to them.

Running servers that will attempt to pass arbitrary values received over
the network as gss_ctx_id_t, gss_name_t or gss_cred_id_t to functions
of its gssapi mechanism seems like a very bad idea.

-Martin

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 May 2011 20:39:19 +0200

> "However, the KDC MUST...".
Mmm, it seems that I read too fast that part. Thanks for the remark.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 04 May 2011 20:56:34 +0200

> On Wed, May 4, 2011 at 1:22 PM, Rafa Marin Lopez<[email-masked]>  wrote:

Indeed, RFC 2743 says that, after a call to GSS_Init_sec_context, major 
status could be:

    o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
    for the input context_handle provided; this major status will be
    returned only for successor calls following GSS_S_CONTINUE_ NEEDED
    status returns.

I would need to think on it a bit more, but handle validation could be 
as simple as building an associative list (map or similar) linking a 
"key" with a "value", where the key will be the context_handle and the 
value will be the actual pointer. On each call, the glue checks that the 
key is present in the list. If so, the actual pointer is passed to the 
specific mechanism. Maybe this is nonsense or too simple.

> validation would probably not help promote GSS pre-auth :(

That's true, of course. But RFC 2743 foresees this kind of situation 
reserving a major status error code for it.

Best regards,
Alejandro

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 14:21:41 -0500

As I wrote ear;ier, the RFCs allow for handle validation, but they do
not require it, and existing implementations don't do it.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 5 May 2011 00:58:18 +0200

Hi Nico,

El 04/05/2011, a las 20:27, Nico Williams escribió:

> status codes for indication of "invalid handle" errors.

Right.

>  Since these

Agree.
> validation would probably not help promote GSS pre-auth :(

I was just trying to clearly understand the different problems raised with the use of the gss_ctx_id_t. And your explanations and Greg's clarify very well the implementation aspect of the context_handle, which is indeed really important. 

Thanks.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 5 May 2011 01:02:42 +0200

> (Also, even if we do as you propose, you still need to MAC the context

Since, after all, KDC may need to be stateful, Greg's suggestion sounds also interesting: "The KDC will need to manage a list of valid handles" which, in principle, would not require any MAC for the handle/s, don't you think so?.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 18:05:39 -0500

> Since, after all, KDC may need to be stateful, Greg's suggestion sounds also interesting: "The KDC will need to manage a list of valid handles" which, in principle, would not require any MAC for th…

That's certainly an option.  Before we go down that path we should try
to convince ourselves that we can't make GSS PA stateless on the
server side.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 5 May 2011 01:13:20 +0200

> to convince ourselves that we can't make GSS PA stateless on the

Fully agree.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 18:45:51 -0500

> to convince ourselves that we can't make GSS PA stateless on the

My own tentative analysis of several mechanisms says that the
encrypted security context token cookie approach is secure for the
KDC, with or without replay caching.  For non-KDC applications the
situation is a bit trickier (basically: it's OK if channel binding is
used, but if not then you need a replay cache shared by all hosts in
the cluster, if there's a cluster).

1-round-trip mechs wouldn't involve the use of exported sec context
token cookies, so we just ignore those.

Mechanisms:

 - RFC4121 (krb5), with DCE style
 - SCRAM
 - mech_dh, with DCE style
 - PKU2U, GSS-TLS (imaginary, but it helps analyze)
 - IAKERB, GSS-EAP, SAML, ...

In the first few cases the exported, partially-established sec
contexts will bear things like:

 - channel bindings (all, but note that if the context token exchange
happens over multiple different channels then there's a bit of a
problem unless the CB type is an end-point type)
 - acceptor sub-key (Kerberos and mech_dh w/ DCE style)
 - copy of the Ticket from the initial token (Kebreros w/ DCE style)
 - StoredKey (SCRAM)
 - nonces/challenges (SCRAM)
 - XOR of hashes of context tokens so far
 - names of AAA/IdP servers that inner tokens are being forwarded to
(GSS-EAP, SAML, ...)

The output, ultimately, is an initiator principal name (including name
attributes, such as might come from a Ticket's authz-data), and
session keys from which to derive (via GSS_Pseudo_random() the reply
key and such things.

As usual in the KDC protocols, replays are not a problem just because
they result in the same reply key being used -- that's a non-problem
that we already have, and we overcome it by using modern enctypes.

All mechanisms other than GSS-EAP, SAML and friends, are replayable
when used in this fashion.  Mechanisms that "tunnel" communications
between the initiator and KDCs/AAAs/IdPs are not necessarily
replayable: if the tunnel involves state on the KDC/AAA/IdP side then
the {token, encrypted exported sec context cookie} will not be
replayable.

None of these really depend on the KDC that the initiator talks to
being the same for each round-trip of the GSS sec context token
exchange.

Outside the context of KDCs w/ GSS PA the situation is different.  In
my GSS-REST proposal, for example, we'll need these GSS state cookies,
at least in the HTTP/1.0 case, and almost certainly also in the
HTTP/1.1 w/ pipelining case as well., but we must prevent replays,
which means we'll need a replay cache in GSS-REST, and it will need to
support clusters (for which my preference will be to use memcache).

So...  IMO we definitely need partially exported security context
tokens, and given those and a shared realm secret key for encrypting
them, and that will be the cookie you need.

Of course, this is a tentative analysis.  I'll think about it more later.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 18:54:40 -0500

Oh, and in the GSS-REST case we should always be using channel
binding, so a replay cache is avoidable at least when end-point CB are
used.  When unique CB are used we'd need to always MIC those in every
request/response (putting the MICs in the headers), and for
multi-round-trip exchanges we'd need to MIC the CBs of all the
round-trips' channels at the end.  We could avoid the use of a replay
cache in the unique CB case as well.

So, unless we have a CB-less GSS-REST use case, I think we can avoid
replay caches in all the cases that I care about.  But for the
tls-unique CB cases the protocol is slightly more complicated than in
the tls-server-end-point case.  We'll probably want
tls-server-edn-point in all cases anyways, so... no big deal.

(For those who don't know what I'm talking about, I submitted a paper
for the W3C identity in the browser workshop on "GSS-REST" and posted
it to the SAAG mailing list as well.  GSS-REST is an idea for doing
application-layer authentication in HTTP apps using the GSS-API, with
proper browser integration in the case of browser-based clients.)

Nico

---

From: Luke Howard <[email-masked]>
Date: Thu, 5 May 2011 09:27:15 +0200

> all cleartext in KDC-REQ-BODY, and preferably any other PA data

I'm just catching up on mail, but it seems to me that using channel bindings is way simpler than dealing with the hash agility issues yet again. Unless I suppose you need to support mechanisms that don't have channel bindings.

-- Luke

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 05 May 2011 10:18:55 +0200

> being the same for each round-trip of the GSS sec context token

Mmm, unless I've missed something of your tentative, the 
partially-established sec context should bear also the specific GSS 
mechanism state machine.
For example, in the case of GSS-EAP, the context token should contain 
the EAP state and the specific EAP method's state. That, specially in 
cases where TLS is involved, may be a complex task and result in a 
really big token.

Regards,
Alejandro

---

From: Luke Howard <[email-masked]>
Date: Thu, 5 May 2011 13:09:41 +0200

> Mmm, unless I've missed something of your tentative, the partially-established sec context should bear also the specific GSS mechanism state machine.
> For example, in the case of GSS-EAP, the context token should contain the EAP state and the specific EAP method's state. That, specially in cases where TLS is involved, may be a complex task and result in a really big token.

On the acceptor, we just care about the RADIUS PW_STATE AVP, which (given it has to fit in a UDP RADIUS response) shouldn't be too big. (Plus the AAA server name.) We're not proposing calling gss_export_sec_context() on a partially established initiator context.

It's true, if we do adopt the proposal of signing the entire conversation with GSS_GetMIC(), then yes, the state could be very large.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 May 2011 09:14:29 -0500

On Thu, May 5, 2011 at 3:18 AM, Alejandro Perez Mendez <[email-masked]> wrote:
> For example, in the case of GSS-EAP, the context token should contain the
> EAP state and the specific EAP method's state. That, specially in cases
> where TLS is involved, may be a complex task and result in a really big
> token.

It's certainly doable.  I don't see the problem.  And, for the
acceptor, this is much simpler than, say, for the initiator, because
the acceptor doesn't need to save the state of any TLS tunnels,
whereas the initiator would have to if it were exporting a partially
established GSS-EAP sec context.

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 5 May 2011 17:16:16 +0200

Hi Nico, 

El 05/05/2011, a las 01:45, Nico Williams escribió:

> KDC, with or without replay caching.

Regarding "encrypted security token", maybe you are aware of this RFC http://tools.ietf.org/html/rfc5077 (Transport Layer Security (TLS) Session Resumption without
Server-Side State). 

>  For non-KDC applications the

Since you mention a "shared realm secret key", I assume that you have a mind that a context could be processed by any KDC in the realm in order to continue the authentication. That is correct in certain cases. However, please consider also this: There are multi-round trip authentications that requires mutual authentication for example. So that client and the authenticator must remain the same entities. So if the client is contacting with KDC_1 and mutual authentication is required, switching to a new KDC_2 in the middle of the authentication will not help (the client is trying to authenticate KDC_1 not KDC_2)

Thus, even if we export all state of the KDC to make it stateless, the client will have to exchange all messages of the multi-round trip authentication with the same KDC. In other words, the context the client has can/should be consumed by the same KDC that generated it.

---

From: Luke Howard <[email-masked]>
Date: Thu, 5 May 2011 17:20:36 +0200

> Since you mention a "shared realm secret key", I assume that you have a mind that a context could be processed by any KDC in the realm in order to continue the authentication. That is correct in ce…

Are we mutually authenticating the KDC or the realm? i.e. what is the target name passed to gss_init_sec_context()? If it represents the realm (TGS name) then I don't see why mutual authentication won't work with multiple KDCs.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 May 2011 11:06:21 -0500

> Regarding "encrypted security token", maybe you are aware of this RFC http://tools.ietf.org/html/rfc5077 (Transport Layer Security (TLS) Session Resumption without

Yes.  But that is more like a ticket than a cookie.  Here we can only
produce a cookie-like object because at the time when we produce it we
may not yet have established any sort of session key by which the
client could prove possession.  Aside from that the similarity between
these two schemes lies in placing the server/acceptor state in an
encrypted blob sent to the client/initiator.

> Since you mention a "shared realm secret key", I assume that you have a mind that a context could be processed by any KDC in the realm in order to continue the authentication. That is correct in ce…

As Luke points out, KDCs for any one realm already share a key: the
TGS key.  The key used to encrypt these state cookies could be a key
derived from the TGS key.  Or the KDCs could have a special key just
for this purpose (likely making it easier to roll it over) -- this is
really an implementation detail because the key is shared only by the
KDCs of any given realm.

> Thus, even if we export all state of the KDC to make it stateless, the client will have to exchange all messages of the multi-round trip authentication with the same KDC. In other words, the contex…

Since we can expect the KDCs to share such a key, no, there's no need
to have all the AS-REQs for a single exchange go to the same KDC.

Nico

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 May 2011 20:11:59 +0200 (MEST)

Nico Williams wrote:
> > That's certainly an option. Â Before we go down that path we should try

If replayability of the authentication creates a security problem
for your protocol, then it is formally provable that there can not
exist a solution that is stateless on the server side.

At the abstract level, there exist the following solutions:

1.) challenge-response, which typically results in 3 tokens (1.5 round-trips)
    requiring server-side state to verify the response on the challenge.
    _no_ replay cache necessary.

2.) uniqueness requirement for the authentication request, which typically
    results in 2 tokens (1 round-trip)
    replay cache required of unlimited size and unlimited lifetime.

For (2), there exist optimizations in order to keep the replay cache
small, in that the uniqueness is usually extended by a time-based part,
and the validity of the authentication request is limited to a
validity time window around the time-based part, which limits the
replay cache requirements for storage size and storage duration
to the validity time window.

While it is possible to wrap (1) into something that looks like (2)
by offloading the state about the challenge that is needed for the
verification of the response onto the client, this will earn you
the requirement for a replay cache.  

The validity time window for (2) and the handshake timeout for (1)
are usually within the same ballpark, in (1) there is a full network
round-trip, which may result in higher communication&processing delays,
but clock-skew between communication peers is a non-issue, while in (2),
you might have less communication and processing delays because it is
just half a leg, however you're facing the clock skew issue.

Botton line is that you end up making a trade-off.  If replayability
amounts to a security problem, then you MUST keep state on the server.

The number of entries (seperate states) that the server needs to keep
is determined by the number of concurrent clients it wants to be able
to serve, and about the same for (1) and (2).
You can try to "off-load" server state to the client at the expense
of network bandwith and processing overhead, with both,
vanilla (1) and (2), as well with (1) wrapped to look like (2).

And the server-side state, no matter what it looks like (challenge
or replay cache entry) will have to be shared among all servers
that should be able to serve the request, there is no way around that.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 May 2011 13:27:42 -0500

> exist a solution that is stateless on the server side.

I forgot to mention one detail for the GSS-REST channel binding case:
the channel had better provide confidentiality protection.

To answer you in detail, then:

 - in the KDC AS exchange case there's no harm in replays (it has long
been thus), therefore we don't care;
 - in the GSS-REST case, at least when we have channel binding with
unique CB data type, no replay can ever happen (even if the channel
provides only integrity protection, and no confidentiality
protection);
 - in the GSS-REST case with CB using end-point CB the channel has to
provide confidentiality protection, not just integrity protection,
otherwise replays are a problem
   - and also in this case we have to consider replays by the same
initiator entity (since those are possible)... if the mechanism has
any way to handle security context replay freshness (e.g., the
timestamp in krb5 Authenticators), then that may be enough, else a
replay cache is necessary.

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 6 May 2011 01:19:47 +0200

Hi Luke

> Are we mutually authenticating the KDC or the realm? i.e. what is the target name passed to gss_init_sec_context()? If it represents the realm (TGS name) then I don't see why mutual authentication…

This is indeed a very interesting question. Looking at the general use of GSS-API, my interpretation of RFC 2743 is what you include in the "target name" is the server identity: "The client calls GSS_Init_sec_context() to establish a security context to the server identified by targ_name,...". If you have two servers (e.g. server1.domain.net and server2.domain.net) providing the same service, each server is a different acceptor and the initiator will use different "target name" depending on what acceptor the initiator is talking with. But I may be mistaken in my interpretation.

Having said that, in my mind, KDC_1 (kdc1.domain.net) is one acceptor and KDC_2 (kdc2.domain.net) is another different acceptor but we would use the same target name for both unlike we do in the example above. Is that what you suggest?.

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 May 2011 18:23:42 -0500

In your GSS PA all the KDCs for a given realm have to have the same
acceptor name, and the same KDB, keys, ...
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 May 2011 03:08:11 +0200 (MEST)

Rafa Marin Lopez wrote:
> 
> > Are we mutually authenticating the KDC or the realm?
> > i.e. what is the target name passed to gss_init_sec_context()?
> > If it represents the realm (TGS name) then I don't see why mutual
> > authentication won't work with multiple KDCs.

That is really an interesting question.

But using Kerberos itself as preauthentication to obtaining a Kerberos TGT
sounds somewhat like an hen-and-egg problem, and there usually is no "REALM"
principal in the average KDB, I assume (there is a KDC principal
of the type krbtgt/REALM@REALM).

> 
> This is indeed a very interesting question. Looking at the general
> use of GSS-API, my interpretation of RFC 2743 is what you include
> in the "target name" is the server identity: "The client calls
> GSS_Init_sec_context() to establish a security context to the server
> identified by targ_name,...".

GSS-API authenticates "target names" or more appropriately,
"target credential holders".

In the real world, you find two categories of folks

(1) I want to talk to service "foo of Bar Inc.", and I don't give
    a damn on which host that service runs today or to which
    backend machine I'm loadbalanced, proxied or otherwise
    forwarded to.

(2) I want to talk to port x on host y and I don't give a damn who owns
    the machine y and who is entitled to run service x on that machine.

The CABrowser Forum seem to believe that anti-fraud protection is
_much_ easier for type (1) folks and I think that observation is
correct.  But implementing (2) is much easier for programmers,
so a lot of software is hardwired to blindly fall for (1).

Back to the original question:  agreeing on a target name that
will work accross a large variety of GSS-API mechanisms to
work for preauth of a Kerberos AS_REQ/AS_REP might be challenging,

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 May 2011 21:40:46 -0500

> That is really an interesting question.

Not really.  All KDCs will have to share a name (kinda like they already do).

What is interesting is the name _type_.  It's certainly not a
host-based service name type.  It's a service name, yes, but with a
realm instead of a hostname.  But because Rafael et. al. want to use
this with non-Kerberos GSS mechanisms, the name type needs to be
something that those mechanisms might support.  See below.

> of the type krbtgt/REALM@REALM).

Who said anything about using Kerberos as pre-auth for Kerberos??
Kerberos already does that... in TGS exchanges (which are very similar
to AS exchanges), via the PA-TGS pre-authentication type.  And with
FAST Kerberos can now do what we used to call "DCE RFC 26" (namely,
use one principal's TGT to help protect another's PA-ENC-TIMESTAMP).
There's no question of infinite recursion because a client could
trivially understand when it'd be recursing infinitely.

>    backend machine I'm loadbalanced, proxied or otherwise

So, what name-type is that?  It'd be useful to wander over to KITTEN
WG and describe the name-types that you use that we don't -- they
might be useful!  (Assuming you're free to do so, of course.)

> so a lot of software is hardwired to blindly fall for (1).

Users type or cut-n-paste URLs, and they recognize the domainname part
of those URLs because those often involve brand-names or other
recognizable names of people they want to do business with.  Therefore
GSS principal names for web services need to be based on the domain
part of URLs -- there's no other way because that's the only name-like
item that users have to identify web services.

> work for preauth of a Kerberos AS_REQ/AS_REP might be challenging,

What I can see us doing is: a) specify a new name-type with generic
syntax for naming KDC services for Kerberos realms, b) defining
mechanism-specific mappings of (a), and, sadly, c) using site-specific
conventions for naming KDC services in various mechanisms.  (c) is a
fallback.  It wouldn't be too tragic if we only did (c).  But I'd
rather we do (a) and (b).

Nico

---

From: Luke Howard <[email-masked]>
Date: Fri, 6 May 2011 09:52:12 +0200

> rather we do (a) and (b).

For non-Kerberos mechanisms that support GSS_KRB5_NT_PRINCIPAL_NAME, like GSS EAP, we can use krbtgt/REALM@REALM. For mechanisms that don't support mutual authentication, we can use GSS_C_NO_NAME.

For other mechanisms, I'm not sure what we do, maybe we need something like GSS_C_NT_REALMBASED_SERVICE. Perhaps we can abuse GSS_C_NT_HOSTBASED_SERVICE with krbtgt as the service name.

-- Luke

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 06 May 2011 10:57:16 +0200

Agree.

> For other mechanisms, I'm not sure what we do, maybe we need something like GSS_C_NT_REALMBASED_SERVICE.

I was thinking on something similar at first. But, since 
GSS_C_NT_REALMBASED_SERVICE would also be Kerberos-specific, maybe it 
does not make sense to define a new type instead of using the already 
defined GSS_KRB5_NT_PRINCIPAL_NAME.

> Perhaps we can abuse GSS_C_NT_HOSTBASED_SERVICE with krbtgt as the service name.

Do you mean to use something like "krbtgt@realm" where "realm" is the 
DNS name corresponding to the Kerberos REALM? Since the part after the @ 
is supposed to be a hostname, not a domain name, I think other 
alternatives are preferable.

Regards,
Alejandro

---

From: Luke Howard <[email-masked]>
Date: Fri, 6 May 2011 12:29:14 +0200

> I was thinking on something similar at first. But, since GSS_C_NT_REALMBASED_SERVICE would also be Kerberos-specific, maybe it does not make sense to define a new type instead of using the already defined GSS_KRB5_NT_PRINCIPAL_NAME.

Right.

In the interests of minimising changes to existing mechanism glues, using GSS_KRB5_NT_PRINCIPAL_NAME makes sense. I'd be interested to know which contemporary GSS mechanisms support mutual authentication but don't support GSS_KRB5_NT_PRINCIPAL_NAME. SCRAM and SAML might be two.

What if the preauthentication layer calls gss_inquire_names_for_mech() to check for the availability of  GSS_KRB5_NT_PRINCIPAL_NAME. If present, it uses it, otherwise it uses GSS_C_NT_USER_NAME with names like "krbtgt/REALM@REALM"?

> Do you mean to use something like "krbtgt@realm" where "realm" is the DNS name corresponding to the Kerberos REALM? Since the part after the @ is supposed to be a hostname, not a domain name, I think other alternatives are preferable.

Agreed. We could use a magic hostname though (e.g. _kerberos.realm).

-- Luke

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 06 May 2011 14:33:34 +0200

Hi all,

after following the discussion, I think that we have faced with an 
interesting obstacle: Kerberos KDC is defined to be stateless, but 
GSS-API does not allow the export of partially established security 
contexts. As I see it, there are two options to continue:

Option A)

    To extend or modify the GSS-API specification to allow exporting
    partially established contexts. This would imply the modification of
    several RFCs (at least RFC 2743 and RFC 2744) and existing
    implementations to conform the extended interpretation of this call.

Option B)

    To allow the KDC to be statefull under certain circumstances. Let me
    explain this alternative a little more.
    Kerberos defines the KDC as a stateless entity, that is, the AS_REQ
    and TGS_REQ exchanges can be performed with different KDCs without
    altering the result of the process, and the KDC does not need to
    store any state after sending each corresponding response. This is
    true since these exchanges are single-round-trip and because all the
    state required to perform the TGS_REQ is contained in the TGT.

    However, the Kerberos preauth framework (RFC 6113) allows the
    "virtual" extension of the AS_REQ exchange across multiple round
    trips. We could then consider that the AS_REQ exchange actually
    starts with the first AS_REQ message, extends over the sequence of
    KRB_ERROR_MORE_PREAUTH_REQUIRED/AS_REQ messages and finalizes with
    the AS_REP message. It would make sense to relax the statelessness
    requirement within this "virtual" exchange for those
    pre-authentication mechanisms that require to maintain some context
    state along the process, and enforce the user to send all the AS_REQ
    messages belonging to this "virtual" AS_REQ exchange to the same
    KDC. The KDC would still be stateless as defined in RFC 4120, in the
    sense that the AS_REQ, TGS_REQ and AP_REQ exchanges are independent
    between them, and no state is required to be stored in the KDC.

    Additionally, from the point of view of an authentication system
    (specially when mutual authentication is involved), the
    authentication process will be performed between the same two
    physical entities from the begging to the end.

Best regards,
Alejandro

> On Wed, May 4, 2011 at 11:34 AM, Alejandro Perez Mendez<[email-masked]>  wrote:

---

From: Luke Howard <[email-masked]>
Date: Fri, 6 May 2011 14:41:42 +0200

> However, the Kerberos preauth framework (RFC 6113) allows the "virtual" extension of the AS_REQ exchange across multiple round trips. We could then consider that the AS_REQ exchange actually starts with the first AS_REQ message, extends over the sequence of KRB_ERROR_MORE_PREAUTH_REQUIRED/AS_REQ messages and finalizes with the AS_REP message. It would make sense to relax the statelessness requirement within this "virtual" exchange for those pre-authentication mechanisms that require to maintain some context state along the process, and enforce the user to send all the AS_REQ messages belonging to this "virtual" AS_REQ exchange to the same KDC. The KDC would still be stateless as defined in RFC 4120, in the sense that the AS_REQ, TGS_REQ and AP_REQ exchanges are independent between them, and no state is required to be stored in the KDC. 
> 
> Additionally, from the point of view of an authentication system (specially when mutual authentication is involved), the authentication process will be performed between the same two physical entities from the begging to the end.
RFC 6113 reiterates the fact that KDCs are stateless (section 5.2). Your GSS-API pre-authentication draft could certainly indicate otherwise. I don't have any particularly strong feelings either way.

Why not add a GSS_C_MA_PART_CTX_TRANS attribute (RFC 5587) to indicate support for partial context attribute? If so, then a stateless (multiple KDC) exchange could be supported. You would need some way of indicating this in the pre-authentication protocol.

Perhaps a more pertinent issue is that this would require standardising the format of partial context tokens, which might be less practical.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 09:28:25 -0500

I'm all for allowing export of partially-established security
contexts.  That will work.  I've not seen any reason not to do it.

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 6 May 2011 17:16:39 +0200

Hi Luke, 

> RFC 6113 reiterates the fact that KDCs are stateless (section 5.2). Your GSS-API pre-authentication draft could certainly indicate otherwise. I don't have any particularly strong feelings either wa…

It is clear what RFC 6113 says about this. But it is not less certain that, as already stated, exporting partially established security contexts is not allowed by RFC 2743. Also Martin also did a really good analysis about exporting partially established security contexts in https://lists.anl.gov/pipermail/ietf-krb-wg/2011-May/009093.html 

> Perhaps a more pertinent issue is that this would require standardising the format of partial context tokens, which might be less practical.

So basically, it seems somehow you are more comfortable with a Option A-alike solution, am I right?. In my case, I am not completely sure if Option-A is simpler than Option-B not only in terms of designing standpoint but also implementation implications. I do not see a strong technical problems in Option B,  assuming that all messages from KRB_AS_REQ to the final KRB_AS_REP in a multi-round trip authentication can be sent by the client to the same KDC. After all once the client gets the TGT after receiving KRB_AS_REP, the client may go to any other KDC in the realm. Nevertheless, I am also well aware that RFC 6113 mentions otherwise about state during pre-authentication and must be a strong reason for that. However, OTP pre-auth also says:

" As described in section 5.2 of [RFC6113], a client can not be certain
   that it will use the same KDC for all messages in a conversation.
   Therefore, the client cannot assume that the PA-OTP-REQUEST will be
   sent to the same KDC that issued the PA-OTP-CHALLENGE.  In order to
   support this, a KDC implementing this protocol requires a means of
   sharing session state.  However, doing this does introduce the
   possibility of a replay attack where the same response is sent to
   multiple KDCs."

In the end, sort of shared session state is required between KDCs for the OTP-CHALLENGE. In fact, this is a case where it is allowed that the client may NOT contact the same KDC but, 
in the end, there must be a shared session state in the infrastructure side.

---

From: Luke Howard <[email-masked]>
Date: Fri, 6 May 2011 17:23:49 +0200

> It is clear what RFC 6113 says about this. But it is not less certain that, as already stated, exporting partially established security contexts is not allowed by RFC 2743. Also Martin also did a r…

Yes, this is a good analysis.

> So basically, it seems somehow you are more comfortable with a Option A-alike solution, am I right?. In my case, I am not completely sure if Option-A is simpler than Option-B not only in terms of d…

Option B is definitely simpler to implement. (I haven't looked at how hard it is to bind sendto_kdc() to a single KDC, but I can't imagine it would be too difficult.) So maybe this is the best option. I don't have a strong opinion either way, generally I prefer easiest to implement unless there's a strong technical reason to do otherwise.

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 6 May 2011 17:29:22 +0200

Hi Nico,

> contexts.  That will work.  I've not seen any reason not to do it.

Don't you think analysis in https://lists.anl.gov/pipermail/ietf-krb-wg/2011-May/009093.html may affect?

Btw, I was wondering what happens in the case, for example, authentication is based on challenges: how could this prevent to save the state (the challenge) in the infrastructure side? (maybe you already explained it. My apologies if you did)

---

From: Luke Howard <[email-masked]>
Date: Fri, 6 May 2011 17:34:21 +0200

> Btw, I was wondering what happens in the case, for example, authentication is based on challenges: how could this prevent to save the state (the challenge) in the infrastructure side? (maybe you al…

If the challenge and challenge response are passed to the infrastructure in a single request (as in the case of NTLM, Digest, etc) this should be straightforward. Unless you were thinking of something else...

(Of course, doing NTLM preauthentication to Kerberos may be not so desirable.)

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 10:49:35 -0500

> defined and limited to interprocess context transfer within a single host.

I don't see the relevance of this.  So it was intended for one purpose
and we can think of another.  So what?

>  http://tools.ietf.org/html/rfc2743#page-28

We know how to read RFCs, thank you.

> A fully established gssapi security context only needs "traffic keys",

We call them session keys.

> for message integrity protection services).

So far so good.

> iterator function is undefined at the GSS-API level.

So far so good.

> when the caller provides GSS_C_NO_CRED instead).

An application handling an input context token for a sec context
imported from an exported partially established security context token
(what a mouthful) would have to use the same credential, yes, but not
the same credential _handle_.  I hardly think this is a problem.

> accessed through PKCS#11 on other platforms).

I don't see how storing credentials on hardware tokens prevents the
export of partially established security contexts.

Let's do a thought experiment.  Let's imagine that we have a GSS
mechanism where the acceptor needs to access acceptor credentials at
two different points in the context token exchange, and that those
credentials are stored as non-extractable keys on an HSM.  Let's
imagine that this is a mechanism whose context tokens are essentially
TLS handshake messages, with renegotiation immediately after the
initial handshake.  And let's imagine that we're using RSA key
transport cipher suites.  So the context token exchange will look like
(roughly):

(1) I->A: ClientHello
(2) I<-A: ServerHello, Certificate, ServerHelloDone
(3) I->A:ClientKeyExchange, ChangeCipherSpec, Finished
(4) I<-A: ChangeCipherSpec, Finished
(5) I->A:ClientHello
(6) I<-A: ServerHello, Certificate, HelloDone
(7) I->A: Certificate, ClientKeyExchage, CertificateVerify,
ChangeCipherSpec, Finished
(8) I<-A: ChangeCipherSpec, Finished

[NOTE: I excluded encrypted, exported, partially-established security
context tokens above, but you can imagine them being present.]

The acceptor will need a credential when processing input tokens at
(3) and (7).  It will need the same RSA private key in both cases.  In
all other cases the acceptor doesn't actually need a credential
(though the API requires that a credential handle be passed in, of
course).

Now let's imagine that the acceptor exports the partially established
sec context after producing every context token and re-imports it
before consuming the next input context token.  Let's also stipulate
that the acceptor uses a different credential handle on every call to
GSS_Accept_sec_context(), but for the same underlying credential.

At (3) and (7) the acceptor has access to the actual private key
that's in an HSM, so in both cases it can decrypt the
ClientKeyExchange -- it has access to that private key even though the
input credential handles are different because they are different
handles for the _same_ credential.

Why wouldn't that work?  What am I missing?  (Note that I tackle
clusters below.)

Now let's consider a scenario with clustered acceptors using the same
acceptor name for all acceptors in the cluster.  This is where we get
into trouble, because for the above imaginary mechanism we could have
N server certs, each with different public keys but the same name, and
with each acceptor having only one cert and private key.  If we do
that then the initiator's ClientKeyExchange payloads will not decrypt
if sent to an acceptor whose cert isn't the one sent in the
Certificate payload that preceded the initiator sending its
ClientKeyExchange.

If one uses key agreement and RSA signatures, then this problem
doesn't happen at all -- each server can have different keys, as long
as they all have certs for the same Name.

There's two obvious answers to this clustering problem: a) don't use
key transport if you want to cluster with different keys on each
cluster member, or b) make sure all the cluster members have the same
keys.  (There's a third option too: the acceptor at (3) and (7) can
just ask the cluster members whose certificates the client got at (2)
and (6) to decrypt the ClientKeyExchange payloads.)  I believe we'll
have similar options for other mechanisms.

That's a pretty complex mechanism, and I showed that it should be
possible to export partially established sec contexts for it.  Next we
could do the same for all mechanisms that we actually know of, and see
if there's any for which it might not be possible to export partially
established sec context, or what constraints must be accepted in order
for it to be possible.

> GSS-API and its semantics should be entirely irrelevant to the KDC.

Not if we're considering the use of GSS for Kerberos pre-authentication.

> facility could be provide at the GSS-API level.

We have done so.  We need a way to handle GSS context token exchanges
with no acceptor-side state.  This requirement comes about from
wanting to use the GSS-API in protocols that require stateless-ness on
the server side.  Yes, we could simply say "the GSS-API cannot be used
in such a case", but as you'll see below, that's not actually useful.

> "If the only tool you know is a hammer, everything looks like a nail to you."

We have many authentication hammers in the IETF.  We can always invent
new ones.  I prefer to use the ones we have whenever possible.

It's funny that if we pursued Kerberos with SASL pre-authentication
you'd likely say nothing because SASL lacks a detailed abstract API.
You'd not say "you can't export partially established SASL security
contexts because the API doesn't allow it".  If you said anything
you'd likely focus on whether that's feasible in actuality, as opposed
to what the API says (since there is no API).

The question is NOT whether this or that authentication API allows for
server-side stateless-ness.  The question is whether it is possible to
have multi-round-trip security mechanisms in _any_ framework in a way
that is server-side stateless.

Please take the API blinders off and think of the actual mechanisms
and protocols.  I understand that you feel that API constraints are
there for a reason, but if you use that only to preclude discussion
then that's not useful.

> in a session cookie _before_ the TLS handshake is complete!

I'm aware.  The TLS thing is a ticket, and the client has to know the
session key that's in it.  It's very Kerberos-like in this sense.  We
cannot do anything like this in the GSS-API with exported security
context tokens.  We agree on this.

I stop here because this is getting entirely too long.  I do hope you
get to the part about thinking about mechanisms rather than APIs.

Nico

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 10:52:10 -0500

On Fri, May 6, 2011 at 10:16 AM, Rafa Marin Lopez <[email-masked]> wrote:
> It is clear what RFC 6113 says about this. But it is not less certain that,
> as already stated, exporting partially established security contexts is not
> allowed by RFC 2743. Also Martin also did a really good analysis about
> exporting partially established security contexts in
> https://lists.anl.gov/pipermail/ietf-krb-wg/2011-May/009093.html

I just responded to Martin's post.  I don't agree with him.  The
matter needs more discussion.

Nico

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 10:53:20 -0500

> Don't you think analysis in https://lists.anl.gov/pipermail/ietf-krb-wg/2011-May/009093.html may affect?

Don't you think you should see my reply to it before you give up?

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 6 May 2011 19:23:25 +0200

Hi Nico,

Sure!!!. But it happened that I sent this e-mail BEFORE you sent your reply to Martin :S. Let me check your reply carefully.

Thanks.

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 12:33:26 -0500

> Sure!!!. But it happened that I sent this e-mail BEFORE you sent your reply to Martin :S. Let me check your reply carefully.

Heh.  True dat.  I took my sweet time answering Martin.  My apologies.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 6 May 2011 20:46:02 +0200

Hi Luke, 

> If the challenge and challenge response are passed to the infrastructure in a single request (as in the case of NTLM, Digest, etc) this should be straightforward. Unless you were thinking of someth…

I was just thinking that it may not be sufficient in the next sense: what happens if the client sends that challenge and the response 1 year later?. Basically the KDC will accept that as valid. Usually in a challenge-response authentication protocol there is a timeout period between messages to avoid this. So basically in the exported partial session context a timestamp should be also provided to determine that a message with the challenge response from the client exceeded that timeout period.

---

From: Martin Rex <[email-masked]>
Date: Sat, 7 May 2011 00:39:14 +0200 (MEST)

> the same credential _handle_.  I hardly think this is a problem.

Then you're misreading the existing spec, it MUST be the exact same cred
handle on all iteration calls, and the same applies to all other
function parameters that I listed -- you have to provide the
EXACT SAME values, pointer and handles.  This is especially tricky
for dynamic output parameters, such as the "src_name" parameter
on gss_accept_sec_context().  If you have a 3- or 4-token mechanism,
where gss_accept_sec_context() must be called twice, the src_name
might be filled on the first call by some and on the second call
by other gssapi mechanisms.  

> > like when it is on a hardware token. Â With hardware tokens and HSMs

because it would be impossible to provide the same handle on the
iteration call, and other KDCs will not have access to that token
at all, so could not not even create another handle to this cred.

> initial handshake.

Renegotiation?  It would be very weird in a kerberos preauth scenario
to NOT request a client cert in the initial handshake and require
a renegotiation, and a big waste of resources...

And I really don't want to think about how rfc5746 (TLS secure renego)
interacts with your suggested renegotiation with moving around of
TLS state, because I think it is undefined.

> And let's imagine that we're using RSA key
> (3) I->A: Certificate, ClientKeyExchange, CertificateVerify,

That is incorrect.  The acceptor will need access to the credential on
both iteration calls of gss_accept_sec_context.  In (2) to check for
availability of the credential and retrieve the credentials certificate
carrying the public part of the credential and an optional cert chain
in order to compose the (Server)Certificate Handshake message.
On the second iteration call in to gss_accept_sec_context() in (3),
the acceptor will need access to the very same credential in order
to process the ClientKeyExchange (RSA Premaster Secret) with the
private key part of the message.

Some folks like hardware tokens so much that they use them with
unique keypairs that are generated on the token, in which case
distinct servers will always have distinct credentials.
And this has nothing to do with clusters, only secondary KDCs.

And do you know about the bogosity in rfc5246 (TLSv1.2) about the
handshake message hash that goes into the handshake message hash
of the CertificateVerify handshake message in (3) above.  Because
of the uncertainty of which hash algorithm the Client will choose
for the Signature, the current conclusion is for some (that offer TLSv1.2)
to keep all handshake messages around until the CertificateVerify
handshake message is received and the server discovers which hash
algorthim to use, or for others (Microsoft) to disable TLSv1.2 on
the server side because of this nonsense...

> established sec context, or what constraints must be accepted in order

You seem so entrenched in your thinking that you seem to have lost
the motiviation behind the existence of GSS-API.

GSS-API was meant to be an architecture where you could pick an
existing APP and an existing mechanism implementation and have
them interoperate.  Binary plug-n-play, meet-in-the-wild when
taken to the extreme.

Now your saying, that you could come up with a huge list of additional
constraints, and if gssapi mechanisms could be completele redesigned
from ground up to meet these constraints, then you could use them
to build an extremely complex, awkward and brittle pre-authentication
for Kerberos that would be stateless on the KDC.  It would be
susceptible to replay of the gssapi authentication, but Kerberos
folks have become accustomed to believing that this is not a
security problem for AS_REQ/AS_REP exchanges.

> in such a case", but as you'll see below, that's not actually useful.

I think you're artificially inflating the issue.  As I've said in
a previous EMail, an authentication exchange that wants to protect
against authentication replay will require server-side state,
either in form of a challenge-response or a replay-cache.
And we are _expecting_ GSS-API mechanisms to be safe against
authentication replay.

I don't see why you have to establish the server side of the
gssapi security context within the Kerberos KDC process itself.
In particular, if you believe in mechglue and mechanism stacking/plugging,
you should really not looking at doing that within the KDC, but within
a seperate helper process instead.  If I was the maintainer of a
KDC codebase, I would fight hard against not having to load and call
a large number of gssapi mechanisms from various sources into
the KDC process space.

And keeping server-side state over complete authentication exchanges
(usually 2-4 round-trips) is something that is extremely common for
the rest of the world, so it should be doable for a helper process
running on a KDC without the sky falling down.

Btw. for those mechanisms where authentication replay protection
is kind of an add-on, it might be much easier to define a new
context attribute "GSS_C_REPLAYOK_FLAG" that causes a gssapi
mechanism to ignore the replay protection and to add to each
context tokens all previous context token so that on the
final call to gss_accept_sec_context(), the whole exchange
can be processed at once.  For GSS-API mechs, where replay
protection is an intrinsic feature, this might require some
small, but pretty dirty code changes.

> new ones.  I prefer to use the ones we have whenever possible.

You are actually asking to dump the existing ones and rewrite them
with significantly more complex requirements to support transfer
of partially established security contexts.

I've seen a number of proposals to enhance TLS with new handshake
messages, but your proposal to hack up GSS-API beats this by
a big margin in deviating from the original architecture.

> contexts because the API doesn't allow it".

I fully agree that it would be *MUCH* easier for each and every
authentication exchange that you have been looking at to take
the GSS-API wrapper away from it and map it message primitves
natively to your design requirements.

>
> If you said anything you'd likely focus on whether that's feasible
> in actuality, as opposed to what the API says (since there is no API).

It would be possible to operate each computer with a keyboard that
has only three keys "0", "1", "Enter".  And a touring machine is
able to compute any result that a modern workstation is able to
compute.  Strange that so few folks are using that stuff, isn't it.

> that is server-side stateless.

Only if (a) replay of authentication exchanges is something you can
solve by simply ignoring it and (b) you can convince the gssapi
mechanism providers to offer you a mode of operation with
authentication replay protection disabled.

Asking for "export of partially exported contexts" is not a very
honest way to ask for please hack your mechanism to allow me
authentication replays.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 May 2011 18:23:50 -0500

On Fri, May 6, 2011 at 5:39 PM, Martin Rex <[email-masked]> wrote:
> [...]

No.  You're misreading what I wrote.  I'm trying to examine this idea
from the protocol point of view, not what RFC2743 says.  The latter is
NOT useful to actually innovating unless it explains why the
innovation in question is fundamentally flawed.  I asked you to stop
looking at things through the API prism.  It'd be one thing for you to
argue the appropriateness of not looking at things through the API
prism, but it's another altogether to just ignore that request.

> at all, so could not not even create another handle to this cred.

I don't agree.  Why do I not agree?  Because it is possible to
provision multiple HSMs with the same key paterial on board.  Quite
aside from that, in specific mechanisms it's possible to use public
key signatures instead of public key encryption or secret key
encryption to avoid the need to provision the same keys on multiple
HSMs.  Quite aside from that, each member of a cluster could ask the
one that does have the correct key material to apply whatever
cryptographic operation on behalf of the first.  The first option is
affects deployment; the second affects mechanism implementation.

This is nothing new either.  The need to share credentials amongst
cluster members, with all that that implies regarding HSMs, already
exists.  For example: NFS server clusters (whether active-active or
active-passive) regularly need to have credentials shared amongst
their members.  This happens TODAY.  There is NOTHING new here,
contrary to what you state below.

> a renegotiation, and a big waste of resources...

So, here I am trying to setup a thought experiment.  The details
aren't too important -- they are contrived for a specific purpose: to
construct an experiment with certain properties.  Can we please not
get stuck on those details?  They are contrived.  Let's argue over
whether some other contrived mechanism would be a better basis for
this analysis.

> in order to compose the (Server)Certificate Handshake message.

Sure, but the certificate is public.  From a protocol point of view
the credential is the private key, and that's only needed at the
points that I indicated.  Remember, I'm trying to establish whether a
proposal is secure from a protocol point of view.  The API point of
view will come later.

> And this has nothing to do with clusters, only secondary KDCs.

I understand that.  See my comments above and earlier regarding HSMs.

> [...]

Irrelevant.

> the motiviation behind the existence of GSS-API.

I don't agree.  From my point of view you seem stuck on preventing
innovation in the GSS-API.  Yet I think we can manage to communicate
effectively if we just try.  I'm trying.

> security problem for AS_REQ/AS_REP exchanges.

Not at all.  I'm adding no constraints.  I'm not even adding
constraints regarding HSM deployment.  As I've described above, HSMs
are a solvable problem, and the problem already exists -- it's not
new.

> either in form of a challenge-response or a replay-cache.

I agree with that.

> And we are _expecting_ GSS-API mechanisms to be safe against

In the case of the Kerberos KDC protocol that's not necessary.  In the
case of GSS-REST it sure is.

(For GSS-REST, strictly speaking, I don't need stateless-ness, but I
do still need the ability to export partially established sec
contexts, and no, I don't mind if that isn't entirely stateless under
the hood (e.g., a process is left behind to hold a sec context, that
later gets called from whatever cluster member needs to import the
context.)

I'll answer the rest later; the above should do for now.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 09 May 2011 13:23:33 +0200

Hi Sam,

Initially, the idea was to seek review comments but we would not have 
any problem to give up change control to the IETF
if the Kerberos WG is interested in this work. Regarding the editorship, 
I could remain as editor if it were adopted. However,
it is important to mention that we may only attend physically to one-two 
IETF meetings per year.

Regards,
Alejandro

>>>>>> "Alejandro" == Alejandro Perez Mendez<[email-masked]>  writes: