Subject: Re: [Ace] Time Requirements for Constrained Devices

From: Renzo Navas <[email-masked]>
Date: Mon, 8 Feb 2016 11:52:11 +0100

Hi Hannes, Hi All,

Sorry for the late reply, I was out of work + out of ACE-ML;

I am glad Hannes that my message raised an interesting debate/question.

I have not done advancements on the field since my last message; but
as I said my opinion is that we should have in account Resource
Servers that do not have Time Information. Otherwise I think demanding
Time-awareness at the RS is a very strong requirement (not so
constrained).

I am trying to come up with a AA solution+implementation for the
simplest Use Case I can think-of and that involves having a very
constrained RS (meaning no Real Time Clock nor time sync protocol);
The Proof-of-possession token solution is and ideal tool on this
constrained scenario as it will permit negotiate a fresh symmetric-key
between the previously unknown Client and the RServer. This Key will
be used to establish an authenticated secure channel between C and RS.
However as I discussed before, if no absolute time awareness is
present at RS: either we need token introspection, or we need another
flow of messages and a nonce-based approach to generate the shared
key/PoP Token.
I will go internally for the second option, but as Hannes mentioned
this adds complications for the revocation mechanism.

My opinion and belief, is that Use Cases where the RS do not have time
information will be very common on real deployments.

Either we can say that UC can be solved by token introspection, or we
will have to explore other solutions.

Regards and good start of the week!

Renzo

