Subject: draft-lha-gssapi-delegate-policy-00.txt

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 18 Aug 2008 14:44:15 +0100

Hello,

I would like to propose the following work to be taken up in the
working group

http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-
policy-00.txt

Abstract

   Several GSS-API applications work in a multi-tiered architecture,
   where the server takes advantage of delegated user credentials to
   act on behalf of the user and contact additional servers.  In
   effect, the server acts as an agent on behalf of the user.  Examples
   include web applications that need to access e-mail or file servers
   as well as CIFs file servers.  However, delegating the ability to
   act as a user to a party who is not sufficiently trusted is
   problematic from a security standpoint.  Kerberos provides a flag
   called OK-AS- DELEGATE that allows the administrator of a Kerberos
   realm to communicate that a particular service is trusted for
   delegation.  This specification adds support for this flag and
   similar facilities in other authentication mechanisms to GSS-API
   (RFC 2743).

Love

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Mon, 18 Aug 2008 13:43:16 -0400

On Mon, 18 Aug 2008 14:44:15 +0100
Love Hörnquist Åstrand <[email-masked]> wrote:

> http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-00.txt

I would much prefer that clients respect the policy first and
only deviate from that behavior unless specifically instructed
(e.g. GSS_C_DELEG_IGNORE_POLICY_FLAG).

I realize this would be a change in behavior for existing code but I
think network admins would welcome it. A violation of The Principal
of Least Surprise is not a sufficient reason for perpetuating a weak
default security policy.

To maintain the old behavior, there could be a setting in krb5.conf
like:

  [libdefaults]
      gssapi_deleg_ingore_policy = true;

This property would also be useful for clients who's KDCs do not
support OK-AS-DELEGATE.

Again, of course the default value for this property should be false to
indicate OK-AS-DELEGATE should be respected first unless specifically
instructed otherwise.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 18 Aug 2008 21:39:52 +0100

> (e.g. GSS_C_DELEG_IGNORE_POLICY_FLAG).

Yes, I think that would be preferable, but this idea meets much
resistance when I propose it. IMO think its a better idea to actually do
something else about then fight about already existing semantics.

Love

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 19 Aug 2008 08:12:38 +1000

> something else about then fight about already existing semantics.

Except they are only existing semantics on Unix, not windows, which is
the majority of krb5 clients these days.  Can we try it one more time?

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 18 Aug 2008 23:24:33 +0100

> the majority of krb5 clients these days.  Can we try it one more time?

Its not the semantics for Unix, its the semantics for GSS-API.

You are talking about the semantics for SSPI/Kerberos. The new
flag gives the same semantics that the SSPI flag.

We don't get around that changing the flag break stuff.

With MIT kerberos you can't set the flag in the KDB w/o redeploying
code, these are the people you need to convince this is a good idea.

Love

---

From: Michael B Allen <[email-masked]>
Date: Mon, 18 Aug 2008 21:37:12 -0400

On Mon, 18 Aug 2008 23:24:33 +0100

> code, these are the people you need to convince this is a good idea.

The OK-AS-DELEGATE flag issue with legacy KDCs is a Kerberos issue and
should not be addressed by pushing the problem into GSSAPI.

Mike

---

From: Tom Yu <[email-masked]>
Date: Mon, 25 Aug 2008 10:51:32 -0400

> should not be addressed by pushing the problem into GSSAPI.

While OK-AS-DELEGATE may be a Kerberos-specific issue, the problem of
finer-grained control over credential delegation is a general GSS-API
problem.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Tom Yu <[email-masked]>
Date: Mon, 25 Aug 2008 11:02:12 -0400

* I see no explicit mention, but is GSS_C_DELEG_POLICY_FLAG ever to be
  set by accept_sec_context?

* The new flag GSS_C_DELEG_POLICY_FLAG appears to request delegation
  regardless of whether GSS_C_DELEG_FLAG is set, and setting
  GSS_C_DELEG_FLAG in combination with GSS_C_DELEG_POLICY_FLAG appears
  to request an override of centrally administered policy.  This is a
  somewhat non-obvious behavior.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 25 Aug 2008 16:37:58 +0100

>  set by accept_sec_context?

Does it matter to the server if delegation was allows by policy or not ?

I think GSS_C_DELEG_POLICY_FLAG should never seen on wire, but I  
really dont care too much about this, either way is fine.

>  somewhat non-obvious behavior.

It preserves the old behavior of the GSS_C_DELEG_FLAG.

0 - no delegate
DELEG - always delegate
DELEG_POLICY - delegate if policy allows
DELEG | DELEG_POLICY -  always delegate, but do tell client if it was  
allowed by policy.

So a client that want to follow the policy of the site, can always  
specify DELEG_POLICY

Love

---

From: Tom Yu <[email-masked]>
Date: Mon, 25 Aug 2008 12:07:14 -0400

> really dont care too much about this, either way is fine.

I also don't care too much either way, but since flags can get output
on the acceptor side, I think we should explicitly mention what
happens.

> It preserves the old behavior of the GSS_C_DELEG_FLAG.

