Delegation and Moonshot

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Delegation and Moonshot

Luke Howard
I wanted to describe some interesting work in bringing delegation to Moonshot. (Well, at least I think it's interesting :-)) I've tried to keep this as high level as possible, but unfortunately it does require a bit of an understanding of GSS-API, Kerberos and SAML. I've used the terms "client" and "service", but you can read "initiator" and "acceptor" or "peer" and "AAA client". I'm cross-posting to krbdev, because the code involved here is all to do with MIT Kerberos; there are no changes to the Moonshot GSS mechanism.

So, delegation is useful when you have ono service that needs to contact another on behalf of a client, and you want to do end-to-end authentication. For example, consider a webmail service that gateways to an IMAP server. I'm sure there are more interesting examples.

With Kerberos, there are a couple of ways to do delegation. The modern approach is so-called "constrained delegation". This allows a service to delegate to a fixed set of other services (determined by KDC policy). At the GSS-API level, the service uses the delegated credential handle returned by gss_accept_sec_context() to create a security context for accessing the back-end service. At a protocol level, the service presents the KDC with the client's ticket, and asks for another one on its behalf to access the backend service. Unfortunately, this only works if the client originally authenticated with Kerberos.

What happens if the client authenticated with another protocol, such as GSS EAP? (For example, Moonshot in Firefox.) Well, it turns out there's a solution for this, too: protocol transition. This allows a service, trusted by the KDC to have authenticated a client by some other means, to acquire a ticket to itself; that ticket can then be used for constrained delegation to another service. The protocol is a variation on the normal ticket request protocol, including an additional field indicating the client on whose behalf the service is acting.

This is all very well, but protocol transition only provides a ticket with the client's name; the rich authorisation semantics provided by SAML in Moonshot are lost. Here's a proposal to allow protocol transition with "assertion transition". Apart from a couple of bugfixes, it doesn't require any source-level changes to MIT Kerberos (and the bugfixes are in the libraries only, not the KDC). The remainder is provided by two plugins: a library plugin that runs on the services, and a KDC plugin.

We define a new authorisation data type, KRB5_AUTHDATA_SAML, that contains a SAML assertion. Moonshot aside, KDCs are free to issue assertions based on their own information. An AAA server that supports services doing "assertion transition" signs assertions with a key shared between it and the KDC. (The AAA service is an ordinary service principal registered with the KDC. The signatures are XML DSIGs as specified by SAML.) In the Moonshot model, the AAA server vouches for assertions that it issues or forwards to the service; here, we extend this to other services in the KDC's realm.

A service doing "assertion transition" makes a normal protocol transition request to a KDC that has the SAML plugin installed. (A KDC without this plugin will copy the assertion into the response, but the service will not be able to validate it.) The KDC validates the AAA server's assertion signature, verifies that local policy permits it to vouch for the assertion, and returns the assertion in the issued ticket (this time signed with the ticket session key, and ultimately encrypted with the service's long term key).

The service receives the protocol transition ticket and validates the assertion (amongst other things, checking the signature). It can now surface the assertion, but this isn't particularly useful because the ticket is to itself. In order to delegate to another service, it makes a constrained delegation request to the KDC; this time, the SAML plugin validates the assertion implicitly because it was signed by the KDC (see http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation for details).

The delegating service will receive a ticket from the client to the delegatee, which it submits in its application protocol (for example, IMAP). The backend-server can thus make authorisation decisions based on the attributes in the original assertion sent by the AAA server. In the IMAP example, this might determine which folders you're allowed to access.

Of course, this could be used with IdPs directly instead of a AAA server. I mentioned this topology here because it's relevant to Moonshot, and it has the nice property of not requiring a parallel PKI or Kerberos infrastructure to do delegation of federated identities within a Kerberos infrastructure. (For EAP identities outside the service realm, the anonymous Kerberos principal name can be used; this makes no difference to attribute-based authorisation.)

This all sounds complicated, but it's actually very easier from an application developer's perspective. The AAA server needs to be modified to sign the assertions, something which I haven't yet implemented (but it should be easy to piggyback on an AAA server that knows how to issue assertions). (In my testbed, the AAA server issued a fixed, signed assertion.)

