Subject: [Ace] Authenticated Key Establishment, OAut PoP Token and Time Requirements for Constrained Devices

From: Renzo Navas <[email-masked]>
Date: Fri, 13 Nov 2015 17:30:50 +0100

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

---

From: Göran Selander <[email-masked]>
Date: Mon, 16 Nov 2015 08:22:55 +0000

Hello Renzo,

Thanks for kind feedback and good questions. I think your questions
deserves further analysis beyond what is included in this first version of
the draft. The purpose of this version of the draft is to demonstrate the
feasibility to use OAuth 2.0 with some modifications in a large variety of
constrained node deployment scenarios. Lack of synchronized time is one
characteristic that needs to be further detailed. Here are some first
answers from me, others may also want to comment:

* As you already noted, time provides freshness in authentication of key
establishment as well as defines validity of authorization information. So
in settings where the RS may occasionally loose time but can communicate
with a trusted node to set time, that may be preferable rather than
running a nonce-based key establishment protocol with a TTP.

* In cases where both C and RS as offline (example in section 6.1) there
is neither the option to synchronize time nor running a TTP-assisted key
establishment protocol. In this case I believe the best we can hope for is
replay protection of access token, so the RS at least knows that this key
has not been used before.

* In case the access token is replay protected and TLS/DTLS is used
between C and RS, additional assurance is provided by the handshake, but
the residual threats needs to be assessed.

* In a severely energy constrained setting (example in section 6.5) key
establishment in the RS may not be affordable in which case the current
key to use is obtained by the C from the AS (which requires appropriate
security considerations).

Having said this I believe there are settings where a nonce based
authenticated key establishment makes sense. There are several
alternatives to embed such a protocol in OAuth 2.0, e.g. Otway-Rees when
using the token introspection flow, or the version of Boyd you referenced
in the flow without token introspection. In the former case, time
synchronization may be preferred as noted above. But in the latter case,
RS offline (example in section 6.2), this may be the right thing to do.
That would then e.g. require a nonce to be transported in the access
token, which is one example of non-JWT claim we would need to add in our
ACE access token profile.

You are most welcome to contribute to this work; identifying under what
conditions such a protocol may be relevant and which information elements
to embed in the message flow.

Regards
Göran

On 2015-11-13 17:30, "Renzo Navas" <[email-masked]> wrote:

>[3] 3PKD - 
>http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf

---

From: Renzo Navas <[email-masked]>
Date: Wed, 18 Nov 2015 11:27:18 +0100

Hello Göran, thanks for your kind response,
I doubted I will get any because my mail was a bit obscure, this time
I will try to be brief.

>  The purpose of this version of the draft is to demonstrate the
> constrained node deployment scenarios.

Indeed the document does achieves that. My opinion after reading it is
that OAuth is flexible and powerful, provides a desirable solution,
and can be further extended.

> authenticated key establishment makes sense.

I do think so too. Restricting the RS to either to be
time-synchronized or to do always the token-introspection flow for me
it's too severe.

> to embed in the message flow.

As you said there may be use cases/scenarios when nonce-based  pop
tokens , with differentce messages flows, will make sense.
So if other people think so too, I can try to work on that (I have
null exprience on ietf writing).

Thanks again for your response,

Renzo

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 Nov 2015 10:19:51 +0100

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,
> 
> _______________________________________________
> 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]
-------------------------------------------------------