RFC2743 and RFC2744 are not so clear on the "always delegate"; they
indicate that the DELEG_FLAG is a request.  It is possible to read the
RFCs as allowing an implementation to apply policy and cause
init_sec_context to decline the delegation request.  In such a case,
DELEG_POLICY_FLAG is not sufficient to allow the application to
override policy.

I suggest that we provide an additional flag to allow applications to
override a centrally administered policy prohibiting delegation.

> DELEG_POLICY - delegate if policy allows

If this is set without DELEG_FLAG being set, then no delegation takes
place if the implementation does not understand DELEG_POLICY_FLAG.
This is probably desired.

> So a client that want to follow the policy of the site, can always

Unless the client assumes an implementation where setting DELEG_FLAG
alone requests "delegate if permitted by policy".
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Mon, 25 Aug 2008 12:37:14 -0400

On Mon, 25 Aug 2008 10:51:32 -0400

> finer-grained control over credential delegation is a general GSS-API

Tom,

I did not say OK-AS-DELEGATE is an issue. I said legacy KDCs that do
not understand OK-AS-DELEGATE are an issue. If there were no such KDCs,
clearly GSS_C_DELEG_POLICY_FLAG would not have been proposed.

If you want finer-grained control over delegation, then use a
GSS_C_DELEG_IGNORE_POLICY_FLAG to accomplish what you want (but I think
it would be a lot cleaner to use a "gssapi_deleg_ignore_policy" property
in the client's krb5.conf to maintain old behavior).

I don't think any of this has any effect on my code so this will be
the last you hear from me on the topic. But I just have to say, I don't
like to see insecure default security policy being proposed as an IETF
standard because a handful of admins are too lazy to add a setting to
their client krb5.confs.

Now whenever someone posts their GSSAPI example on the kerberos mailing
list, someone will have to chime in with "oh, by the way you have to
set the GSS_C_DELEG_POLICY_FLAG too" and then get gaffed explaining why.

Mike

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 25 Aug 2008 18:28:40 +0100

> on the acceptor side, I think we should explicitly mention what

ok, will do.

> DELEG_POLICY_FLAG is not sufficient to allow the application to

But that is not how some of people that made implementation for  
kerberos have read it.'

If it is how you say, then we don't need DELEG_POLICY_FLAG. And are  
all done.

If you change your implementation to behave like that, how far would  
you make it down the Vassar street before some disgruntal sysadmin  
catches you with a bat ?

> override a centrally administered policy prohibiting delegation.

I would say that that is DELEG_FLAG flag. I think its a bad idea to  
introduce even more flags and knobs.

> alone requests "delegate if permitted by policy".

Right, any implementation like that except SSPI ?

Love

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Aug 2008 20:07:59 +0200 (MEST)

> > Does it matter to the server if delegation was allows by policy or not ?

I also don't think this should matter to the acceptor. :)

> on the acceptor side, I think we should explicitly mention what

It will be just fine to define this flag as a local flag, i.e. something
that is communicated only between the local app and the local gssapi
mechanism and not across the wire.  There are already two other flags
which are completely local: GSS_C_TRANS_FLAG and GSS_C_PROT_READY
(but the spec may be lacking that these are local flags).

> DELEG_POLICY_FLAG is not sufficient to allow the application to

Correct, asserting the flag is a mere request.

(Honestly, I haven't considered the exact details of the spec) but my
recollection is this is a local issue, i.e. possible reasons why
a requested delegation of credentials is not performed are
  - delegation of credentials is not defined for this mechanism
  - delegation of credentials is defined the the mechanism, but
    not implemented by the current mechanism implementation
  - delegation of credentials is prohibited by local policy
  - delegation of credentials is not possible due to technical reasons
    (i.e. the local credentials may not be valid anywhere else,
     or it may be impossible to transfer them, because they are
     bound to token hardware)

> override a centrally administered policy prohibiting delegation.

I do not take a position here.  Delegation of credentials is a can
of worm that I don't like to be opened where it can be avoided.

I principle I see a conceptually difference in forwarding a credentials
(e.g. when doing a remote login of some kind) and when doing a real
delegation of a credential to some server that decides autonomously
what it is going to do with the delegated credentials.  For the latter,
a constrained delegation might be preferable, but that is a complex
topic that is likely to result in long discussions (rat hole, can of worms).

> alone requests "delegate if permitted by policy".

When trying "credential forwarding" for remote login, the user may
have a workaround for "policy problems", by recreating (software)
credentials on the remote machine.

IIRC, the primary purpose of "OK_AS_DELEGATE" was to restrict the
number of targets/services which will be able to obtain delegated
credentials, because it was assumed that the application might
not be in the position to perform a sensible/safe decision (blindly
assert the flag, sometimes due to the number of abstraction
layer between "APP" and GSS-API/SSPI), and that the user would
also often not be in the position to do a sensible decision
(and normally should better NOT be bothered with such a decision).

This might not apply to all users and all usage scenarios, but
it was anticipated to apply to a non-negligable amount of users
and usage scenarios, and that it might be quite easy for attackers
to cause delegation to services under their control without
a central policy setting.

-Martin