The service itself just needs to do the following:

        // authenticate GSS EAP client
        do {
            gss_accept_sec_context(&client_name); // establish GSS EAP security context
        } while (status == GSS_S_CONTINUE_NEEDED);

        // acquire credential for GSS EAP client
        gss_acquire_cred(&impersonator_cred);
        gss_canonicalize_name(client_name, KRB5_MECH, &krb5_name);
        gss_acquire_cred_impersonate_name(client_name, &client_cred);

        // authenticate using Kerberos to backend service
        do {
            gss_init_sec_context(client_cred, ...); // establish Kerberos security context
        } while (status == GSS_S_CONTINUE_NEEDED);

The backend-service then does:

        // authenticate Kerberos client
        do {
            gss_accept_sec_context(&client_name); // establish GSS EAP security context
        } while (status == GSS_S_CONTINUE_NEEDED);

        gss_get_name_attribute(client_name, "some attribute");
        gss_get_name_attribute(client_name, "some other attribute");

If the delegating service wants to use anonymous names, then it's a few more lines of code (because you need to create a new name and copy the assertion explicitly), but if this was a common pattern we could probably do something (maybe overload the credential usage flags in gss_acquire_cred_impersonate_name(), or add a pseudo-mech to gss_canonicalize_name() that anonymised then canonicalised).

The observant reader will notice that there is some overlap with the fast reauthentication support provided by Moonshot, where the service mints a ticket to itself for use in subsequent authentication. This ticket cannot be used for constrained delegation, because it is not signed by the KDC. It is true that the service could use protocol transition to generate this ticket. I'm not sure at this stage whether this confers any advantages though (it requires changes to the Moonshot mechanism, and it requires a round trip to the KDC even if delegation is not desired). Sam will probably have more to say on this.

If you want to play with the code, it's in the users/lhoward/saml2 branch of MIT. gss-server has been enhanced to do protocol transition (I haven't committed the constrained delegation tests yet). You'll need to install the plugins in plugins/authdata/saml*.

-- Luke
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Nico Williams
On Sat, Apr 2, 2011 at 6:47 AM, Luke Howard <[hidden email]> wrote:
> I wanted to describe some interesting work in bringing delegation to Moonshot. (Well, at least I think it's interesting :-)) I've tried to keep this as high level as possible, but unfortunately it does require a bit of an understanding of GSS-API, Kerberos and SAML. I've used the terms "client" and "service", but you can read "initiator" and "acceptor" or "peer" and "AAA client". I'm cross-posting to krbdev, because the code involved here is all to do with MIT Kerberos; there are no changes to the Moonshot GSS mechanism.
>
> So, delegation is useful when you have ono service that needs to contact another on behalf of a client, and you want to do end-to-end authentication. For example, consider a webmail service that gateways to an IMAP server. I'm sure there are more interesting examples.

I don't mean to take anything away from this amazing work you've done,
but, credential delegation writ large is simply scary.  Better to
design services that don't require it.  For example, in the particular
case you mention of web gateways to mail services just trust the web
service fully and be done -- incredibly undesirable if the two
services are not run by the same organization, but then, would you
really delgate access to your mailboxes to a party other than the one
that runs them?!

THAT said... I would be particularly interested in your model of
attribute delegation coupled with MAC (Mandatory Access Controls).
Indeed, if the KDC (or whatever) can enforce policies to limit what
attributes can be delegated to services, then you have everything that
you need to call it MAC (well, almost: you still need access controls
performed by the back-end services to disallow the user the ability to
modify MAC controls).

That is, if credential delegation is at all necessary, then I'd like
it to be subject to MAC-like constraints.

Note that when I say "MAC" I don't mean MLS (multi-leve security)
necessarily -- I have Smack in mind in particular.  (In Smack label
dominance is policy driven rather than algorithmic.)

> [...]
>
> What happens if the client authenticated with another protocol, such as GSS EAP? (For example, Moonshot in Firefox.) Well, it turns out there's a solution for this, too: protocol transition. This allows a service, trusted by the KDC to have authenticated a client by some other means, to acquire a ticket to itself; that ticket can then be used for constrained delegation to another service. The protocol is a variation on the normal ticket request protocol, including an additional field indicating the client on whose behalf the service is acting.

Note that "a service, trusted by the KDC to have authenticated a
client by some other means" is a stunningly large degree of trust --
larger even than traditional Kerberos credential delegation.  However,
if the protocol transition involved signed SAML attributes...  I know,
that's where you're going with this :)