On Tue, Jan 26, 2016 at 9:00 PM, Hannes Tschofenig
<[email-masked]> wrote:
> Hi Goeran,
>
> thanks for your response.
>
> On 01/21/2016 06:40 PM, Göran Selander wrote:
>> Hi Hannes,
>>
>> Good discussion input, some comments:
>>
>> You write certificates, but CoAP also support raw public keys and
>> pre-shared keys. For these cases there is not necessarily time related
>> information, is there?
>
> It is true that with raw public keys and pre-shared secrets the
> situation is a bit different. Nevertheless the requirement for time
> information still does not necessarily disappear since there is still
> the access token that may contain claims like issued at, not before, and
> an expiry date.
>
>>
>> If the use case does not allow the RS to be online with AS or time server
>> at all times (for reasons of connectivity such as container use case etc.,
>> or for reasons of communication budget) then you are right that it may not
>> be possible to verify change of permissions and revokation.
>
> Correct.
>
>>
>> But still it may be possible for the RS to:
>> - invalidate short lived access tokens (counting down using internal clock)
>> - verify that access tokens are not replayed (using nonce or sequence
>> numbers)
>> which is sufficient in terms of timely authorization in some cases.
>
> Access tokens don't contain sequence numbers or nonces since otherwise
> they will become on-time-tokens.
>
> Using an "internal clock" is not sufficient since such a real-time clock
> needs to have a reference to know whether a "short lived token" is
> indeed fresh.
>
>>
>> Furthermore a client may have access to the AS even if the RS doesn’t, and
>> through a new access token provide fresh information to the RS. (The RS
>> would in this case not know that an access token is recent, but in case of
>> sequence numbers that it is more recent than previous.)
>
> It is indeed possible that the client may have access to the AS but you
> are in essence suggesting
>  * one-time-tokens, and
>  * keeping state (such as a sequence number) at the RS.
>
>
>>
>> I think we should support deployments which does not require RS to keep
>> external time, and accept that those deployments will not be able to
>> support immediate revocation.
>
> The problem is that it come for free. So, we need to make an informed
> decision. For that reason I am reaching out to folks in this group to
> determine whether there is indeed interest in deploying such solutions.
>
> Ciao
> Hannes
>>
>> Göran
>>
>>
>>
>> On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig"
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>> Hi Renzo, Hi all,
>>>
>>> thanks for your review comment since you raise a bigger issue. The
>>> review feedback was recorded as issue#12 at
>>> https://github.com/LudwigSeitz/ace-oauth/issues/12
>>>
>>> You are asking what our requirements for the Resource Server (RS) are
>>> with regard to the availability of time information (and the accuracy of
>>> it). Our solution building blocks currently require time information,
>>> such as certificates and access tokens.
>>>
>>> In your email write-up, see
>>> http://www.ietf.org/mail-archive/web/ace/current/msg01554.html, you
>>> correctly pointed out that there is a relationship with the validity of
>>> the authorization information and with a potential revocation mechanism.
>>>
>>> Before we start working on solutions I would like to get a sense of the
>>> group what the views are. For resource servers do you consider to
>>> incorporate a real-time clock and a protocol mechanism that obtains time
>>> information?
>>>
>>> Not having time information at the RS will have the following impact:
>>>
>>> * The RS somehow has to get information about access tokens where
>>> permissions have changed, where the access tokens have been revoked or
>>> have otherwise been invalidated since the tokens do not contain validity
>>> information.
>>> * Time-related information in certificates cannot be checked.
>>>
>>> In many situations we will have a tradeoff between the availability of
>>> time information and the required communication overhead for interacting
>>> with an authorization server to obtain up-to-date information about the
>>> validity of the credentials.
>>>
>>> What does the group think?
>>>
>>> Ciao
>>> Hannes
>>>
>>>
>>> On 11/19/2015 10:19 AM, Rafa Marin Lopez wrote:
>>>> Hi Renzo:
>>>>
>>>> I agree with you that if we consider the distribution of a symmetric
>>>> key between three parties the literature is full of very concise and
>>>> security proven protocols.
>>>>
>>>> Please count on me if some help is required in this area.
>>>>
>>>> Best Regards.
>>>>
>>>>
>>>>> El 13 nov 2015, a las 17:30, Renzo Navas <[email-masked]>
>>>>> escribió:
>>>>>
>>>>> Good Evening ACE ML,
>>>>>
>>>>> Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for easy
>>>>> to read doc) I was very interested by the PoP token that offers an
>>>>> authenticated fresh key to be used for further secure the comm.,
>>>>> but I saw a very strong requirement for the RS to have a Time Sync.
>>>>> mechanism.
>>>>> I preview the objective of my mail,  is to raise the question:
>>>>>
>>>>> * Do we want to have a strong requirement for the constrained device
>>>>> (RS) on an AA Architecture to have a Time Synchronization mechanism?
>>>>> * Are we interested on offering non-time -nonce- based solution for an
>>>>> OAuth PoP Token approach (for example when the token does not expire)?
>>>>>
>>>>>
>>>>> (those interested on those concerns can read the rest of the mail,
>>>>> that is rather long)
>>>>>
>>>>> Regards
>>>>>
>>>>> -------------------------------------------------------
>>>>>
>>>>> (Long version)
>>>>>
>>>>> I've been working lately on the Authenticated Key Establishment
>>>>> problem (The are two very good reference books [1][2]), focusing on
>>>>> solutions with a Trusted Third Party, Symmetric Crypto, and not using
>>>>> Time-stamps but Nonces (To avoid having to deal with time
>>>>> synchronization).I have no strong Crypto background.
>>>>>
>>>>> First I want to thank the authors of draft-seitz-ace-oauth-authz-00 ,
>>>>> very enlightening for the oauth neophytes.
>>>>> I'm mostly interested on the authentication problem (auth. key
>>>>> establishment), so the Proof-of-Possesion Token is a great
>>>>> tool/concept, I took the time to read
>>>>> draft-ietf-oauth-pop-architecture-05 and
>>>>> draft-ietf-oauth-pop-key-distribution-02 to try to have all the
>>>>> background possible.
>>>>>
>>>>> So from the Authenticated key establishment mechanism point of view a
>>>>> new fresh key between C and RS obtained by means of a  PoP Token
>>>>> mechanism -I think- will be similar to a  Denning-Sacco shared key
>>>>> protocol (
>>>>> http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html
>>>>> . Client is A, AS is S, and RS is B), with the difference that the PoP
>>>>> Token Timestamp have a start and end value that will make the
>>>>> "mutiplicity attack" of Denning-Sacco limited on time.
>>>>>
>>>>> My concern is that we will always need Time sync on the RS, that some
>>>>> (most) times will be the constrained node (I think that the Client
>>>>> does not need to be Time-aware), is that a MUST requirement? So
>>>>> no-time aware devices will not be able to use OAuth PoP Token (or will
>>>>> have to use token introspection, a good fallback solution btw)
>>>>>
>>>>> Will be of interest offering a PoP Token generation and transport
>>>>> mechanisms that  offers an authenticated fresh key without the need of
>>>>> Time-awarenness at the RS?
>>>>>
>>>>> Time awareness at the RS offers great advantages, and maybe also Time
>>>>> is always needed in all authorization solutions (to make easy token
>>>>> expiration and freshness claims).
>>>>>
>>>>> But I'm thinking about nonce-based authenticated key establishment. Of
>>>>> course without time information embedded on the token, token
>>>>> expiration will be more difficult:
>>>>> * we will need token introspection, or
>>>>> * the AS will contact the RS to revoke tokens, or
>>>>> * we will need on a non-time based solution for revocation that does
>>>>> not involve the AS, for example: a pop token/key is valid for use only
>>>>> for one (or N) Resource Requests (of course if the response message
>>>>> get lost we are screwed...)
>>>>>
>>>>>
>>>>> So maybe we cannot avoid to have Time-awareness at the RS, for
>>>>> Authorization purposes..
>>>>> But for Authentication certainly we can avoid Time, the three most
>>>>> recommended by [2] nonce-based protocols are:
>>>>> * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven
>>>>> provably secure on the strongest model to test auth. key establishment
>>>>> protocols ] [3]
>>>>> * Yahalom [a modified version has been proven secure on a weaker model
>>>>> -bellare rogway- than 3PKD] [4]
>>>>> * Boyd [Key Agreement: RS, C and AS contribute inputs to generate the
>>>>> key] [proof idem yahalom ][5]
>>>>>
>>>>> The message flows on that three of protocols do not respect OAuth
>>>>> flows (I attach an image with the high level message flows, A is the
>>>>> initiator always), so that take us apart a bit from OAuth...
>>>>>
>>>>> This mail is starting to get long so I will try to conclude it, but
>>>>> hopefully raise the question:
>>>>>
>>>>>
>>>>> ** Are we interested on offering non-time -nonce- based solution for
>>>>> an OAuth PoP Token approach (for example when the token does not
>>>>> expire)**?
>>>>>
>>>>>
>>>>>
>>>>> If NO, I guess that will need token introspection for RS that cannot
>>>>> support time (That mechanism will map to other authenticated key
>>>>> establishment protocol and not Denning-Sacco-based )
>>>>>
>>>>> if YES, are we interested in adapting a nonce-based auth. key
>>>>> establishment protocol to OAuth PoP Token?
>>>>>
>>>>>
>>>>> I hope this questions are useful,
>>>>>
>>>>> Best regards
>>>>>
>>>>> Renzo
>>>>>
>>>>>
>>>>>
>>>>> [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key
>>>>> Establishment and Authentication. Springer-Verlag New York, Inc.,
>>>>> Secaucus, NJ, USA.
>>>>> [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.).
>>>>> Springer Publishing Company, Incorporated.
>>>>>
>>>>> [3] 3PKD -
>>>>> http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf
>>>>> [4] Yahalom - https://eprint.iacr.org/2007/188.pdf
>>>>> [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf
>>>>>
>>>>> ____________________________________
>>>>> ___________
>>>>> Ace mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>> -------------------------------------------------------
>>>> Rafael Marin Lopez, PhD
>>>> Dept. Information and Communications Engineering (DIIC)
>>>> Faculty of Computer Science-University of Murcia
>>>> 30100 Murcia - Spain
>>>> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
>>>> -------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ace mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>
>>
>

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 10 Feb 2016 14:19:59 +0100

Hi,

See below.

> On 08 Feb 2016, at 11:52, Renzo Navas <[email-masked]> wrote:
> 
> Hi Hannes, Hi All,
> 

I propose that we add this scenario to the section that describes the functionality and rational behind introspection. This highlights the requirement of resource servers without means of keeping time and the fact that access token introspection is a solution for this. When we have explored other solutions we can augment the draft by either adding new sections or complement it with new drafts that detail this scenario.

I propose that we change the text describing introspection in section 3.1 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00#section-3.1 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00#section-3.1> to look like the following:

   Introspection:

      Introspection is a method for a resource server to query the
      authorization server for the active state and content of a
      received access token.  This is particularly useful in those cases
      where the authorization decisions are very dynamic and/or where
      the received access token itself is a reference rather than a
      self-contained token.  Resource servers that don't have the means
      to keep time can also offload the validation of timed access
      tokens to the introspection resource on the authorization server.
      More information about introspection in OAuth 2.0 can be found in
      [I-D.ietf-oauth-introspection].

Does that sounds reasonable. I’ll add it to the draft for now so it will be in the -01 revision, but I’m open for feedback.

/ Erik

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 10 Feb 2016 15:46:25 +0100

On 02/10/2016 02:19 PM, Erik Wahlström wrote:
>
> I propose that we add this scenario to the section that describes the
> functionality and rational behind introspection. This highlights the
> requirement of resource servers without means of keeping time and the
> fact that access token introspection is a solution for this. When we
> have explored other solutions we can augment the draft by either adding
> new sections or complement it with new drafts that detail this scenario.
>

The problem is that if a device is not able to keep accurate time, it 
often coincides with also not being able to do real-time 
over-the-network introspection.
You have to consider that a very constrained device will struggle to 
keep the security context for one secure connection in memory (together 
with the internet protocol stack and the application it is running), if 
we now say that it should also do introspection, we basically force it 
to keep two secure connections in memory at the same time, and that is 
not a good idea.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 11 Feb 2016 12:17:08 +0100

I think it’s one of those problems that’s hard (i.e. not impossible) to solve in the perfect way that's simple, secure and always up to date with latest policies, especially with the diversity of both devices and required security.

- You either do a best effort and just validates the access token.
- We would then also propose an alternative to get real time updates using the introspection endpoint.
- And third and last we would open up for potential future work being done to solve it once and for all (as suggested in earlier discussions on the list).

I think that’s a good level of commitment for first version.

/ Erik

> On 10 Feb 2016, at 15:46, Ludwig Seitz <[email-masked]> wrote:
> 
> The problem is that if a device is not able to keep accurate time, it often coincides with also not being able to do real-time over-the-network introspection.
> You have to consider that a very constrained device will struggle to keep the security context for one secure connection in memory (together with the internet protocol stack and the application it is running), if we now say that it should also do introspection, we basically force it to keep two secure connections in memory at the same time, and that is not a good idea.
> 
> /Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70 349 9251
> http://www.sics.se
>