Subject: [Ace] RS Synchronized Time

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2016 18:53:49 +0100

Hi all,

on the mailing list and subsequently at the virtual interim meeting we
had a discussion about the requirements for time synchronization. It
seems that there are three possible approaches, namely

1) No requirement for real-time clocks and time synchronization at all.
2) Requirement for a real-time clock at the RS
3) Requirement for a real-time clock at the RS together with the need to
synchronize time with the AS.

At least Carsten was of the opinion that we need to support this
functionality and that it can be accomplished fairly easily.

On the mailing list there was not much support for this functionality.

Here are the slides from the ACE virtual interim meeting providing
further background information:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-5.pdf

If you have experience in this field and ideas on how the nonce-based
approach could work please share it with us.

Once we have enough details about the solutions we will have to make a
decision.

Ciao
Hannes & Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 02 Mar 2016 23:13:07 +0100

> functionality and that it can be accomplished fairly easily.

Clarification: I was arguing that a solution that is applicable to
constrained devices needs to address (1).  I was not arguing (2) or (3)
are needed (at least not for the PSK or RPK cases -- traditional
certificates obviously do need more powerful devices); they should not
be part of an MTI mandate.

Also, I should clarify that "no time synchronization" is in terms of
wallclock time -- there may or may not be a monotonous (boot relative)
time available to even a constrained device.  There may also be an
event-based mechanism of progressing a logical clock (cf. Lamport
timestamps for an example that is about as old as IP); what is needed
here depends on the application.

Modern Web frameworks use freshness indicators of this kind in the form
of authenticity tokens and similar anti-CSRF mechanisms, so I'm not sure
we have to spend a lot of time looking for them.

Grüße, Carsten

---

From: Renzo Navas <[email-masked]>
Date: Thu, 3 Mar 2016 18:58:45 +0100

HI Hannes, Kepeng, Carsten, All,

Sorry I was not present on yesterday's meeting.

>> synchronize time with the AS.

Regarding the approaches, I would like to see an ace solution for  (1).
If here is not the place to discuss and come up with a solution for
that type of constrained devices, where would it be?

As Carsten said, my understanding of the time limitation of scenario
(1) is that the node does not have wallclock time sincronization
(notion of absolute time) -he could have internal clock- ; not having
wallclock time is enough to  make the current PoP token approach
(Denning-Sacco shared key-like) to not be feasible (or any timestamp
authenticated key establishment approach).

One clarification: I see the PoP token as a new fresh shared key
between previously unknown parties, hence I treat the base PoP-token
problem as an Authenticated Key Establishment-problem.

Replying to Hannes request for ideas:

In late 2015 I've been working on the authenticated key establishment
problem, and I've studied several nonce-based approaches on the third
party scenario.

 * How can I help? Maybe I can make a set of slides with the the
nonce-based approaches I studied (I mentioned some here
http://www.ietf.org/mail-archive/web/ace/current/msg01554.html),
and map it to the  REST OAuth Scenario: Client, Resource Server, and
AS ? (like on slide 5 of
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-5.pdf)

then if its worthy a draft with a nonce-based flow oauth pop token?
Maybe is better first to have a high level idea of how the different
nonce based protocols will map to the pop rest oauth architecture.

Regards

Renzo

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 13:59:43 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > 3) Requirement for a
    > real-time clock at the RS together with the need to synchronize time
    > with the AS.

    > functionality and that it can be accomplished fairly easily.

I'd like to hear more about this.

I don't understand why you write that we need to "support this
functionality", --- it seems that this is functionality that we need to
require from the underlying operating system or due without.

In this list, I think that having a monotonically, but not necessarily
real-time, clock is easily provided, and provides what we need need.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Mar 2016 20:43:55 +0100

> I'd like to hear more about this.

https://mailarchive.ietf.org/arch/msg/ace/7UitoDFiRnxrNxOHvOMEmm5TcDs

Grüße, Carsten

---

From: Renzo Navas <[email-masked]>
Date: Thu, 17 Mar 2016 15:43:16 +0100

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