> This is all very well, but protocol transition only provides a ticket with the client's name; the rich authorisation semantics provided by SAML in Moonshot are lost. Here's a proposal to allow protocol transition with "assertion transition". Apart from a couple of bugfixes, it doesn't require any source-level changes to MIT Kerberos (and the bugfixes are in the libraries only, not the KDC). The remainder is provided by two plugins: a library plugin that runs on the services, and a KDC plugin.

Very cool.  (Also, a complete vindication of pluggable architectures!)

> We define a new authorisation data type, KRB5_AUTHDATA_SAML, that contains a SAML assertion. Moonshot aside, KDCs are free to issue assertions based on their own information. An AAA server that supports services doing "assertion transition" signs assertions with a key shared between it and the KDC. (The AAA service is an ordinary service principal registered with the KDC. The signatures are XML DSIGs as specified by SAML.) In the Moonshot model, the AAA server vouches for assertions that it issues or forwards to the service; here, we extend this to other services in the KDC's realm.

Right, so the XML signatures are key to constraining the degree of
trust the KDC must have in the services in question.  Excellent.

> [...]
> The delegating service will receive a ticket from the client to the delegatee, which it submits in its application protocol (for example, IMAP). The backend-server can thus make authorisation decisions based on the attributes in the original assertion sent by the AAA server. In the IMAP example, this might determine which folders you're allowed to access.

It'd be useful if the attributes delegated in this way could be
winnowed according to policy at the AAA server.  Is that possible?

> The service itself just needs to do the following:

Right, quite simple.  BTW, do we want to be able to gss_store_cred()
impersonation credentials?  I believe some will.  E.g., if you need to
use secure NFS, AFS, ... as the client, then you have no way to pass
the desired credential handle to the NFS or AFS client.  Being able to
create a PAG or keyring, or whatever, then store the credential there,
where the NFS or AFS client will find it, is a very good thing.  Where
the impersonation credential is a Kerberos one this is already taken
care of.  For other mechs it'll be something to think about.

> The backend-service then does:
>
>        // authenticate Kerberos client
>        do {
>            gss_accept_sec_context(&client_name); // establish GSS EAP security context
>        } while (status == GSS_S_CONTINUE_NEEDED);
>
>        gss_get_name_attribute(client_name, "some attribute");
>        gss_get_name_attribute(client_name, "some other attribute");

This reminds me.  In my original naming exts proposal I had an API for
"mapping" the attributes that appear explicitly to other attributes.
My goal was to export to the app the signed attribute payloads (PAC,
...) and then probide a way to extract the individual attributes'
values that are of interest to the app (SIDs, ...) and even map them
to other things that are locally meaningful (UIDs, GIDs, ...).

Given the raw attribute payloads, there's no reason for the mapping
API to be part of the GSS-API.  Except it'd be convenient to have one
family of specs (GSS) and one implementation provide both, the GSS-API
and the attribute mapping API.  Thoughts?  Should we revive that
mapping API?

> If the delegating service wants to use anonymous names, then it's a few more lines of code (because you need to create a new name and copy the assertion explicitly), but if this was a common pattern we could probably do something (maybe overload the credential usage flags in gss_acquire_cred_impersonate_name(), or add a pseudo-mech to gss_canonicalize_name() that anonymised then canonicalised).

Agreed.  Not a big deal (either way).

