David, That's not a nitpick, that's an essential point, and I appreciate your making it. My bad.
> Nitpick alert: Andrew, your suggested scheme(s) still leaves ST's as bearer tokens with time and audience restrictions (audience restriction = restriction on who the token is intended for). Anyone possessing the the ST will still be able to authenticate without providing any other evidence of identity, if they can do it in time and before the token has been "used up". So it is still a bearer token. On Wed, Mar 20, 2013 at 4:29 PM, Ohsie, David <[email protected]> wrote: > > I do think a security model where service tickets are not merely bearer > tokens will be even better. > > Nitpick alert: Andrew, your suggested scheme(s) still leaves ST's as > bearer > tokens with time and audience restrictions (audience restriction = > restriction on who the token is intended for). Anyone possessing the the > ST > will still be able to authenticate without providing any other evidence of > identity, if they can do it in time and before the token has been "used > up". > So it is still a bearer token. > > What your scheme does do is to enable enforcement of the audience > restriction (service parameter), so that only the indended audience can > even > validate the ticket. > > What could be done to make the ST and TGT not be a bearer tokens is as > follows: > > 1) The client presents a client cert in the ssl/tls negotiation when > authenticating to CAS and indicates that he wants a HoK (holder of key) ST. > > 2) CAS authenticates the user and records their public key along with the > service attribute in the ticket registry with the ST and TGT. > > 3) The client presents his client cert in the ssl/tls negotiation when > sending the ST to the relying party (CAS client). > > 4) The relying party (CAS Client), presents the clients public key as one > of the parameters when calling serviceValidate/samlValidate. > > 5) CAS checks that the client's public key matches the one stored in the > ST during ST validation. > > 6) If the client presents a TGT to CAS to request an ST, the same check > can be done so that the TGT is also HoK. > > Basically this is just SAML-like HoK validation implemented in CAS. > Obviously it depend on the client possessing and using a client cert. > > Now you could take a similar approach to enforcing the audience > restriction: > > 1) When the client ask for an ST, he presents the public key in the SSL > cert presented by the service. > > 2) CAS records this "service public key" in the ST. > > 3) When the service calls "serviceValidate", it must present a client > cert > corresponding to the "service public key". > > This method would run into problems if there is any kind of "SSL" proxying > going (as happens with my company's outgoing proxy), or if the target > service is running in a cluster where SSL/TLS termination happens at the > node, since each node would be have different public/private key pair. > > These are all somewhat preliminary thoughts made up when pondering SAML HoK > tokens and then adapted to your audience restriction enforcement use case. > They could all be wrong... > > David Ohsie > ASD Arch. and Advanced Dev. > 410-929-2092 > > > > From: Andrew Petro [mailto:[email protected]] > Sent: Wednesday, March 20, 2013 11:32 AM > To: [email protected] > Subject: Re: [cas-user] Restricting access to SAMLValidate to whitelisted > sites and applications > > A try to clarify some issues raised in this thread generally, and then I > get > down to some ideas for addressing Michael's requirements specifically: > > Service tickets are bearer tokens authenticating the end user. They do not > authenticate services, applications, or anyone else. These bearer tokens > are borne by the end user and by the application the end user presents them > to attempting to log in to it. > > When you configure CAS to release attributes in exchange for a service > ticket, then you are configuring CAS to release attributes in exchange for > a > token that authenticates only the end user. > > If the bearer of a bearer token is compromised by the Adversary, then the > Adversary gains access to the borne tokens and, because they are bearer > tokens, can make use of them with impunity. > > So, here, if the user agent is hacked, the Adversary can lay hands on the > service tickets the user acquires (or capture the user's password and then > acquire any other service tickets he likes) and can take those service > tickets and validate them himself, harvesting all the user attributes they > yield. > > This is not a security defect in CAS as such. It's just the nature of the > security model, of the design. Service tickers are bearer tokens. They > have these characteristics. > > CAS adopters should configure CAS to release only user attributes that they > are willing to release under this security model (or enhance CAS to change > the security model). That is, only release attributes you're willing to > release to the end user's user agent, which, sure, like all things in life, > might be compromised. Or the end user might have given up his password in > a > phishing attack. Or shared it with his significant other with whom he's > now > had a nasty breakup. You get the idea. End user authentication is a > horribly messy thing, and service tickets are only obtained by end user > authentication, not by authentication of anything else. Bearer tokens > authenticating the end user. > > Proxy Granting Tickets have different security properties. A service must > authenticate itself (via an https callback mechanism) to obtain a PGT, and > a > PGT authenticates that service in the context of its participation in the > end user's single sign-on session. > > So. If you want to add authentication of the service doing the ticket > validation, that's a fine thing to add. I see it as on this roadmap: > > https://wiki.jasig.org/x/OwE_Aw > > and it would simplify aspects of CAS. The PGT callback would be > unnecessary, since the PGT could be included directly in the validation > response. ClearPass would be unnecessary, since the password could be > included directly as an attribute in the validation response. > > It's a fine improvement to make. It amounts to making service tickets no > longer bearer tokens and instead tokens that only the intended relying > party > can successfully validate. > > So then there's the question of how to authenticate these services, these > relying parties. Shared secret, with the shared secrets registered in the > service registry, feels like the Simplest Thing That Could Possibly Work. > If I were coding a proof of concept of this, I'd start there. TLS has > potential. > > Shibboleth in principle can handle this by encrypting the SAML assertion > with the relying party's public key so that only the holder of the private > key, the relying party, can decrypt it. If my initial use cases for > services needing to obtain attributes JIT that ought not to be released to > end users were narrow enough, I might start there, introducing a Shibboleth > IdP for use with my CAS server and preferring it as the feature-rich engine > for attribute marshalling, transformation, and JIT release via encryted > SAML > assertions. I should immediately temper the enthusiasm of the signed SAML > assertions idea, though, with the recognition that encrypting SAML > assertions is not widely adopted and my impression is it's not supported as > widely as would be desirable. Still, it's a formal and rigorous way to > accomplish this. > > I'd also say this: you could invent a new, ClearPass-like CAS server > endpoint, say > > /cas/attributes > > and require applications to present a proxy ticket to authenticate to that, > just as today they present a proxy ticket to authenticate to ClearPass. > The > implementation of that endpoint would need to know how to translate from > the > authenticated proxy chain to the set of services you'd like to release, but > a naive implementation of treating the last identifier in the proxy chain > as > a service identifier and doing the service registry lookup might well be > good enough. > > This would get you to a security model where the token is authenticating > the > relying party in the context of the end user's SSO session rather than just > the end user, without inventing any new shared secrets, TLS reliances, or > public key cryptography, and instead leveraging the n-tier authentication > feature already in CAS. > > Hope this helps. > > I do think it wil be worth getting to an updated CAS product, protocol that > does authenticate services doing ticket validation, because while I don't > think the current model is broken -- it's entirely serviceable for what it > does -- I do think a security model where service tickets are not merely > bearer tokens will be even better. > > Andrew > > > > > PS: > > The requirement on the validation call from relying parties to CAS (the > call > where they validate a service ticket, as in a call to /samlValidate) > requires presentation of the correct Service identifier to which the > service > ticket was intended to authenticate the user *not* because an Adversary > would have any difficulty guessing a correct value for this parameter, but > only to help relying parties not fall prey to illicit proxies. An illicit > proxy would arise if end user A obtains service ticket to authenticate to > application B, presents the ST to B, and instead of validating the ST, B > presents the service ticket to C to attempt to illicitly log in to C as the > end user. C will attempt to validate the service ticket and the validation > will fail because C will use its own identifier as the service parameter on > the validation attempt. Not because it couldn't have used any other > parameter or because it couldn't have guessed the one matching the service > ticket (the namespace is in practice way too small to make guessing > difficult), but because that's not the question it asks. Presenting the > service parameter is in effect asking CAS "Hey CAS, whom if anyone does > this ST authenticate to this service?" CAS could just as well have > included the service identifier associated with the ST in the validation > response, except relying parties might not properly validate that, just as > they sometimes overlook the need to validate proxy chains. > > > > > > On Tue, Mar 19, 2013 at 5:32 PM, Michael Easthope > <[email protected]> wrote: > That's basically it. Remember that the redirect is a request being sent to > the users device. If they are running a malicious app then the app can > choose not to honor that request. > At that point, the app has all the information it needs to generate a > samlValidate call. There can be SSL between the original site and the > device; and between the device and the cas server - but on the device > itself > the information is not protected. > The service registry doesn't help because from the point of view of the cas > server, everything looks normal. > On 20 Mar 2013 03:23, "Andrew Morgan" <[email protected]> wrote: > On Tue, 19 Mar 2013, Michael Easthope wrote: > Its an edge case but if you can trick a user into logging in AND you > control the http flow (eg if you are running a malicious mobile application > that pretends to be a legitimate app) you can intercept the redirect URL > that comes back from a successful sign-in. That redirect URL contains both > the service URL and the service ticket - with that you can generate a > samlValidate request and obtain the user details - something we only want > to be releasing to our own applications. > > Let's see if I understand: > > 1. User goes to https://yoursite > 2. User is redirected to CAS for login > 3. User authenticates and is redirected back to https://yoursite > 4. Something executes a Man-In-The-Middle attack to change the redirect to > https://badsite? > > That doesn't make sense because SSL should be preventing MITM attacks. > > Or are you saying there is a mobile application (not a browser) that is > talking to https://yoursite? > > Wouldn't the CAS Services Registry matching rules allow you to specify > which > sites are allowed? Or are we talking about a proxying situation? > > Andy > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
