I think that there is also the Proof Key observation for Proof of Possession that needs to be included:
When creating response, the AS encrypts both the token and the proof key within it using the public key of the RS. The AS also includes the proof key in the response and encrypts it using the public key of the client. Upon receiving this, the client is able to decrypt the proof key. It then sends the token and a message that it signed with the proof key to the RS. When the RS receives the message, it is able to decrypt the token using its private key. It computes the signature of the token using the public key of the AS and compares it to the one included in the token. If they match, the RS knows that the token was sent by the AS and that the proof key in the token is trustworthy. It then uses this to sign the message. If the signature matches the signature created by subject using the proof key, the RS knows that the message originated from the subject claiming to have sent it and no one else. From: [email protected] [mailto:[email protected]] On Behalf Of Phil Hunt Sent: Monday, July 16, 2012 6:29 PM To: [email protected] WG Subject: [OAUTH-WG] High-level observations on HoK Issues Some observations about requirements and issues for designing an OAuth HoK proposal. Note: I have intentionally tried to stay away from specifics like token types, encryption types and have only at most delved into asymmetric vs. symmetric keys. I see positives in many combinations for different scenarios. That said, I'm not yet sure that one proposal can meet all high level requirements. I am happy to present this for discussion at the OAuth WG meeting in Vancouver. Players at The Party Most crypto cases discuss scenarios involving a sender and receiver. For these scenarios, there may be 3 identities in play. Plus a 4th during setup. 1. The client application (that accesses the resource). * A client applicaiton may have its own client credential (backed by PKI key pair or other credential). Many clients may share the same credential so... * Sometimes we are more interested in uniquely identifying an instance of a client (if the client keys are not unique). 1. The resource server being accessed. 2. Delegation token (access token). An authority granted by an authorization server for a client to access on a users behalf 3. Authorization server (a server that does secure communication with the client for the purpose of issuing access tokens and potentially exchanging secrets). Public vs. Confidential Clients In OAuth scenarios, there are two sets of broad clients to consider: Public and Confidential. Here are some characterizations that occur to me. Public * In many cases public clients are light weight. While they can do TLS, their ability to generate key pairs might be limited. Symmetric keys may be easier? * Public clients generate requests primarily based on user input actions. While latency is an issue, overall throughput is low. * A public client typically only has access tokens representing delegated authorizations for a single user. * Public clients are difficult to uniquely identify. In OAuth, such clients may only be identified by a self asserted client_id which by itself cannot be verified. Confidential * Confidential clients are often web apps that can serve many users and other service providers directly. * Confidential clients usually have many access tokens (100s to millions) representing delegated authorizations for many many users. * A single confidential client may generate 1000s of requests per second using 1000s of different access tokens. * Connection pooling is an important scaling factor. * Confidential clients usually have client credential that can be well protected. It may be reasonable to expect a client to have a private key. * Confidential clients often have unique client credentials (though not guaranteed). Authentication vs. Uniqueness Typically in HoK the drive is "authentication". I would contend that this isn't the case in OAuth. The "authentication" step was already performed in the authorization steps (or done externally). In most cases we simply want to verify that the client issued a token is the one using an access token. * In OAuth, client credentials are often shared by multiple client software instances. * Many OAuth threats are mitigated when a token or code can be bound to a specific "instance" of a client. * Binding a token to a "client" credential may not be sufficient. Even while a strong client authentication credential helps mitigate risk, binding tokens to "instances" of clients is better. TLS vs. Open Channel There are many cases where transport security may not be needed or not desired. Since a particular access token could be used for many things, it is not necessarily true that an access token intended for a low-risk service is only used at a low-risk service. * Bearer tokens can be sniffed over open (non-TLS) connections, this poses a particular risk for sniffing attacks. * For some applications the oauth token may be more valuable than the resource. Some applications may wish to secure only the access token. * TLS One-way provides a way for clients to authenticate the service and to secure and protect traffic integrity. * Two-way TLS provides bi-directional authentication but has limited use in practice as service providers often terminate TLS at load balancers. TLS channel information may not be available to the web tier. * Their is some discussion that even with TLS, rogue proxies could be used as an attack vector. Therefore a secure token is still desirable. Message vs. Channel HoK There are three forms of HoK that can be used: * Channel HoK - In channel HoK, the client proves identity as suggested by Hannes HoTK draft. * A client HoK channel could be bound to the client or could be bound to a oauth authorize token context. * There may trade-offs in connection pooling for using client bound vs. access token bound HoK. * Client bound Keys may be long-lived. Access token keys are shorter lived * Long lived keys should be asymmetric. * * Message HoK - In message HoK, a proof contained within the authorization header token protects the credential from sniffing because it binds the client instance to the token. Message HoK tokens can be used in non-secure channels, in TLS channels, and in Channel HoK scenarios. * An HoK message token should bind an *instance* of a client to the token. * The key establishes some sort of proof about the client being the same client that originally requested the access token. It does not necessarily need to prove the client's identity * The keys can be ephemeral. * Since keys last only as long as an access token many scenarios may only require symmetric keys. * Asymmetric message keys add limited value if the Channel HoK is already asymmetric (confirm?) * I suspect that unique keys should be generated by the client and not by the server so the client may detect "insertion" attacks. (confirm?) * Message authentication (a signature of the request) provides message integrity when used over non-secure channel. * Message authentication could also be designed to prevent replay attacks. Note: I think Hannes HoTK proposal is interesting. It actually inserts another dimension into these observations which I think is important for public clients (e.g. mobile apps). It doesn't break down into message vs. channel, but rather uses access token scoped channel security to achieve some features of both. Still I have concerns about performance for client web apps (confidential clients). Phil @independentid www.independentid.com<http://www.independentid.com> [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
