Re: [Ace] ACE Framework Review

Stefanie Gerdes <> Wed, 24 October 2018 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F7C4127133 for <>; Wed, 24 Oct 2018 06:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mt4V7W0xnK-V for <>; Wed, 24 Oct 2018 06:53:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28995130EC2 for <>; Wed, 24 Oct 2018 06:53:32 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4F27427F8D; Wed, 24 Oct 2018 15:53:30 +0200 (CEST)
To: Jim Schaad <>, 'Ludwig Seitz' <>,
References: <> <> <02af01d46a4a$2c629790$8527c6b0$>
From: Stefanie Gerdes <>
Message-ID: <>
Date: Wed, 24 Oct 2018 15:53:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <02af01d46a4a$2c629790$8527c6b0$>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ace] ACE Framework Review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Oct 2018 13:53:49 -0000

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:
>> Subject: Re: [Ace] ACE Framework Review
>> On 10/10/2018 16:24, Stefanie Gerdes wrote:
>>> 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 fixed in the meantime).
>> Thank you for your review. Sorry for the long response time. Answers
> inline. I
>> also tried to add issues in the issue tracker, but github seems to be
>> experiencing trouble at the moment.
>> /Ludwig
>>> Validity of the access token (Token Expiration, Section 5.8.3): There
>>> seem to be additional requirements here that are currently not
>>> mentioned. It is not clear how RS determines the freshness of
>>> introspection messages (and how fresh they are).
>> That would be up to the commSec protocol, also it is covered in the
> security
>> considerations of RFC 7662. I will add a reference to those considerations
> in
>> our security considerations section.
> This seems to be a bit of an odd requirement to impose on the protocol and
> not on the RS.  The RS should have some type of idea of when it last asked
> the AS if it was valid and also some idea of when the AS said this was going
> to expire relative to when it last asked.  If the RS asks twice and the AS
> returns a cached answer that is on the AS and not on the RS.
> An RS with no sense of time could still implement a counter and ask the AS
> every nth access to the resource (potentially spreading that over all
> accesses by anybody).

A counter that RS starts before sending the introspection message would
help to solve this problem if a timeout is defined or if the
introspection message contains the lifetime of the token. If this is the
expected behavior of RS, it should be mentioned in the document.

>>> The sequence number approach has the problem that an attacker may
>>> withhold new tokens from RS. In this case, old tokens are infinitely
>>> valid. This is particularly damaging because C may have a strong
>>> interest to withhold new tokens and can easily do so by not relaying
>>> them to RS. This approach therefore must not be used unless there is
>>> an additional communication channel between RS and AS that regularly
>>> informs RS which the most recent sequence number is.
>> This is a best effort approach when the RS has no internal sense of time.
> Also
>> the idea was that several client could submit tokens with an ever
> increasing
>> unique serial number maintained by the AS. Thus even if one client would
>> withhold it's newer tokens to keep the old ones from expiring, the other
>> clients would eventually submit enough new tokens (with higher sequence
>> numbers) so that the token expires.
>> AFAIK the RS with no internal clock at all is a very rare occurrence, thus
> you
>> can usually expect some form of wallclock time, and thus implement an
>> expiration based on "time-since-you-received-this-token".
> Additionally one could use the clear everything after n accesses to
> resources.
>>> Management of the authz-info resource:
>>> * The authz-info resource is vulnerable to DoS attacks: clients may
>>> (with or without intention) send large numbers of access tokens to RS. A
>>> constrained RS may soon run out of memory/storage space if it needs to
>>> store large numbers of tokens.
>> A RS is not expected to store large numbers of tokens. Section 5.8.1
>> specifies:
>> "The RS MUST be prepared to store at least one access token for future
>>     use."
>> Thus the RS can adapt the number of tokens it stores to its constrained
>> storage resources.
> This might be a good place to reference the new core draft  - too many
> requests - as a reasonable response for an overloaded server in this case.
>>> The preferred mitigation should be that the
>>> authz-info resource is only used for protected communication. This does
>>> obviously not work for the RPK mode. In the PSK mode, RS should be able
>>> to decide that it uses the authz-info resource only for protected
> updates.
>> I don't think that will help, since somehow the initial access token
>> must get to the RS. So even when passing it through the DTLS handshake
>> (as with PSK in the DTLS profile) the same DoS risk exists.
> Going the DTLS handshake route might actually make things worse as you are
> now doing lots of additional process on the server side since you have added
> all of the DTLS work to the token validation work.

