Subject: [Ace] FW: RS Synchronized Time

From: Francesca Palombini <[email-masked]>
Date: Mon, 4 Apr 2016 14:32:11 +0000

Hi,

Slides just showed by Renzo, for those wondering in Jabber :)

Francesca

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Renzo Navas
Sent: den 17 mars 2016 15:43
To: [email-masked]
Subject: Re: [Ace] RS Synchronized Time

Hi All,

I have mapped some nonce-based three party authenticated key establishment protocols for a REST/OAuth-like Scenario. I focused on the flows of messages, and not on the crypto content.

The messages/protocols do have any timestamp and the nodes do not need to have absolute time (wall clock) awareness.
In the literature is known that timestamp based authkey protocols have a theoretical lower bound (of nr of messages exchanged) of one less message that nonce-based solutions. In the REST mappings I present here the Req/Response model always introduce an overhead of at least one message. Some fine-tunning can be done (for not having let's call it "REST overhead") but I have not dealt with that.

I did the mapping on the like of the last slide from the last's ACE interim meeting ( https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-5.pdf
 ) -appropiate acknoledgment, thank you!- , but not adding so much REST detail.

At the end of the document there is a résumé of the nr (and type of) messages each entity will have to send or receive.

On a first look, I see that some protocols are too burdensome for a constrained REST-like implementation (e.g: "Yahalom"), burdersome for me is too much messages that will consume energy mostly for the Constrained RS.
But others seems to map well (there are two rest-variations for each auth key protocol), like "Otway-Rees/BBF (A=RS)"; "3PKD" (both
variations) and "Boyd (A=C)".

I do not deal with the Crypto content (quantity of encryption/decryption or MAC operations. but on these kind of protocols there are only three cryptoprimiotives encryption, decryption and mac calculation operations).

BUT a security aspect (VERY important) not mentioned is that not all protocols have a formal proof of security; Notably 3PKD ( a modified version by Kim-Kwang Raymond Choo) have been proven provably secure on the CK (Canetti-Krawczyk) 2001 Model (the strongest).
Boyd and Yahalom has been proven secure on the Bellare-Rogway 93'
model (weaker than CK2001).

I may be put more effort on actually mapping one of these solution for a OAuth-PoP profile document.
Another idea to add flexibility (without putting burden on the RS) If C first contacts the AS, he can learn which PoP-token the RS supports.

Regards to all, and I hope that this is on the interest of anyone, I am open to discussion

Have a good Thursday,

Renzo

---

From: Renzo Navas <[email-masked]>
Date: Mon, 4 Apr 2016 12:10:03 -0300

Hi All,

Thank you Francesca. I was a bit nervous as it is the first time I
presented something at IETF. I did not pass further than the 4th
slide... So I think I couldn't make my point so clear.

Basically the point I wanted to rise is:

There exists several nonce-based (auth key est.) well-known protocols
that can be used to solve the pop token generation.
If you skim through the slides you will see there are lots of
possibilities and much room to profiling (and confusion).

I wanted to rise the question on the mailing list to try to arrive to
a sort of discussion on which mappings do make sense (if any..) to
solve our problem.
I would gladly work on this.

Renzo

ps: I correct a mistake from my original message:

"The messages/protocols do NOT have any timestamp and the nodes do not need
to have absolute time (wall clock) awareness."

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 4 Apr 2016 20:51:40 +0200

> I would gladly work on this.

Renzo,

I see one problem with all the approaches presented in your slides 
except for Otway-Rees/Bauer-Berson-Feiertag: They all seem to require 
full connectivity. Now in several usecases we have either C or RS 
without direct connectivity to AS. I wouldn't want to work towards a 
solution that excludes those usecases.

If I'm not mistaken the proposal Göran presented is basically Otway-Rees 
integrated in the COAP request response protocol (steps 1. and 4.) and 
the OAuth token request or introspection protocol (steps 2. and 3.). My 
understanding is that Göran is not designing a new protocol, but 
adapting an existing one to the specific use case.

@Göran: Would that be a fair description of your proposal?

/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 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Apr 2016 00:12:38 +0200

Hi Navas,

thanks for your contributions and great that you made it to this IETF
meeting!

As discussed at the meeting today there will be a design team with the
following persons: You + Ludwig + Carsten + Thomas

It was clear from the discussions that there are several design aspects
to take into account. Since I am always a big fan of re-using existing
work I am sure your input on the different authentication and key
exchange techniques will be valuable.

I also want to have a solution for the authorization question where the
problem can be described as: The RS needs to know whether the
authorization information in an access token (either one that has just
been received or cached from a previous interaction) is still valid.

We also need to take the state-of-the-art in hardware capabilities (such
as real-time clocks in modern embedded processors) and the different
sleep states offered by these processors into account. IMHO it would be
good to have some prototyping efforts so that we are not just guessing.

Ciao
Hannes

On 04/04/2016 05:10 PM, Renzo Navas wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Göran Selander <[email-masked]>
Date: Tue, 5 Apr 2016 16:46:54 +0000

Hi Ludwig and Hannes,

In response to Ludwig’s question and Hannes's requirement on verifying
validity of authorization information.

I tried to formulate a proposal in the meeting yesterday. Maybe it wasn’t
understood, or maybe it wasn’t good enough? I’ll recap, let me know what
issues you see. 

My proposal is that we assume some sense of time in the RS (wall-clock,
event based etc.), and the ability for the RS either a) to keep time (as
for example the case David mentioned in the f2f meeting yesterday), or, b)
to synchronise time with a "time server”, which may be the AS - given that
the RS can access the "time server”.

Assuming these assumptions are reasonable, what remains to solved is the
“RS offline” case (local token verification), when the RS does not have
direct access to a time server. In this case, we could use a protocol like
that of slide 5 in
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-inter
im-2016-ace-1-5.pdf

This is not a nonce-based AKE. It is simply a challenge-response protocol
containing some updated time information between parties that have a
security association.

Is that a reasonable solution?

General comment: I think part of the work for the “RS synchronised time”
design team is to formulate the complete problem statement what we need to
use time for. 

Göran

---

From: Mohit Sethi <[email-masked]>
Date: Tue, 5 Apr 2016 18:15:07 -0300

Hi All

The discussion during the WG meeting on Monday about Synchronized time 
also made me wonder if anyone has had a look at Lamport's vector clocks:

http://www.citemaster.net/get/10b50274-7bc5-11e5-8aa1-00163e009cc7/p558-lamport.pdf

So if the participating entities: C, RS, and AS at least have 
monotonically increasing clocks, then a vector of the three clocks can 
give some idea about the ordering of events. This probably does not 
solve the challenges, but might help to think of possible solutions.

/--Mohit

On 04/04/2016 03:51 PM, Ludwig Seitz wrote:
> If I'm not mistaken the proposal Göran presented is basically 
> Otway-Rees integrated in the COAP request response protocol (steps 1. 
> and 4.) and the OAuth token request or introspection protocol (steps 
> 2. and 3.). My understanding is that Göran is not designing a new 
> protocol, but adapting an existing one to the specific use case.
>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 05 Apr 2016 23:21:42 +0200

Or have a look at vector clocks;

https://en.wikipedia.org/wiki/Vector_clock

They guarantee advance, and with a few nodes the overhead is not too 
awful.

Peter

Mohit Sethi schreef op 2016-04-05 23:15:
> [1]
>> except for Otway-Rees/Bauer-Berson-Feiertag: They all seem to
>> require full connectivity. Now in several usecases we have either C
>> or RS without direct connectivity to AS. I wouldn't want to work
>> towards a solution that excludes those usecases.
>> 
>> Otway-Rees integrated in the COAP request response protocol (steps
>> 1. and 4.) and the OAuth token request or introspection protocol
>> (steps 2. and 3.). My understanding is that Göran is not designing
>> a new protocol, but adapting an existing one to the specific use
>> case.
>> 
> Links:
> ------
> [1]