> The observant reader will notice that there is some overlap with the fast reauthentication support provided by Moonshot, where the service mints a ticket to itself for use in subsequent authentication. This ticket cannot be used for constrained delegation, because it is not signed by the KDC. It is true that the service could use protocol transition to generate this ticket. I'm not sure at this stage whether this confers any advantages though (it requires changes to the Moonshot mechanism, and it requires a round trip to the KDC even if delegation is not desired). Sam will probably have more to say on this.

That additional round-trip is not desirable, IMO.

Awesome work Luke!

Nico
--

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Russ Allbery
Nico Williams <[hidden email]> writes:

> I don't mean to take anything away from this amazing work you've done,
> but, credential delegation writ large is simply scary.  Better to design
> services that don't require it.  For example, in the particular case you
> mention of web gateways to mail services just trust the web service
> fully and be done -- incredibly undesirable if the two services are not
> run by the same organization, but then, would you really delgate access
> to your mailboxes to a party other than the one that runs them?!

Having done this for years, it does mostly work, but it has a serious
drawback: it requires that you do authorization control at multiple
levels.  Properly managed delegation systems can instead allow you to do
authorization control only once.

The best way to see this is to consider LDAP as the final destination
service.  OpenLDAP, and probably other LDAP implementations, supports
extremely complex access controls with many features, such as making
access contingent on both the authenticating identity and on the values of
other fields in the same object that one is trying to read fields from.
We use those sorts of features here to implement user-chosen visibility.
For example, may of our LDAP ACLs will release data if the corresponding
suVisib attribute is set to stanford, but not if it's set to private;
then, the data is only visible to specific privileged users or
applications.

If you have other software that uses LDAP to present information to a
user, you now have to duplicate this extremely complex logic in every
single application that may serve users with varying degrees of authorized
access.  If you want phone numbers to have user-settable privacy but
always display them to Help Desk staff, for example, everything that
displays phone numbers now has to look up the corresponding visibility
settings and confirm that the current authenticated user has access based
on those settings.  If, however, you have delegated credentials, you can
set the ACLs once on the LDAP servers and then everything just inherits
them.

The same issues do apply to services other than LDAP, in other ways, but
they're the most obvious with LDAP.

> Right, quite simple.  BTW, do we want to be able to gss_store_cred()
> impersonation credentials?  I believe some will.  E.g., if you need to
> use secure NFS, AFS, ... as the client, then you have no way to pass the
> desired credential handle to the NFS or AFS client.  Being able to
> create a PAG or keyring, or whatever, then store the credential there,
> where the NFS or AFS client will find it, is a very good thing.  Where
> the impersonation credential is a Kerberos one this is already taken
> care of.  For other mechs it'll be something to think about.

Yes.  This is required to implement things like a web-based front-end to
AFS.  It is one of the main places we use delegation right now.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Luke Howard
In reply to this post by Nico Williams

> winnowed according to policy at the AAA server.  Is that possible?

Sure, or ditto at the KDC. Obviously, there's a convenience vs privacy tradeoff: the AAA server needs to include in the assertion any attributes that may be required by delegatees, and these will be visible to the delegating service. If this is unacceptable, a model where the KDC contacts the IdP is better.

> values that are of interest to the app (SIDs, ...) and even map them
> to other things that are locally meaningful (UIDs, GIDs, ...).

I think this could be better done with something like Shibboleth and mapping to the local (non-URN) namespace. We have this working with Moonshot and OpenSSH/OpenLDAP authorization and it works well.

That said, map to any is implemented by MIT. Not by Heimdal though.

-- Luke
>

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Nico Williams
In reply to this post by Russ Allbery
On Sun, Apr 3, 2011 at 11:23 PM, Russ Allbery <[hidden email]> wrote:

> Nico Williams <[hidden email]> writes:
>
>> I don't mean to take anything away from this amazing work you've done,
>> but, credential delegation writ large is simply scary.  Better to design
>> services that don't require it.  For example, in the particular case you
>> mention of web gateways to mail services just trust the web service
>> fully and be done -- incredibly undesirable if the two services are not
>> run by the same organization, but then, would you really delgate access
>> to your mailboxes to a party other than the one that runs them?!
>
> Having done this for years, it does mostly work, but it has a serious
> drawback: it requires that you do authorization control at multiple
> levels.  Properly managed delegation systems can instead allow you to do
> authorization control only once.