As I already pointed out in my response to Ludwig, transporting the
token in the DTLS handshake has the advantage that the RS can discard
the token if C is not able to finish the handshake. Also, DTLS has some
protection against DoS attacks. Uploading large amounts of access tokens
to a resource is very easy for a client.

>>> Validity of the access information:
>>> It seems that the people who wrote the framework did not consider that
>>> the keying material is not only provided to RS but also to C.
>>> How does C determine if the keying material it receives from AS is still
>>> valid?
>> It is valid as long as you don't get a 4.01 (Unauthorized) from the RS.
>>> The access token response may comprise an expires_in
>>> field that contains the validity period of the access token in seconds
>>> (RFC 6749), but does not specify the validity period of the keying
>>> material. But even if the validity periods are equal, C does not know
>>> when the access token was generated. Also, the use of the expires_in
>>> field is optional. Without protection, the access information is
>>> infinitely valid. C may use outdated and maybe compromised keying
>>> material to communicate with RS. The framework should provide
>>> information how C determines if the keying material is still valid.
>>> Also, C must check if the keying material it has for a communication
>>> partner is still valid before sending a request.
>> I would think that in most cases it is acceptable that the client just
>> optimistically sends its request with the existing keying material and
>> renews it if it gets back a 4.01.
>> Use cases where the security policy is such that this is unacceptable
>> should use a specific profile that defines additional mechanisms for the
>> client to check its tokens and associated keying material (e.g. by using
>> client introspection).
> I think that the use of the expires_in field in an AS response should cover
> this case sufficiently well for most cases where the client might care.  I
> would agree that the failure of a request is a good clue that a new token
> needs to be obtained.  I am not sure that it makes any sense to say that
> keying material has expired for the RPK case.  It only makes sense to have
> key lifetime for a POP symmetric token.  In that case I would expect that
> the lifetime of the token and the key material to be the same.  I would not
> think that a new token with expanded privileges on the same key material
> should last beyond the original POP token.  This does mean that there will
> need to be a more frequent DTLS negotiation but that is not difficult for a
> simple PSK with no asymmetric key.

RPKs do not have semantic information attached to them and they do
expire eventually. The AS must check if the keying material that it
provides to C is still valid at least as long as the token and then must
set the expires_in field to the remaining lifetime. To avoid attacks
where an attacker manages to withhold messages, the AS should specify
when the token was issued in an iat field.

>>> It is not clear how C makes plain to AS with which RS it wants to
>>> communicate. C may specify the intended audience in the token request
>>> using the req_aud parameter. How is RS represented in this case?
>>> C and AS must have a common understanding how RS is identified,
>>> otherwise C may communicate with the wrong RS!
>>> IP addresses may change and therefore are not suitable. If AS specifies
>>> identifiers for RS, C must securely obtain this knowledge.
>> Identifying the RS (using the audience claim and the req_aud parameter)
>> is application specific. Some applications may want to use public keys,
>> others will want to use fixed identifiers that are manually assigned or
>> otherwise generated.
>> The framework does not suggest IP addresses as a way to identify an RS.
> There are two cases here that need to be thought about.  The first is that
> the audience and the RS are synonymous.   In that case there is not a
> problem here.  The second case is an audience that exists on multiple
> servers. The question then is should the token be setup for a single RS or
> for every RS that hosts the audience?  I would expect it to be the latter as
> one could get a redirect at some point from RS1 to RS2 but it should not
> require that a new token be obtained just that it be re-posted.   The
> question you ask would only be if interest if one said that multiple RSs
> hosted a single audience and they all had to be keyed separately.

The audience seems to be some string that (not necessarily uniquely)
identifies RS. Appendix B states that the AS is expected to know which
audiences refer to the RS. I wonder how C knows which audience
identifies an RS. I think it is very important to point out that AS and
C must have a common understanding how RS is identified because
otherwise C will communicate with the wrong RS.

Viele Grüße