Thanks Thomas! My notes below are not aimed specifically at Thomas but at those seeking to have this section included. I'm going to skip any editorial feedback as I will make those changes if and when incorporating this text into the v2 specification. I will say that the new section 3.2 belongs largely in the introduction of section 3.
> [NOTE: Text for the following Section 3 is based on OAUTH draft-11] > > > 3. Client Credentials > > When interacting with the authorization server, the client identifies > itself using a set of client credentials which include a client > identifier and other properties for client authentication. The means > through which the client obtains its credentials are beyond the scope > of this specification. Some authentication > schemes require the client to undergo registration with the > authorization server. > > Due to the nature of some clients, authorization servers SHOULD NOT > make assumptions about the confidentiality of client secrets without > establishing trust with the client. Although it is difficult for > servers to ascertain the security capabilities of clients, in general > authorization servers SHOULD NOT issue client secrets to clients incapable > of keeping their secrets confidential. > > The authorization server MAY authenticate the client using any > appropriate set of credentials and authentication schemes. The > client MUST NOT include more than one set of credentials or > authentication mechanism with each request. Need to make it explicit that no client authentication scheme is mandatory to implement. > Although authentication schemes and their protocol implementations > are out of scope, this specification seeks to support a broad > selection of authentication schemes that are currently deployed > today and that may be deployed in the future. This statement is just not true. This specification may seek to keep client authentication out of scope but by defining two such mechanisms in section 3, it clearly fails to keep them out of scope. > > 3.1. Client Password Credentials This section should be named "Using HTTP Basic access authentication scheme". The parameters defined are just a hack to align Basic with the deployed reality of using parameters instead of the header. > Client password credentials use a shared symmetric secret to > authenticate the client. The client identifier and password are > included in the request using the HTTP Basic authentication scheme as > defined in [RFC2617] by including the client identifier as the > username and client password as the password. > > For example (line breaks are for display purposes only): > > > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&code=i1WsRn1uB1& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > Alternatively, the client MAY include the password in the request > body using the following parameters: Need to add a note here that using the parameter alternative is deprecated or NOT RECOMMENDED. If we are going to bastardize HTTP Basic, we should do it in a responsible way and discourage people from using it. There is not a single reason why clients can't use HTTP Basic to transmit these credentials (if you have requirements showing otherwise, please share). > client_id > REQUIRED. The client identifier. > > client_secret REQUIRED. The client password. > > For example (line breaks are for display purposes only): > > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&client_id=s6BhdRkqt3& > client_secret=gX1fBat3bV&code=i1WsRn1uB1& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > The authorization server MUST accept the client credentials using > both request parameters and the HTTP Basic authentication scheme. > The authorization server MAY support additional authentication > schemes suitable for the transmission of password credentials. This is not true. There are no requirements for what authentication schemes the authorization server MUST or SHOULD accept. > 3.2. Shared Secret Credentials > > Beyond client password credentials, there is a broad family > of authentication schemes based on the notion of shared secrets. > In these schemes the primary aim is for the client to prove > possession of the shared secret. In the current OAUTH 2.0 context, > shared secret credentials are different from assertion credentials > (see below) in that here the client does not have to > provide any assertions or claims. > > Within the family of authentication schemes based on the pairwise > sharing of secrets there are a variety of protocols that have > been deployed. These include challenge-response protocols > (e.g. CHAP [RFC1994]), password-authenticated key agreement > protocols (e.g. EKE [REF]) and various embodiments > of the one-time password (OTP) protocols (e.g. [RFC2289]). > > These authentication protocols > are out of scope of this specification, but in deployment > of these authentication schemes with OAUTH 2.0, the authorization > server MUST accept the client credentials using > both request parameters and the HTTP Basic authentication scheme. I don't understand how these other symmetric secret schemes work with Basic. > 3.3 Client Assertion Credentials > > The term assertion (or signed assertion) refers to a statement or > claim made by a trusted third party regarding a given subject > at a given moment in time. Typically an assertion is digitally > signed by its issuer in order to provide source-authenticity > and integrity protection. There are a number of vehicles for > the implementation of assertions. > Examples include X.509 subject and attribute certificates > [RFC3280,RFC5755], SAML 2.0 assertions [OASIS.saml-core-2.0-os], > Claims [OASIS.imi-identity-1.0], Kerberos service tickets [RFC4120] and > others. > Their differences typically lie in their semantic expressiveness, > syntactic complexity and size. > > In OAUTH, client assertion credentials provide an extension point > by which the authorization server can authenticate a client by validating > a signed assertion issued by a third party (assertion issuer), > which is trusted by both the client and the authorization server. > > A client must obtain an assertion (such as > a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer > or may in some cases self-issue an assertion. > The format of the assertion, the process by > which an assertion is obtained, and the method of validating an > assertion are defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. However, for > the purposes of the authorization server validating the identity of > a client, the assertion presented by the client SHOULD contain > at least the following information: > > o Identity of the client. > o Identity of the issuer. > o Method of authentication used by the issuer to > authenticate the client (RECOMMENDED). > o Time of authentication of the client by the issuer (RECOMMENDED). > o Time of assertion issuance and validity period of assertion. > o Digital signature of the issuer. > o An indication (explicit or implied) as to the means by which > the client demonstrates its right to present the assertion > (RECOMMENDED). The entire section is marked as SHOULD which is equal to RECOMMENDED. This is an odd combination of "double SHOULD" on some items. > When using a client assertion, the client includes the following > parameters: > > client_assertion_type REQUIRED. The format of the assertion as > defined by the authorization server. The value MUST be an > absolute URI. > > client_assertion REQUIRED. The client assertion. Since this section does not claim to be the only valid way to authenticate a client using assertions (as other *real* HTTP schemes may provide that facility), the REQUIRED parameters should be limited to those using *this* mechanism, not to 'using a client assertion'. > For example, the client sends the following access token request > using a SAML 2.0 assertion to authenticate itself (line breaks are > for display purposes only): > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&code=i1WsRn1uB1& > client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type= > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > When obtaining an access token using a client assertion together with > an authorization code (as described in Section 5.1.1), a mechanism is > needed to map between the value of "client_id" parameter used to > obtain the authorization code, and the client assertion. Such a > mechanism is beyond the scope of this specification, but MUST > be specified for any client assertion type used in combination with > an authorization code. This MUST is pointless and should be removed. We should not include any MUST which cannot be verified and enforced (I need to review the rest of the document for such normative requirements). Here, since no registration process is provided for assertion types, and none of the vendors demanding this facility have published (or indicated their intention to publish) documents for any particular assertion type, where exactly is this MUST to be enforced? There is just no point. It is enough to say that this is something they need to consider. > The authorization server MUST reject access token requests using > client assertion credentials that do not contain HMAC or signed > values that: > > o State the assertion was specifically issued to be consumed by the > receiving endpoint (typically via an audience or recipient value > containing the receiving endpoint's identifier). > > o Identify the entity that issued the assertion (typically via an > issuer value). > > o Identify when the assertion expires as an absolute time (typically > via an expiration value containing a UTC date/time value). The > authorization server MUST reject expired assertions. This is where things fall apart. This looks like normative language, and clearly intents to be, but has no real way of being implemented by any general purpose library. If this section (client assertions) is to be added to the specification, this entire last part should be converted to a security consideration section, not a pretend attempt to define real security requirements. The security of this entire proposal rests on being able to enforce these requirements, but the specification does not offer any useful information for implementers to do so. In practice, this invents a new HTTP authentication scheme. The test we must apply here before adding this section to the document is whether it would pass IETF scrutiny if it was presented as a new, standalone, HTTP authentication scheme (regardless of how it transmits the credentials using parameters or header). Before including it, I would like to see a statement from the AD stating that the text is acceptable to the IETF security standards, and that it is suitable for use as a generic HTTP authentication scheme. If it is acceptable here but not with other HTTP requests, we need to make that clear (though that would be pretty bad). Here is one counter proposal to this. Define the two parameters 'client_assertion_type' and 'client_assertion', and specify a required process for publishing specifications using them for use with well-defined assertion formats. This way, the community can enforce sane security standards which this section clearly fails to accomplish (no matter hard it tries, and it does try). How is this different from the grant type extension point (which does not require any such publication)? With the grant type extension point, we clearly label it an extension, and take no position as to what it may contain and to its level of security. Here however, the text clearly creates the illusion of security, but doesn't provide enough detail as how to specifically accomplish that in practice. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
