Hi,
I looked through the ACE framework document. I think there are some open
issues that need to be addressed. I will try to summarize the main
issues below. We provided a rough analysis of the DTLS profile in [1],
which may also be interesting (many of the issues mentioned there were
already fixe
ework does not suggest IP addresses as a way to identify an RS.
>
>> The framework must point out that AS must check if the keying material
>> that it provides to C in the access token response actually refers to
>> the RS that C wants to communicate with. The problem of mixups
>&
Hi Jim,
On 10/22/2018 10:59 PM, Jim Schaad wrote:
>
>
>> -Original Message-
>> From: Ace On Behalf Of Ludwig Seitz
>> Sent: Monday, October 22, 2018 6:08 AM
>> To: ace@ietf.org
>> Subject: Re: [Ace] ACE Framework Review
>>
>> On
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 doe
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 t
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 it
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 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 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
token,
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 o
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,
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 rath
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 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, w
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 the
Hi Ludwig,
That's better, thanks.
Viele Grüße
Steffi
On 01/11/2019 02:09 PM, Ludwig Seitz wrote:
> Hi,
>
> I've merged Hannes' PR, fixed a typo and added a sentence as follows:
> =
> For self-contained tokens the RS MUST proces
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 y
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 John,
C must not communicate with an AS which it doesn't trust. As stated in
section 6.5, "the client MUST be able to determine whether an AS has the
authority to issue access tokens for a certain RS." The client would
therefore notice if RS or an attacker tries to trick C into
communicating wi
of an 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
>
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
>>> f
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 mec
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
> AS
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 ser
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 sim
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 s
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 require
Hi Roman,
Thank you very much for your detailed comments!
We addressed your comments with two exceptions as explained in detail
below. You can see most of the changes at
https://github.com/ace-wg/ace-dtls-profile/commit/a9ee40dff5093f1cf43e1b734eb6e02745f43f4d
On 3/23/21 4:32 AM, Roman Danyliw v
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
> draft-iet
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 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 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
> draft
32 matches
Mail list logo