In exchange you get one more thing to manage: credential delegation
policies.  Such policies might be as simple as one more bit
per-principal (trusted-for-delegation), or quite complex if you want
to reduce attributes across delegation boundaries.  One of the nice
things about a model like Smack is that you would be able to constrain
delegation in a simple way, requiring just one additional item
per-principal: a label (plus, when you need to create additional
labels, additional Smack rules, but hopefully you can manage to keep
those to a minimum).

> The best way to see this is to consider LDAP as the final destination
> service.  OpenLDAP, and probably other LDAP implementations, supports
> extremely complex access controls with many features, such as making
> access contingent on both the authenticating identity and on the values of
> other fields in the same object that one is trying to read fields from.
> We use those sorts of features here to implement user-chosen visibility.
> For example, may of our LDAP ACLs will release data if the corresponding
> suVisib attribute is set to stanford, but not if it's set to private;
> then, the data is only visible to specific privileged users or
> applications.
>
> If you have other software that uses LDAP to present information to a
> user, you now have to duplicate this extremely complex logic in every
> single application that may serve users with varying degrees of authorized
> access.  If you want phone numbers to have user-settable privacy but
> always display them to Help Desk staff, for example, everything that
> displays phone numbers now has to look up the corresponding visibility
> settings and confirm that the current authenticated user has access based
> on those settings.  If, however, you have delegated credentials, you can
> set the ACLs once on the LDAP servers and then everything just inherits
> them.

Oh, this is a very good example.  I like it a lot, and I'll probably steal it :)

In the example I've used most often in the past (NFS), impersonation
is still used, but without credential delegation: you just trust the
service to impersonate anyone.  This applies to LDAP too!

> The same issues do apply to services other than LDAP, in other ways, but
> they're the most obvious with LDAP.

I think it's the same problem in all cases.  Not using credential
delegation does not mean not using impersonation.

>> Right, quite simple.  BTW, do we want to be able to gss_store_cred()
>> impersonation credentials?  I believe some will.  E.g., if you need to
>> use secure NFS, AFS, ... as the client, then you have no way to pass the
>> desired credential handle to the NFS or AFS client.  Being able to
>> create a PAG or keyring, or whatever, then store the credential there,
>> where the NFS or AFS client will find it, is a very good thing.  Where
>> the impersonation credential is a Kerberos one this is already taken
>> care of.  For other mechs it'll be something to think about.
>
> Yes.  This is required to implement things like a web-based front-end to
> AFS.  It is one of the main places we use delegation right now.

Good to know.

Nico
--

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Nico Williams
In reply to this post by Luke Howard
On Sun, Apr 3, 2011 at 11:38 PM, Luke Howard <[hidden email]> wrote:
>> winnowed according to policy at the AAA server.  Is that possible?
>
> Sure, or ditto at the KDC. Obviously, there's a convenience vs privacy tradeoff: the AAA server needs to include in the assertion any attributes that may be required by delegatees, and these will be visible to the delegating service. If this is unacceptable, a model where the KDC contacts the IdP is better.

I thought about the KDC doing the winnowing, but surely the issuer of
the assertion is best placed to do the winnowing, and if another party
does it then the issuer has to trust it.  Now, for attributes asserted
by the KDC, sure, by my logic the KDC would have to do the winnowing.

>> values that are of interest to the app (SIDs, ...) and even map them
>> to other things that are locally meaningful (UIDs, GIDs, ...).
>
> I think this could be better done with something like Shibboleth and mapping to the local (non-URN) namespace. We have this working with Moonshot and OpenSSH/OpenLDAP authorization and it works well.

