Re: [Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi Craig,

Okay, I will read some documents on how to implement such mechanism. Thanks!

John

Craig A Lee <craig.a@aero.org> 於 2016年6月27日 週一 下午3:38寫道：

> All,
>
>
>
> This issue of *delegation of trust* (user -> nova -> glance, i.e.,
> enabling nova to auth to glance on behalf of the user) is a fundamental
> capability.  This is precisely why PKI *proxy certs* (IETF 3820) were
> developed back in the grid era enabling chains of trust to be established
> up to a specifiable length.  The OAuth approach essentially enables one
> step of delegation but is certainly getting more widely used.  What’s the
> best approach for Keystone, however, is not going to be simple to pin down.
>
>
>
> --Craig
>
>
>
> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> *Sent:* Sunday, June 26, 2016 11:11 PM
> *To:* 林自均 <johnl...@gmail.com>
> *Cc:* openstack@lists.openstack.org
> *Subject:* Re: [Openstack] [Keystone] Source IP address in tokens
>
>
>
>
> On Jun 26, 2016 19:39, "林自均" <johnl...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have the following scenario:
> >
> > 1. On client machine A, a user obtains an auth token with a username and
> password.
> > 2. The user can use the auth token to do operations on client machine A.
> > 3. A thief steals the auth token, and do operations on client machine B.
> >
> > Can Keystone check the auth token's source IP (which is client machine A
> in the above example) to prevent thieves to use it? Does this feature
> exist? Or is it a work in progress? Thanks for the help!
> >
> > John
> >
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
> Unfortunately, validating tokens in this way will induce a number of
> failures. The user's token is passed through from one service to another
> for subsequent actions (e.g. nova talking to glance to get the proper
> image).
>
> We are working on changing how AuthZ is handled when it is service to
> service (nova to glance or cinder) vs when it is user to service.
>
> While we have had the concept of token binding (requiring an x509 client
> cert for example) the above mentioned limitation has made the feature a
> non-starter. Generally speaking bearer tokens are known to have this issue
> and keystone tokens are bearer tokens.
>
> The best mitigation is to use TLS for communication to the endpoints (user
> -> service) and limit the life span of the tokens to the shortest window
> possible (making replay attacks significantly more difficult as the tokens
> expire quickly).
>
> Eventually we can work on solving this, but there is a bunch of work
> needed before it can be worked on/explored.
>
> --Morgan
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi Steve & Morgan,

Thank you for your reply! I see the reasons not to validate tokens with
theirs source IP addresses.

One more question to Morgan: you mentioned that I should use the shortest
life span of tokens (perhaps 1 hour?), but this will make the users type in
their usernames and passwords too often. Let's say if I want to provide a
"Remember me for 30 days" checkbox, is there a better way other than
setting the life span of tokens to 30 days?

John

Morgan Fainberg  於 2016年6月27日 週一 下午2:11寫道：

>
> On Jun 26, 2016 19:39, "林自均"  wrote:
> >
> > Hi all,
> >
> > I have the following scenario:
> >
> > 1. On client machine A, a user obtains an auth token with a username and
> password.
> > 2. The user can use the auth token to do operations on client machine A.
> > 3. A thief steals the auth token, and do operations on client machine B.
> >
> > Can Keystone check the auth token's source IP (which is client machine A
> in the above example) to prevent thieves to use it? Does this feature
> exist? Or is it a work in progress? Thanks for the help!
> >
> > John
> >
>
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
> Unfortunately, validating tokens in this way will induce a number of
> failures. The user's token is passed through from one service to another
> for subsequent actions (e.g. nova talking to glance to get the proper
> image).
>
> We are working on changing how AuthZ is handled when it is service to
> service (nova to glance or cinder) vs when it is user to service.
>
> While we have had the concept of token binding (requiring an x509 client
> cert for example) the above mentioned limitation has made the feature a
> non-starter. Generally speaking bearer tokens are known to have this issue
> and keystone tokens are bearer tokens.
>
> The best mitigation is to use TLS for communication to the endpoints (user
> -> service) and limit the life span of the tokens to the shortest window
> possible (making replay attacks significantly more difficult as the tokens
> expire quickly).
>
> Eventually we can work on solving this, but there is a bunch of work
> needed before it can be worked on/explored.
>
> --Morgan
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Keystone] Source IP address in tokens

[Morgan Fainberg]

On Jun 26, 2016 19:39, "林自均"  wrote:
>
> Hi all,
>
> I have the following scenario:
>
> 1. On client machine A, a user obtains an auth token with a username and
password.
> 2. The user can use the auth token to do operations on client machine A.
> 3. A thief steals the auth token, and do operations on client machine B.
>
> Can Keystone check the auth token's source IP (which is client machine A
in the above example) to prevent thieves to use it? Does this feature
exist? Or is it a work in progress? Thanks for the help!
>
> John
>
> ___
> Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

Unfortunately, validating tokens in this way will induce a number of
failures. The user's token is passed through from one service to another
for subsequent actions (e.g. nova talking to glance to get the proper
image).

We are working on changing how AuthZ is handled when it is service to
service (nova to glance or cinder) vs when it is user to service.

While we have had the concept of token binding (requiring an x509 client
cert for example) the above mentioned limitation has made the feature a
non-starter. Generally speaking bearer tokens are known to have this issue
and keystone tokens are bearer tokens.

The best mitigation is to use TLS for communication to the endpoints (user
-> service) and limit the life span of the tokens to the shortest window
possible (making replay attacks significantly more difficult as the tokens
expire quickly).

Eventually we can work on solving this, but there is a bunch of work needed
before it can be worked on/explored.

--Morgan
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [Keystone] Source IP address in tokens

[林自均]

Hi all,

I have the following scenario:

1. On client machine A, a user obtains an auth token with a username and
password.
2. The user can use the auth token to do operations on client machine A.
3. A thief steals the auth token, and do operations on client machine B.

Can Keystone check the auth token's source IP (which is client machine A in
the above example) to prevent thieves to use it? Does this feature exist?
Or is it a work in progress? Thanks for the help!

John
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack