Subject: [Ace] Time Requirements for Constrained Devices

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jan 2016 16:16:34 +0100

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: Göran Selander <[email-masked]>
Date: Thu, 21 Jan 2016 17:40:41 +0000

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?

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.

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.

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.)

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.

Göran

On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig"
<[email-masked] on behalf of [email-masked]> wrote:

>> 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.
>> 
>>> protocol ( 
>>>http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html
>>> [3] 3PKD - 
>>>http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jan 2016 21:00:11 +0100

Hi Goeran,

thanks for your response.

> pre-shared keys. For these cases there is not necessarily time related

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.

> be possible to verify change of permissions and revokation.

Correct.

> 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.

> 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.

> 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