On 2020-05-05, at 17:39, Jim Schaad wrote:
>
> I don't see how the four-corner model solves the issue that I highlighted.
> If the client does not have a key for any local AS, then nothing helps. The
> four-corner model deals with the issue of the client and the RS not trusting
> the same
-Original Message-
From: Michael Richardson
Sent: Tuesday, May 5, 2020 11:07 AM
To: Jim Schaad ; 'Ace'
Subject: Re: [Ace] draft-ietf-ace-oauth-authz
Jim Schaad wrote:
> I have much the same problem. While a client could find an AS which
> would authenticate the client, I
Jim Schaad wrote:
> I have much the same problem. While a client could find an AS which
> would authenticate the client, I don't know how the client would
> establish any degree of trust in the AS which is going to give it
> tokens.
Is your question that you don't know how to
Hi Michael,
On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson"
wrote:
Francesca Palombini
wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS.
Note
> that this T2 has different authorization info, but does not contain
> input
HI Jim,
Agree.
That's a new draft then with an rt value for a given upload protocol.
Peter
Jim Schaad schreef op 2020-05-05 17:43:
Thanks Peter, that makes things a lot clearer. However I think that you are not asking for who is an AS, but who is an AS that has a particular interface. It
Francesca Palombini wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS. Note
> that this T2 has different authorization info, but does not contain
> input keying material ("osc"), only a reference to identify Sec1 ("kid"
Is there an assumption that the access
Thanks Peter, that makes things a lot clearer. However I think that you are
not asking for who is an AS, but who is an AS that has a particular interface.
It would make more sense to define a new interface identifier for the
upload/control protocol rather than just identifying who is an AS.
I don't see how the four-corner model solves the issue that I highlighted. If
the client does not have a key for any local AS, then nothing helps. The
four-corner model deals with the issue of the client and the RS not trusting
the same AS, but the different AS entities trust each other on
Hi Ludwig,
What you state is in fact the change proposed below, I'm happy you support
making this change. The reason why it does not work that way already is because
of the way authz-info is defined for the "general" case (exchange of nonces is
necessary, and derivation of sec ctx). The change
Hello Francesca,
I have not followed this discussion in detail so excuse me if I missed an
important detail. That said: I cannot understand why you would want to
negotiate a new context in step 8 by sending N1'? At that point you have a
functional OSCORE context established and could just send
Hi Ace chairs, DTLS authors, Ace framework authors, Ben,
TL;DR: we propose some changes on the OSCORE profile for the "update of access
rights" scenario. We have comments for the DTLS profile and the ACE framework
regarding this scenario, and we ask for feedback from ACE OSCORE implementers
HI all,
I agree about the authorization/trust problem.
My request concerns something more trivial.
Suppose we have this new network with a set of servers, an (AS) (may be
more) and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only
12 matches
Mail list logo