I guess it's time for me to take a deep dive into Shibboleth... But
not anytime soon :(

Can Shibboleth be made to pick apart the PAC?

> That said, map to any is implemented by MIT. Not by Heimdal though.

Think it can be made to handle the PAC cleanly?

Nico
--

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Luke Howard
If you want to pick apart the PAC, I would do it with the MIT libkrb5 plugin interface. See the code that already does that to some extent. If you want to process the picked apart PAC with policy to map it to UIDs, then either this interface or Shibboleth might be candidates.

-- Luke

Von meinem iPhone gesendet

Am 04/04/2011 um 14:48 schrieb Nico Williams <[hidden email]>:

> On Sun, Apr 3, 2011 at 11:38 PM, Luke Howard <[hidden email]> wrote:
>>> winnowed according to policy at the AAA server.  Is that possible?
>>
>> Sure, or ditto at the KDC. Obviously, there's a convenience vs privacy tradeoff: the AAA server needs to include in the assertion any attributes that may be required by delegatees, and these will be visible to the delegating service. If this is unacceptable, a model where the KDC contacts the IdP is better.
>
> I thought about the KDC doing the winnowing, but surely the issuer of
> the assertion is best placed to do the winnowing, and if another party
> does it then the issuer has to trust it.  Now, for attributes asserted
> by the KDC, sure, by my logic the KDC would have to do the winnowing.
>
>>> values that are of interest to the app (SIDs, ...) and even map them
>>> to other things that are locally meaningful (UIDs, GIDs, ...).
>>
>> I think this could be better done with something like Shibboleth and mapping to the local (non-URN) namespace. We have this working with Moonshot and OpenSSH/OpenLDAP authorization and it works well.
>
> I guess it's time for me to take a deep dive into Shibboleth... But
> not anytime soon :(
>
> Can Shibboleth be made to pick apart the PAC?
>
>> That said, map to any is implemented by MIT. Not by Heimdal though.
>
> Think it can be made to handle the PAC cleanly?
>
> Nico
> --

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Nico Williams
On Mon, Apr 4, 2011 at 12:16 AM, Luke Howard <[hidden email]> wrote:
> If you want to pick apart the PAC, I would do it with the MIT libkrb5 plugin interface. See the code that already does that to some extent. If you want to process the picked apart PAC with policy to map it to UIDs, then either this interface or Shibboleth might be candidates.

The latter (I want the SIDs, the SIDs mapped to UIDs/GIDs, the homedir
UNC mapped to whatever, ...).

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Luke Howard
In reply to this post by Russ Allbery
Russ,

With the example you give, you might be interested in an OpenLDAP ACL plugin we've developed that lets you use GSS attribute value assertions - eg from a SAML assertion - as authorization subjects.

-- Luke


Von meinem iPhone gesendet

Am 04/04/2011 um 14:23 schrieb Russ Allbery <[hidden email]>:

> Nico Williams <[hidden email]> writes:
>
>> I don't mean to take anything away from this amazing work you've done,
>> but, credential delegation writ large is simply scary.  Better to design
>> services that don't require it.  For example, in the particular case you
>> mention of web gateways to mail services just trust the web service
>> fully and be done -- incredibly undesirable if the two services are not
>> run by the same organization, but then, would you really delgate access
>> to your mailboxes to a party other than the one that runs them?!
>
> Having done this for years, it does mostly work, but it has a serious
> drawback: it requires that you do authorization control at multiple
> levels.  Properly managed delegation systems can instead allow you to do
> authorization control only once.
>
> The best way to see this is to consider LDAP as the final destination
> service.  OpenLDAP, and probably other LDAP implementations, supports
> extremely complex access controls with many features, such as making
> access contingent on both the authenticating identity and on the values of
> other fields in the same object that one is trying to read fields from.
> We use those sorts of features here to implement user-chosen visibility.
> For example, may of our LDAP ACLs will release data if the corresponding
> suVisib attribute is set to stanford, but not if it's set to private;
> then, the data is only visible to specific privileged users or
> applications.
>
> If you have other software that uses LDAP to present information to a
> user, you now have to duplicate this extremely complex logic in every
> single application that may serve users with varying degrees of authorized
> access.  If you want phone numbers to have user-settable privacy but
> always display them to Help Desk staff, for example, everything that
> displays phone numbers now has to look up the corresponding visibility
> settings and confirm that the current authenticated user has access based
> on those settings.  If, however, you have delegated credentials, you can
> set the ACLs once on the LDAP servers and then everything just inherits
> them.
>
> The same issues do apply to services other than LDAP, in other ways, but
> they're the most obvious with LDAP.
>
>> Right, quite simple.  BTW, do we want to be able to gss_store_cred()
>> impersonation credentials?  I believe some will.  E.g., if you need to
>> use secure NFS, AFS, ... as the client, then you have no way to pass the
>> desired credential handle to the NFS or AFS client.  Being able to
>> create a PAG or keyring, or whatever, then store the credential there,
>> where the NFS or AFS client will find it, is a very good thing.  Where
>> the impersonation credential is a Kerberos one this is already taken
>> care of.  For other mechs it'll be something to think about.
>
> Yes.  This is required to implement things like a web-based front-end to
> AFS.  It is one of the main places we use delegation right now.
>
> --
> Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Luke Howard
In reply to this post by Nico Williams
BTW Nico MIT already has configurable delegation policy, similar to AD. Of course it could be more flexible.

-- Luke
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Nico Williams
In reply to this post by Nico Williams
On Sun, Apr 3, 2011 at 11:44 PM, Nico Williams <[hidden email]> wrote:

> On Sun, Apr 3, 2011 at 11:23 PM, Russ Allbery <[hidden email]> wrote:
>> Nico Williams <[hidden email]> writes:
>>> I don't mean to take anything away from this amazing work you've done,
>>> but, credential delegation writ large is simply scary.  Better to design
>>> services that don't require it.  For example, in the particular case you
>>> mention of web gateways to mail services just trust the web service
>>> fully and be done -- incredibly undesirable if the two services are not
>>> run by the same organization, but then, would you really delgate access
>>> to your mailboxes to a party other than the one that runs them?!
>>
>> Having done this for years, it does mostly work, but it has a serious
>> drawback: it requires that you do authorization control at multiple
>> levels.  Properly managed delegation systems can instead allow you to do
>> authorization control only once.
>
> In exchange you get one more thing to manage: credential delegation
> policies.  Such policies might be as simple as one more bit
> per-principal (trusted-for-delegation), or quite complex if you want
> to reduce attributes across delegation boundaries.  [...]

Hmmm, well, if the alternative to delegation is to allow impersonation
without delegation then that still requires managing who's allowed to
impersonate, which makes the above argument not a very good one!

What I want is very fine-grained control regardless of whether I were
relying on credential delegation impersonation without credential
delegation.  It's probably easier to decentralize such policy, but
only in the case of impersonation without credential delegation, since
the KDC needn't be involved in the former but must be involved in the
latter.  Imagine an authorization-data element, to be used in
Authenticators more often than in Tickets, that indicates that the
cname@crealm wants to impersonate some other principal...

Nico
--

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

PACs (was: Re: Delegation and Moonshot)

Luke Howard
In reply to this post by Nico Williams
On 04/04/2011, at 3:34 PM, Nico Williams wrote:

> On Mon, Apr 4, 2011 at 12:16 AM, Luke Howard <[hidden email]> wrote:
>> If you want to pick apart the PAC, I would do it with the MIT libkrb5 plugin interface. See the code that already does that to some extent. If you want to process the picked apart PAC with policy to map it to UIDs, then either this interface or Shibboleth might be candidates.
>
> The latter (I want the SIDs, the SIDs mapped to UIDs/GIDs, the homedir
> UNC mapped to whatever, ...).


If you wish to give the administrator knobs to configure the mapping, Shibboleth is a lot more flexible. But consider that you would probably still need a libkrb5 authdata plugin to decode the PAC buffers and surface them as individual GSS attributes. (Maybe this could be done as a Shibboleth plugin instead, I don't understand its architecture well enough to say. But I'm pretty certain it doesn't have a built-in NDR un-marshalling engine!

Your putative libkrb5 plugin could re-entrantly call krb5_authdata_get_attribute("urn:mspac:logon-info") and then it's a simple matter of NDR decoding that, converting the SIDs to strings, etc. I should really write this someday... but isn't the PAC a little circa 2001? :-)

-- Luke
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation and Moonshot

Russ Allbery
In reply to this post by Luke Howard
Luke Howard <[hidden email]> writes:

> With the example you give, you might be interested in an OpenLDAP ACL
> plugin we've developed that lets you use GSS attribute value assertions
> - eg from a SAML assertion - as authorization subjects.

Yeah, that's a good idea -- thank you.

Also, thank you to Nico -- I hadn't thought about impersonation without
delegation thoroughly enough.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: PACs (was: Re: Delegation and Moonshot)

Simo Sorce
In reply to this post by Luke Howard
On Tue, 5 Apr 2011 00:52:05 +1000
Luke Howard <[hidden email]> wrote:

> On 04/04/2011, at 3:34 PM, Nico Williams wrote:
>
> > On Mon, Apr 4, 2011 at 12:16 AM, Luke Howard <[hidden email]> wrote:
> >> If you want to pick apart the PAC, I would do it with the MIT
> >> libkrb5 plugin interface. See the code that already does that to
> >> some extent. If you want to process the picked apart PAC with
> >> policy to map it to UIDs, then either this interface or Shibboleth
> >> might be candidates.
> >
> > The latter (I want the SIDs, the SIDs mapped to UIDs/GIDs, the
> > homedir UNC mapped to whatever, ...).
>
>
> If you wish to give the administrator knobs to configure the mapping,
> Shibboleth is a lot more flexible. But consider that you would
> probably still need a libkrb5 authdata plugin to decode the PAC
> buffers and surface them as individual GSS attributes. (Maybe this
> could be done as a Shibboleth plugin instead, I don't understand its
> architecture well enough to say. But I'm pretty certain it doesn't
> have a built-in NDR un-marshalling engine!
>
> Your putative libkrb5 plugin could re-entrantly call
> krb5_authdata_get_attribute("urn:mspac:logon-info") and then it's a
> simple matter of NDR decoding that, converting the SIDs to strings,
> etc. I should really write this someday... but isn't the PAC a little
> circa 2001? :-)

If you are ok with GPLv3 code and depending on a yet unstable library
we have code in the forthcoming samba 4 release to allow easy
(un)packing of NDR data :)

Simo.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: PACs (was: Re: Delegation and Moonshot)

Luke Howard
> If you are ok with GPLv3 code and depending on a yet unstable library
> we have code in the forthcoming samba 4 release to allow easy
> (un)packing of NDR data :)


