Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?
On 10/10/2019 17:02, Justin Richer wrote: They are in that registry as the “token endpoint response” error codes. RFC8628 adds new ones. I think that 6749 failed to put in the base ones. — Justin That would explain my confusion. Errata-worthy? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?
Hello OAuth WG, while addressing some AD review comments on draft-ietf-ace-oauth-authz, I've come across a question I think you can help me with: I was previously laboring under the misconception that the error codes defined in https://tools.ietf.org/html/rfc6749#section-5.2 are registered here: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error Which is apparently not the case. Is there another registry that one should use (e.g. if one needs to add new error codes)? If there is none (which seems to be the case), should we create one? Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question regarding RFC 7800
On 03/04/2019 12:14, Robert Lembree wrote: Hello folks, What is the status of RFC 7800? We’re finding the need for this, and wonder what we might be able to do to help move this along? Regards, rob If I may be so bold to drop a shameless plug for the ACE WG here [1]. As you are working with Schneider Electric, the work in ACE (based on OAuth, but for Contrained Environments) might be more relevant for you. We have adopted a constrained profile of RFC 7800 (among other things): https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ Regards, Ludwig [1] https://datatracker.ietf.org/group/ace/documents/ -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-fett-oauth-dpop-00
On 02/04/2019 17:35, Brian Campbell wrote: Except that the jwk header is more appropriate in the given context https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key that corresponds to the key used to digitally sign the JWS. Which is what it is. A quick nit: in figure 3 you seem to be using the "jwk" claim to include the pop-key in the token. Any reason for not using the "cnf" claim from RFC 7800? /Ludwig My bad, figure 3 is not a token (although it looks like one) it's the token request (encapsulated in a JWS). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-fett-oauth-dpop-00
On 28/03/2019 11:17, Daniel Fett wrote: Hi all, I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00 Abstract This document defines a sender-constraint mechanism for OAuth 2.0 access tokens and refresh tokens utilizing an application-level proof-of-possession mechanism based on public/private key pairs. Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before! If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop - Daniel A quick nit: in figure 3 you seem to be using the "jwk" claim to include the pop-key in the token. Any reason for not using the "cnf" claim from RFC 7800? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
On 07/02/2019 16:15, Hannes Tschofenig wrote: Hi Ludwig, My interpretation of this is that "resource" refers to a single resource No. Here is the text from token exchange (see last sentence): resource [...] Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. Enumerating the audience is not the same as addressing it by a group name. I agree that without too much stretching of the definition of the resource parameter I could use URIs as group identifiers, however the audience claim is defined to be "StringOrURI" so if someone defines an audience identified by a String that is not an URI how does a client ask for that with the resource parameter? Or in short: Why don't you make your resource parameter mirror the "aud" claim? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
On 28/01/2019 23:12, George Fletcher wrote:
I also don't know that this raises to the level of "concern" but I find
the parameter name of "req_aud" odd. Given that the parameter in the
resource-indicators spec is 'resource' why not use a parameter name of
'audience'. That said, I have not read the thread on the ACE working
group list so there could be very good reasons for the chosen name:)
I do think that there is a lot of overlap (in most cases) between
'resource' and 'audience' and having two parameters that cover a lot of
the same semantics is going to be confusing for developers. When calling
an API at a resource server, the 'audience' and the 'resource' are
pretty equivalent. Maybe in other use cases they are distinctly separate?
To give you all the background of "req_aud" from ACE (sorry for the long
text):
Originally in ACE we had defined the "aud" parameter for requests to the
token endpoint with the semantics that the client was requesting a token
for a certain audience (i.e. requesting that the AS copy the "aud"
parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that
specifies the intended audience of Authorization Servers (if I remember
correctly), so we decided to rename our parameter to "req_aud" for
"requested audience".
Mike Jones then made us aware of the work on resource indicators, but
upon closer examination I found the "resource" parameter to be more
limited than the "req_aud", since resource specifically states:
"Its value MUST be an absolute URI ... the "resource" parameter URI
value is an identifier representing the identity of the resource"
My interpretation of this is that "resource" refers to a single
resource, which is more constrained than the definition of the "aud"
claim from 7519, which uses a StringOrURI value. For example my intent
was to use "aud" and "req_aud" for group identifiers
("temperatureSensorGroup4711") and other non-uri strings
(hash-of-public-key), which I cannot do with "resource". We therefore
decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params,
even though is clearly overlaps with "resource".
Any comments and suggestions about that line of reasoning (especially
from the OAuth point of view) are very welcome.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] exp claim ... was RE: expires_in
On 18/12/2018 17:06, Aaron Parecki wrote: The "exp" claim is an implementation detail of one type of access token, but obviously doesn't have any meaning to someone using non-JWT tokens. Since not everyone is using JWT access tokens, it seems strange to have a mention of a JWT-specific detail. That said, it sounds like the proposal is to recommend access tokens always have an expiration date? In that case, is it also important that the expiration date be communicated to the client? The original context was from the ACE WG. In ACE we use pop-tokens exclusively and it is important in some usecases that the client no longer uses the pop-key material when the token has expired. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] expires_in
On 18/12/2018 12:59, David Waite wrote: My understanding was that this parameter was advisory to the client - it neither mandated the client discard the token after the expires_in time, nor has a requirement that the token is no longer honored by protected resouces at that point in time (vs earlier or later). That is my understanding as well, I would however have expected that this parameter would be aligned with the 'exp' claim of the token. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] PoP Key Distribution
On 2018-07-03 21:46, Hannes Tschofenig wrote: Hi all, Where should the parameters needed for PoP key distribution should be defined? Currently, they are defined in two places -- in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and the token_type parameters are defined in both specs. IMHO it appears that OAuth would be the best place to define the HTTP-based parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and alike. Of course, this is subject for discussion, particularly if there is no interest in doing so in the OAuth working group. I fully agree that OAuth would be the best place. I've only drawn some of these parameters into draft-ietf-ace-oauth-authz because the work on draft-ietf-oauth-pop-key-distribution seemed to have been discontinued (it expired August 2017). That said, I'd hate to introduce a normative dependency into draft-ietf-ace-oauth-authz on a document that will not move forward or only move very slowly. What are the prospects of going forward quickly with draft-ietf-oauth-pop-key-distribution? There is also a misalignment in terms of the content.. draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. In the meanwhile the work on OAuth meta has been finalized and It seems indeed that 'alg' and 'profile' parameters have some overlap, although 'alg' seemed a bit more narrow to me (which is why I created 'profile'). If we could extend the definition of 'alg' a bit, I'd be OK to remove 'profile' from the ACE draft (provided the OAuth draft moves forward in a timely manner). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
On 2017-02-24 22:58, John Bradley wrote: I updated the references but haven't made any other changes. I had some questions about it so though it was worth keeping alive at-least for discussion. There have been some other questions and proposed changes. I will take a look through them and see if what may be worth updating. John B. Question about the 'aud' parameter: Wouldn't it be useful to allow other values than URIs for that one? One could easily imagine a group identifier as value of that field, where the RS internally resolves whether it is part of that group and therefore the target audience of that token. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE ICT/SICS Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Future of PoP Work
On 2016-10-19 20:45, Hannes Tschofenig wrote: Hi all, two questions surfaced at the last IETF meeting, namely 1) Do we want to proceed with the symmetric implementation of PoP or, alternatively, do we want to move it over to the ACE working group? 2) Do we want to continue the work on HTTP signing? We would appreciate your input on these two questions. Ciao Hannes & Derek Hello, maybe my 2-cents as author of the ACE draft that needs PoP can contribute something here: I would also prefer that you guys make the PoP specs and I just make a ACE profile on top of them. However the ACE work is moving forward and the PoP work at OAuth seems to be stuck. I've currently taken what was available form draft-ietf-oauth-pop-* and moved the relevant text into draft-ietf-ace-oauth-authz (acknowledging the original authors of course), since it was unclear to me what the future status of the pop drafts would be. I'm absolutely willing to remove the text again and reference an OAuth WG document instead, if I feel it will not significantly delay the progress of the ACE draft. Hope this information helps in the decision making. Regards, Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelevägen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order to create a unified institute sector and become a stronger innovation partner for businesses and society. At the end of the year we will change our name to RISE. Read more at www.ri.se/en/about-rise smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
Michael, thank you for answering, this is getting very interesting. Comments inline. /Ludwig On 02/05/2016 04:26 PM, Michael Richardson wrote: First, let me say that I confused RS and RO/AS in my mind when reading before. Starting again, I think that any PSK for authentication between C<->RS is unrealistic. Actually I don't want to authenticate the client, I just want do a proof-of-possession for the (symmetric) key that is bound to the token. Wouldn't the DTLS-PSK handshake provide that proof? Detailed scenario (skip if the above makes sense): Client has a PoP token with a symmetric PoP key. Client wants to use DTLS-PSK towards the RS with the symmetric PoP key as PSK to get a.) A secure connection and b.) do the proof-of-possession towards the RS. >> So my question is then: could the out-of-band process have >> pre-exchanged the raw public key (and the RS's key/certificate!) as >> well? > Short answer: Yes but only to the AS not to the client(s). > Long answer: I am laboring under the assumption that the AS not only > provides the OAuth token and the corresponding PoP key to the client, > but also some information on the communication security protocols that > the RS supports. Furthermore the AS facilitates the establishment of a > security context between client and RS by providing things such as a > (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode > that the RS is going to support. Thus individual clients would not, > a-priori, know the raw public key of a RS, but would be able to get > that information from the AS. That seems entirely reasonable. Would the OAuth token not also be bound to the Raw RSA key of C?So RS would never need to be told about C's key, because the AS would have told it "key XYZ can access resource ABC" in the OAuth token. Yes if the PoP token uses a public key as PoP key. C could even generate an ephemeral key-pair just for this token (and the DTLS-RPK handshake). -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
On 02/04/2016 05:14 PM, John Bradley wrote: In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution The proof key is included in the access token or provided out of band. The proof mechanism to the RS is what would determine if the key type needs to match DTLS . If the proof is DTLS then they would need to match. Thank you John, this leads me to another question (maybe I just missed it in the PoP drafts): Who decides what the proof mechanism should be? How is the proof mechanism signaled to the client (the client may support several proof mechanisms)? /Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Questions about OAuth and DTLS
Hello list(s), in the process of updating our draft [1] (mainly in reaction to the reviewer's comments) I've come up with a question I'd like to put to the list (crossposting to OAuth as well, they might have considered that already): Assuming we are using (D)TLS to secure the connection between C and RS, assuming further that we are using proof-of-possession tokens [2], i.e. tokens linked to a key, of which the client needs to prove possession in order for the RS to accept the token. Do we need to support cases, where the type of key used with DTLS does not match the type of key in the PoP-token? Example: The client uses its raw public key as proof of possession, but the DTLS connection C - RS is secured with a pre-shared symmetric key. Is that a realistic use case? It would simplify the DTLS cases a lot, if I could just require the token and the DTLS session to use the same type of key. For starters we could use DTLS handshake to perform the proof-of-possession. Would there be any security issues with using the PoP key in the DTLS handshake? I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 and raw public PoP keys as client-authentication key as in RFC7250. Regards, Ludwig [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02 -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
Thank you Michael! Comments inline. /Ludwig On 02/04/2016 03:31 PM, Michael Richardson wrote: Ludwig Seitz <lud...@sics.se> wrote: > Assuming we are using (D)TLS to secure the connection between C and RS, > assuming further that we are using proof-of-possession tokens [2], > i.e. tokens linked to a key, of which the client needs to prove possession in > order for the RS to accept the token. > Do we need to support cases, where the type of key used with DTLS does not > match the type of key in the PoP-token? > Example: > The client uses its raw public key as proof of possession, but the DTLS > connection C - RS is secured with a pre-shared symmetric key. > Is that a realistic use case? Before I agree that it's unrealistic, I think it's worth going out of charter scope and ask how much these two credentials were created/distributed. I think that in this case, the pre-shared symmetric key is initialized through some out-of-band (perhaps human mediated?) process, while the raw public key did not need any other pre-arrangement. Actually even the raw public key needs to be provisioned out-of-band to those supposed to trust it for authentication. So my question is then: could the out-of-band process have pre-exchanged the raw public key (and the RS's key/certificate!) as well? Short answer: Yes but only to the AS not to the client(s). Long answer: I am laboring under the assumption that the AS not only provides the OAuth token and the corresponding PoP key to the client, but also some information on the communication security protocols that the RS supports. Furthermore the AS facilitates the establishment of a security context between client and RS by providing things such as a (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode that the RS is going to support. Thus individual clients would not, a-priori, know the raw public key of a RS, but would be able to get that information from the AS. -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
