Hi Ludwig,
On 12/12/2018 10:47 AM, Ludwig Seitz wrote:
> The value of checking the iss field is indeed limited, but if present I
> feel it MUST be checked.
>
> The text does say that the RS must check the integrity of the token (see
> 5.8.1.1.)
>
> "Since the cryptographic wrapper of the token
Hi Ludwig,
On 12/12/2018 11:05 AM, Ludwig Seitz wrote:
> On 12/12/2018 10:33, Stefanie Gerdes wrote:
>> Hi again,
>>
>> I have one additional comment to ace-oauth-17:
>>
>> Section 5.8.1 recommends that RS stores only one token per key and that
>> existing
Hi Hannes,
On 12/15/2018 04:04 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
> ~snip~
>
>
>> I also think that the client must be able to assume that RS' RPK that C
>> receives from AS is also valid as long as the token, unless C has additional
>> information.
>
> I would think that it is
Hi Hannes,
On 12/18/2018 02:51 PM, Hannes Tschofenig wrote:
> ~snip~
>
>
> Now that I got a response from the OAuth working group (in the sense that I
> was thinking about the claims in the access token rather than the parameters
> in the response from the AS) I think checking the expires_in
Hi Hannes,
I think the text is much better now. Protecting the integrity of
self-contained tokens is not sufficient, however. The RS must not only
ascertain that the token is integrity-protected but also validate its
authenticity, i.e., that it stems from an authorized AS.
Viele Grüße
Steffi
Hi Jim,
thank you for your quick response.
On 12/11/2018 09:38 PM, Jim Schaad wrote:
>>
>> C may receive keying material for the communication with RS from AS.
>> Unfortunately, the AS does not inform C how long the keying material is
> valid. C
>> therefore may use outdated keying material for
Hi again,
I have one additional comment to ace-oauth-17:
Section 5.8.1 recommends that RS stores only one token per key and that
existing tokens are overwritten by new tokens. I wonder how the RS knows
which token is the most recent. I don't think the expiration time helps
in this case because
Hi,
I looked through the document again. Many issues have been fixed, but I
still have some comments:
I still think that Section 5.8.1, in particular 5.8.1.1 should point out
that RS must check the integrity of the token und validate that it stems
from an authorized AS. Checking the iss field
Hi Ludwig,
>>
>> I am currently only referring to the keying material that AS provides to
>> C, i.e., the symmetric key shared between C and RS or, if asymmetric
>> keys are used, RS's RPK. Since it is clear to you that symmetric keys
>> are only valid as long as the token, you should point that
Hi all,
as I understand the current proposal of the ACE framework, an attacker
can send an access token to the RS that only contains a scope and is not
signed or otherwise protected. Section 5.8.1.1 (titled verifying an
access token) does not state that RS must check the authenticity of the
Hi Hannes,
On 12/18/2018 04:26 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
>> In OAuth, the expires_in field is usually used to inform the client how long
>> the access token is valid. If the client uses the access token in a request
>> after the token expired, the RS will reject the request,
Hi Hannes,
On 12/19/2018 12:36 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
> Are you focused on token expiry or the case where a token + symmetric key has
> been leaked?
I am talking about the expiry of the keying material for RS that AS
provides to C.
>
> Is the threat you are describing
Hi John,
On 09/09/2020 11:36 AM, John Mattsson wrote:
>>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will
>>> happily send the AS address to any node that asks. This causes two
>>> problems.
>>>
>>> - If C acts on the unauthorized information, this is an attack vector
>>>
Hi Ludwig,
comments inline.
On 09/10/2020 08:49 AM, Seitz Ludwig wrote:
> Seeing that the mechanism was introduced to bootstrap a client that doesn't
> know which AS to talk to for a specific RS and given the issues raised by
> John, what other options do we have that are more secure?
The
Hi Jim,
comments inline.
On 09/10/2020 12:11 AM, Jim Schaad wrote:
> A compromised RS may use the hints for attempting to trick a client into
> contacting an AS that is not supposed to be in charge of that RS.
> Therefore, C must not communicate with an AS if it cannot determine that this
>
n error message would be
> if the error message contained something like sign(AS, RS), but this is
> something that is not discussed in the draft.
>
> Cheers,
> John
>
> ___
> Ace mailing list
> Ace@ietf.org
> https
Hi John,
On 09/07/2020 12:45 PM, John Mattsson wrote:
>
> The mechanism is not presented as an error message when the client in good
> faith tries to access a resource. It is presented as something C do
> intentionally to dicsover the AS. In the description in the draft, C is
> clearly aware
Hi all,
On 09/10/2020 02:10 PM, Stefanie Gerdes wrote:
> We also should decouple the AS request creation hints from the
> explanation of the AS discovery mechanism. The hints have the additional
> purpose that they may contain the resource server's cnonce that the
> resource server c
Hi Christian,
On 07/13/2020 05:12 PM, Christian Amsüss wrote:
>
> * A malicious attacker intercepts the discovery process, and tells C
> that there is an RD at
> `;rt=core.rd`
> (which is a perfectly legitimate service we're running there for
> commercial purposes; its interface is that
Hi Lars,
Thank you for your detailed comments, and sorry for the late reply. We
addressed the issues as suggested. Sorry for the late reply.
Thank you for your time,
Steffi
On 3/24/21 6:56 PM, Lars Eggert via Datatracker wrote:
> Lars Eggert has entered the following ballot position for
>
Hi Roman,
Thank you for your detailed comments. We addressed most of your comments
in the latest version. Please find my comments inline.
On 3/23/21 4:32 AM, Roman Danyliw via Datatracker wrote:
>
> --
> DISCUSS:
>
Hi Francesca,
Thank you for your detailed comments, and sorry for the late reply. We
addressed most of your comments in the latest version. Please find my
comments inline.
On 3/24/21 4:49 PM, Francesca Palombini via Datatracker wrote:
>
>
Hi Murray,
Thank you for your comments, and sorry for the late reply. We addressed
most of the issues in the latest version, but I have one comment (see
below).
On 3/25/21 5:28 AM, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
>
On 02/11/2021 04:26 AM, Daniel Migault wrote:
>
> OLD: section 6.2
> "Profiles MUST specify how communication security according
>to the requirements in Section 5 is provided."
> NEW:
> section 6.2 is focused on security but the security requirements are
> provided in section 5. We may
Hi,
I propose that we use the following text for the ACE framework (as
originally proposed by Göran):
Section 6.2:
OLD
"Profiles MUST specify how communication security according
to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are
Hi Daniel,
On 02/16/2021 04:53 PM, Daniel Migault wrote:
> Section 5:
> OLD
> "Profiles MUST specify a communication security protocol that provides
>the features required above."
> NEW
> "Profiles MUST specify at least one communication security protocol that
> provides the features
26 matches
Mail list logo