I think I'll stick with http://www.dcerpc.org/ -- given I worked on that code for quite a few years ;-)

-- Luke
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: PACs (was: Re: Delegation and Moonshot)

Volker Lendecke
On Wed, Apr 06, 2011 at 12:14:48AM +1000, Luke Howard wrote:
> > If you are ok with GPLv3 code and depending on a yet unstable library
> > we have code in the forthcoming samba 4 release to allow easy
> > (un)packing of NDR data :)
>
>
> I think I'll stick with http://www.dcerpc.org/ -- given I
> worked on that code for quite a few years ;-)

Last I heard was that it was pretty difficult to separate
the pure [un]marshalling routines to and from blobs from
the RPC engine. Has that changed?

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: PACs (was: Re: Delegation and Moonshot)

Luke Howard
>> I think I'll stick with http://www.dcerpc.org/ -- given I
>> worked on that code for quite a few years ;-)
>
> Last I heard was that it was pretty difficult to separate
> the pure [un]marshalling routines to and from blobs from
> the RPC engine. Has that changed?


I added support for Microsoft Encoding Services (as used in the PAC) back in 2003, although this wasn't available until Novell open sourced it in 2007. It's in the dcerpc.org code, as part of the IDL library.

The flag you want for the PAC is IDL_ES_MIDL_COMPAT (which turns MES compatibility on). IDL_ES_NO_HEADER gets you the raw NDR data.

-- Luke
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: PACs (was: Re: Delegation and Moonshot)

Nico Williams
In reply to this post by Simo Sorce
There's also CDDL code in what remains of OpenSolaris (i.e., the last
build, buil 147).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev