Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body
Tom Van Oppens <Tom.Van.Oppens@be.ibm.com> Fri, 26 January 2018 12:20 UTC
Return-Path: <Tom.Van.Oppens@be.ibm.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A67412DA1D for <oauth@ietfa.amsl.com>; Fri, 26 Jan 2018 04:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level:
X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMUeFYAW8riP for <oauth@ietfa.amsl.com>; Fri, 26 Jan 2018 04:20:25 -0800 (PST)
Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D053A12EA81 for <oauth@ietf.org>; Fri, 26 Jan 2018 04:20:22 -0800 (PST)
Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0QCJhg7090898 for <oauth@ietf.org>; Fri, 26 Jan 2018 07:20:19 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.74]) by mx0b-001b2d01.pphosted.com with ESMTP id 2fr42t0c7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <oauth@ietf.org>; Fri, 26 Jan 2018 07:20:18 -0500
Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for <oauth@ietf.org> from <Tom.Van.Oppens@be.ibm.com>; Fri, 26 Jan 2018 12:20:18 -0000
Received: from us1a3-smtp02.a3.dal06.isc4sb.com (10.106.154.159) by smtp.notes.na.collabserv.com (10.106.227.92) with smtp.notes.na.collabserv.com ESMTP; Fri, 26 Jan 2018 12:20:14 -0000
Received: from us1a3-mail10.a3.dal06.isc4sb.com ([10.146.77.204]) by us1a3-smtp02.a3.dal06.isc4sb.com with ESMTP id 2018012612201411-450919 ; Fri, 26 Jan 2018 12:20:14 +0000
In-Reply-To: <CABzCy2BPHy=-XtS5wN7Ltw9CaJ8Ev3z5NK5TwYFDvdHpF-=YqA@mail.gmail.com>
References: <OFC97C8467.B35570A3-ON8025821F.00389998-8025821F.0038B8AA@notes.na.collabserv.com> <CA+k3eCRTP1iZV4+nW1zFgNFhu4_LONL6vnj0WSsvHipwMdLO6Q@mail.gmail.com> <CABzCy2BPHy=-XtS5wN7Ltw9CaJ8Ev3z5NK5TwYFDvdHpF-=YqA@mail.gmail.com>
X-Disclaimed: 35826
To: Nat Sakimura <sakimura@gmail.com>, Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
MIME-Version: 1.0
X-KeepSent: 0AA1C0E2:F7D42D93-C1258221:00357853; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP7 Octobe4, 2013
From: Tom Van Oppens <Tom.Van.Oppens@be.ibm.com>
Date: Fri, 26 Jan 2018 13:20:13 +0100
X-LLNOutbound: False
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="=_alternative 0043C483C1258221_="
x-cbid: 18012612-7581-0000-0000-000005A645A7
X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.397557; ST=0; TS=0; UL=0; ISC=; MB=0.245201
X-IBM-SpamModules-Versions: BY=3.00008431; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000248; SDB=6.00980612; UDB=6.00497121; IPR=6.00759913; BA=6.00005796; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019224; XFM=3.00000015; UTC=2018-01-26 12:20:17
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2018-01-26 11:26:53 - 6.00007964
x-cbparentid: 18012612-7582-0000-0000-0000E73E49D9
Message-Id: <OF0AA1C0E2.F7D42D93-ONC1258221.00357853-C1258221.0043C506@notes.na.collabserv.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-26_07:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DwIxL8laQYziznQm6MECoVL_HUc>
Subject: Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2018 12:20:28 -0000
@Brian +1 I agree that the section is confusing and that errata should be published about it, but before we go there it might be interesting why someone took the effort to describe the situation with an empty client secret, because including these suggestions will break the ability for an sever to dectect a double authentication when the client secret is an empty string - As for the client secret not being an empty, it might be that it's updateable by the client.Maybe specifying that a client secret can't be an empty string might be the most elegant solution. - Secondly I couldn't find the the "If a client_id parameter is present in conjunction with some client authentication mechanism, then both must refer to the same client. " section nor can i find anywhere in the spec what the I do agree that many to be specs and implementations use the client_id in the body, and there are valid arguments to be made for that. But without errata in the OAuth2 spec they are violating the OAuth2 spec, And seeing the nature of it i think adding errata to the OAuth2 spec is the way to go Do you have another suggestion to interpret the problematic section ? @Nat Nowhere in the spec i can find that they must match or even that the AS is supposed to do anything with it When you read the specs at this point the problem is that if a client_id is in the body it is the same as a client_id and a secret (but a blank secret) and that is a double authentication when the Auth header is present @all Shoudln't we define or maybe in the OIDC spec add some information so that the AS needs to do something with that clien_id in the body, saying it must match the client_id coming in somewhere else ? Or at least have the AS do something with it . From: Nat Sakimura <sakimura@gmail.com> To: Brian Campbell <bcampbell@pingidentity.com> Cc: Tom Van Oppens <Tom.Van.Oppens@be.ibm.com>, oauth <oauth@ietf.org> Date: 26/01/2018 01:16 Subject: Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body +1 to Brian. I would like to point out that listing the participant in the protocol message and the authentication of the message sender is an entirely different thing. I see no problems in duplicating client_id in body and header. Of course, they have to match and must fail the authentication if they do not, but this should not be a problem. In fact, it may even be desirable for the message body to have self-contained references to the participants in the authentication protocol as shown in [1]. In such a case, it will necessarily duplicate in case of the basic authentication. [1] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) Best, --- Nat Sakimura On Thu, Jan 25, 2018 at 11:28 PM Brian Campbell < bcampbell@pingidentity.com> wrote: Hi Tom, Indeed RFC 6749 is not well written with respect to this situation and unfortunately leaves some room for varied interpretations. However, in my own not entirely uninformed view having worked on this stuff for awhile now, it is erroneous to interpret the presence of the client_id parameter in the request body as client_secret_post authentication when there is no corresponding client_secret parameter. As you alluded to, there are other types of client authentication that explicitly allow (JWT, SAML, and their base spec) or require (MTLS) the client_id parameter and the OIDC core spec even has an example of the client_id parameter in the body when doing JWT client auth. If client_id with no client_secret in the request body actually implies client_secret_post, then those RFCs (one soon to be RFC) and OIDF standards are all contradicting OAuth 2.0 /RFC 6749. Those supplementary standards as well as widespread implementations/deployments in practice should, I believe, be considered more authoritative than one particular implementation's problematic (in terms of interoperability) interpretation of a not particularly well written area of the OAuth spec. The problematic text from https://tools.ietf.org/html/rfc6749#section-2.3.1 says that "the client MAY omit the [client_secret] parameter if the client secret is an empty string" so it would only really be reasonable for an AS to reject a request as having two client authentication methods in the case that it issued a client the empty string as a client secret (not a public client but a client with an empty string as its actual secret), which should never happen in practice, and that client sent both a basic authorization header without a password and a client_id without a client_secret in the body. That's one way to read it anyway. And regardless that text in Sec 2.3.1 is problematic and should probably be updated with an errata on RFC 6749 to get rid of the text about empty string password and just state that the client_secret parameter is required when doing client_secret_post authentication. Unfortunately the errata often get overlooked but it'd still be good to have that fixed somewhere and a published RFC can't be changed so errata is the only real option to document the actual intent of the original specification. The presence of the client_secret parameter should be the only thing that implies client_secret_post authentication. If a client_id parameter is present in conjunction with some client authentication mechanism, then both must refer to the same client. On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <Tom.Van.Oppens@be.ibm.com > wrote: Dear Oauth Mailing List After some discussion i had i wanted to ask you for some guidance. For the following request request_uri https://example.com/token request_method POST request_headers {"Accept":"application/json","Authorization":"Basic bWFnaWNpZDpwb3RhdG9zZWNyZXQ=","Content-Type":"application/x-www-form-urlencoded","Content-Length":"91"} request_body grant_type=client_credentials&scope=accounts&client_id=magicid We had some discussions whether or not this request is a valid request, to be more exact wether the clientid can be in the body. Section 2.3.1 states A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. But at the same time in the case of a client password (2.3.1) The clientid and secret are carried in the basic auth header as a form of authentication as a preferred method , But the standard states that if you choose to use the body as a form of authentication that if you can ommit the clientsecret the clientsecret is an empty string, therefore passing only the client_id is the same as passing the client_id and an empty string clientsecret . So the current request would be according to the spec interpreted as follows Authentication 1) basic auth cleintid:secret Authentication 2) body auth clientd and blank secret You can choose to use the client_id in the body with public clients or in the confidential client (the Lloyds situation) if you choose to add the clientsecret there as well and are not using the basic auth header (this is due to spec section 2.3 which states The client MUST NOT use more than one authentication method in each request. In short there is no way in the spec that allows for the oauth provider to distinguish between your intention of sending in the client_id again for identification and a malformed request with double authentication. So my stance is (for now) that you cannot send a clientid when you find yourself in the clientid with a corresponding password situation. Is that a correct statement ? and if it is not how would that work ? and if it is, when can you send the clientid in the body but use something else for authentication (something like mtls ?) ? Kind Regards Van Oppens Tom Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above: International Business Machines of Belgium sprl / bvba Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336 RPM Bruxelles / RPR Brussel _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura Chairman of the Board, OpenID Foundation Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above: International Business Machines of Belgium sprl / bvba Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336 RPM Bruxelles / RPR Brussel
- [OAUTH-WG] rfc6749 question about the optional us… Tom Van Oppens
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Nat Sakimura
- Re: [OAUTH-WG] rfc6749 question about the optiona… Tom Van Oppens
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Mike Jones
- Re: [OAUTH-WG] rfc6749 question about the optiona… Brian Campbell
- Re: [OAUTH-WG] rfc6749 question about the optiona… Mike Jones