[OAUTH-WG] Re: [ID-align] Re: Re: Re: Fwd: Internet Terminology Glossary
{does oauth need to remain in the CC?}
Rifaat Shekh-Yusef wrote:
> The *draft* proposal is talking about a *live* document, with some
> ideas borrowed from the IANA registry process.
Hmm... registration process.
It sounds like you are maybe thinking _Specification Required_?
So would documents that introduce new terms then be referenced from the
Glossary?
I kind of like that, but I also think it might be too restrictive if that's
the only way to add to it. But, perhaps different entries have different
levels of authority, and a term that comes from a Specification gets a higher
status.
In general, I think about the many (often vastly different) definitions that
one can see in, for instance, the urban dictionary (.com).
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Rifaat Shekh-Yusef wrote: > That's where we started, but that was deemed problematic because that > document was produced as an Independent Submission Stream, which is > outside of the IETF process. Also, the RFC is a static document, while > what we are proposing is a living and dynamic document. I think that we can update/replace 4949. The fact that it came through ISE doesn't matter: we can produce a new document. While I agree that we need a living document which is easy to extend and amend, I don't actually think we want "dynamic". Having the definition of terms change from under the users of the term is a problem. So I am in agreement that a git backed wiki is a good way to build a terminology, I think that the contents should be fixed periodically so that it can be stably referenced. That doesn't mean it has to be an RFC; many wiki have the ability to reference a term at a specific date. ps: thank you for championing this, it's way overdue. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
Re: [OAUTH-WG] [COSE] .well-known/jwks.json and constrained-voucher and RFC7517
Thank you for the replies. (Omitting unicast CCs by request) It seems that 1) /.well-known/jwks.json might not be in as common use as I thought, but maybe OAUTH types might want to register it so as to reduce surprise in the future. 2) We, ANIMA, should probably have two or three RFC7517 containing end points with semantics that we control/define. We already have /.well-known/brski, with IANA rules, so we should do it there. I'm sorry if this sounded like crying wolf :-) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517
EXEC-SUM: /.well-known/jwks.json seems in use, but not registered with IANA. I don't know if it's appropriate for my use. Seems to contain RFC7517 content. Hi, in draft-ietf-anima-constrained-voucher we are creating a CoAP/CBOR version of RFC8995 (BRSKI). One thing that we want to avoid is any extra keys or certificates in the constrained voucher. If we have certificate chains that *do* need to be transmitted we will use x5bag. As BRSKI has three parties: MASA (signer), Registrar (audit/owner), Pledge(relying party/verifier) In general, the Pledge is built by the same entity as runs the MASA, and so the in the simplest form, the Pledge can be built with appropriate trust anchors. (There could be PKI trust roots built-in, or self-signed EE) In the constrained situation, we can sign with a raw public key using CWT. The Registrar would ideally like to verify the signatures. The Registrar would in many cases get the right anchors to verify the signature via a supply chain integration. There are other situations where a TOFU is appropriate. In either case, we'd like to automate the transfer of the keys from MASA to Registrar. In a supply chain integration, then an operator might validate the keys before they are activated, but online transfer makes a lot of sense to reduce errors, particularly as keys get bigger in a PQ world. It was suggested that if we just knew the manufacturer's URL, that /.well-known/jwks.json would work for us. I think it would. I see "documentation" at: https://www.baeldung.com/spring-security-openid-connect (section 6) https://www.baeldung.com/spring-security-oauth2-jws-jwk which seem to refer to keys in RFC7517 format. Note: We have three anchors that we might like to deploy. 1) the key that signs the RFC8366/constrained-voucher objects. Could be a RPK. 2) the key that signs the IDevID certificates in the devices. Most likely a RFC5280 self-signed certificate, but of course, it's a trust anchor, so likely only the public key matters. 3) the manufacturer could have a CA trust anchor, and #1 and #2 might be provided via subordinate CAs, and only #3 needs to be transfered. (#1 is an EE certificate) draft-richardson-anima-masa-considerations actually discusses some of the options here. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
Justin Richer wrote: > From a technical standpoint, OAuth’s dynamic client registration lets > arbitrary clients talk to an AS, but the trust isn’t there in > practice. As an example of a fail even in a closed ecosystem: neither Google nor Facebook nor LinkedIn nor .. permit one to login to them with themselves. Even if we believe that there are business reasons why they wouldn't delegate to another, the fact is that they don't delegate to themselves. What's the use case? I'll give you two: 1) parent/child 2) boss/secretary (*) My kid is subject to Google Classroom. A great idea, rather poorly implemented. The parent interface is basically non-existent. The advice, from *GOOGLE* (and my school board) is, in order to find out what your child is doing... have them share their password with you, the parent. I read this, and went WTF? Doesn't that go against all of the authentication security precepts that Google and others have been telling us? (*) - yes there are limited abilities to do this within gmail. But, it does not extend throughout the ecosystem. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
Ludwig Seitz wrote: > On 02/04/2016 03:31 PM, Michael Richardson wrote: >> >> Ludwig Seitz 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. 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. >> 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
Ludwig Seitz 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. 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? > 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. I agree, that it would be better. (I'm also concerned that we not fail into where IKEv1 did: with weak PSK being the only interoperable mechanism...) > 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. Just because I had to look it up... 4279 - Pre-Shared Key Ciphersuites for Transport Layer Security 7250 - Using Raw Public Keys in Transport Layer Security I thought perhaps it was some more specific mechanism... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
