Subject: [Ace] Offline operation of Resource Server

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 13:35:54 +0200

Hi all,

in one of my previous mail I said that the requirements rule out an
EAP/AAA solution and this impression was based on reading the following
requirement from http://tools.ietf.org/html/draft-seitz-ace-usecases-01

"
   o  U5.2 The meters must be able to perform fine-grained access
      control on the metering data and on the configuration while being
      offline.
"

I was wondering how strong the requirement for not having a real-time
interaction between the resource server and the AS is.

Ciao
Hannes

---

From: Josh Howlett <[email-masked]>
Date: Mon, 14 Jul 2014 11:43:24 +0000

A strict requirement for offline operation need not necessarily exclude an AAA/EAP solution. It is perfectly possible, for example, to use GSS EAP pre-authentication to obtain a Kerberos ticket from a KDC. There is running code.

Josh.

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: 14 July 2014 12:36
> To: [email-masked]
> Subject: [Ace] Offline operation of Resource Server
> 
> Hi all,
> 
> in one of my previous mail I said that the requirements rule out an EAP/AAA
> solution and this impression was based on reading the following

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 13:44:32 +0200

Interesting point, Josh.

On 07/14/2014 01:43 PM, Josh Howlett wrote:
> A strict requirement for offline operation need not necessarily
> exclude an AAA/EAP solution. It is perfectly possible, for example,
> to use GSS EAP pre-authentication to obtain a Kerberos ticket from a
> KDC. There is running code.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 14 Jul 2014 14:07:24 +0200

+1.

That is what we had also in mind with our EAP/AAA solution (for bootstrapping). In fact, although not in the context of IoT, UMU has been working in bootstrapping Kerberos with EAP/AAA authentication. We think some of the ideas could be still applicable here. As Josh mentioned we have running code.

Best Regards.

- Rafael Marin-Lopez, Fernando Pereniguez, Gabriel Lopez, and Alejandro
Perez-Mendez. Providing EAP-based Kerberos pre-authentication and
advanced authorization for network federations. Computer Standard &
Interfaces, 33(5):494-504, 2011.

- Alejandro Perez-Mendez, Fernando Pereniguez-Garcia, Rafael Marin-Lopez, and
Gabriel Lopez-Millan. Out-of-band federated authentication for Kerberos
based on PANA. Elsevier Computer Communications, 36(14):1527 1538, 2013.

El 14/07/2014, a las 13:44, Hannes Tschofenig <[email-masked]> escribió:

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jul 2014 14:01:39 -0400

> interaction between the resource server and the AS is.

I think it is important to have the tokens able to be validated offline
within some deployment specific time interval.  For some deployment "99
years" is exactly what is desired, for other deployments having to be online
is what is desired.

The missing piece is enrollment of devices (must be online), and associated
with that is the initial exchange of authorization tokens.

My view is that "enrollment" is really about establishment of the "superuser"
authorization token in the AS. In kerberos terms, it's the Ticket Granting
Ticket.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 20:52:51 +0200

To re-use the Kerberos language, the client gets the TGT. The real-time
interaction I was talking about relates to the interaction between the
resource server and the authorization server.

Maybe the language in the use case document needs to be a bit more explicit.

Ludwig, could you please explain this offline requirement a bit more?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jul 2014 16:12:16 -0400

> resource server and the authorization server.

During enrollment, the Authorization Server gets a TGT on the *resource* server.
Given that, it can now issue new tickets to clients that come along that wish
to access the resource.  The client, during enrollment, asks the (possibly
federated list of) authorization servers for a resource ticket.
(This is why part of network join needs to be in scope for ACE)

All of the above has to occur online.

Once the client has the resource ticket, the resource server can validate it offline.

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 15 Jul 2014 07:47:46 +0200

>>Ludwig, could you please explain this offline requirement a bit more?

It means exactly the kind of offline validation that Michael described 
above.

1. You need some initial enrollment of AS <-> RS (that could be online 
or offline & manual such as by reading off some QR code with the RSs 
initial key material and feeding that to the AS).

2. Then you need some online authorization decision step between C and AS.

3. Then (possibly later) there is some interaction between C and RS, 
that could be offline. Here RS needs to be able to do offline validation 
of the authorization decision from step 2.

/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: Göran Selander <[email-masked]>
Date: Tue, 15 Jul 2014 07:25:44 +0000

Hannes,

I believe it is important that the solution allows an offline mode of
operation. Here are some other supporting use cases:

Although not listed in use case 1, the container monitoring use case, any
access requests to the goods at sea may need to work without connectivity
to an AS in the cloud. Containers may also be kept other areas e.g.
underground where cellular access is not available. One important point is
that even if connectivity to AS is technically possible at all times it
may not affordable for the particular business case.

We discussed previously one company considering designing physical access
control using an online system. There are another companies in the
physical access control business that profile themselves with offering
offline mode, for example Telcred. Their home page provides some more
details.

http://telcred.com/

One example of offline operations is for field technicians to physical
access radio base station sites:
If the base station is malfunctioning, there may be no cellular coverage
at the site, and the field technician need to access the site to repair
the base station (which then may become a catch 22).

There are also use cases where the AS functionality is hosted in a smart
phone or other end-user operated device (and the client is not in the same
device). In these cases we must also expect periods of time when the
device is not available or turned off.

In  draft-seitz-ace-problem-description section 4.5 we formulated the
offline requirement/assumption as:

     o RS may not be able to communicate with AS at the time of the
        request from C.

It would be interesting to know how people think about this (and other
statements in section 4).

Göran

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 15 Jul 2014 07:31:38 +0000

Snip
> (This is why part of network join needs to be in scope for ACE)

+1
This certainly has to considered to create a complete solution taking the whole lifecycle of the IoT device

regards
Sandeep

> From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Monday, July 14, 2014 10:12 PM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Ace] Offline operation of Resource Server
>
>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Likepeng <[email-masked]>
Date: Tue, 15 Jul 2014 08:25:52 +0000

Hi Ludwig,

> It means exactly the kind of offline validation that Michael described above.
> 
> 1. You need some initial enrollment of AS <-> RS (that could be online or offline
> & manual such as by reading off some QR code with the RSs initial key material
> and feeding that to the AS).
> 
> 3. Then (possibly later) there is some interaction between C and RS, that could
> be offline. Here RS needs to be able to do offline validation of the
> authorization decision from step 2.

This seems to be the normal flow.

If I check the draft section 4.3.4, in the normal flow, the RS also does not need to contact the AS for the online validation of the access token.
http://tools.ietf.org/html/draft-selander-core-access-control-02

Do you mean Client is also offline, and can't contact with AS?

In draft-seitz-ace-problem-description section 4.5, the offline requirement/assumption is:

     o RS may not be able to communicate with AS at the time of the request from C.
  
But I am not clear, only RS can’t communicate with AS, or both Client and RS can’t communicate with AS?

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
> 发送时间: 2014年7月15日 13:48
> 收件人: [email-masked]
> 主题: Re: [Ace] Offline operation of Resource Server
> 
> > Given that, it can now issue new tickets to clients that come along
> > that wish to access the resource.  The client, during enrollment, asks
> > the (possibly federated list of) authorization servers for a resource ticket.
> It means exactly the kind of offline validation that Michael described above.
> 
> 1. You need some initial enrollment of AS <-> RS (that could be online or offline
> & manual such as by reading off some QR code with the RSs initial key material
> and feeding that to the AS).
> 
> 3. Then (possibly later) there is some interaction between C and RS, that could
> be offline. Here RS needs to be able to do offline validation of the
> authorization decision from step 2.
> 
> 
> /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: Ludwig Seitz <[email-masked]>
Date: Tue, 15 Jul 2014 10:30:05 +0200

> Do you mean Client is also offline, and can't contact with AS?

I haven't really considered that, but it might be the case that in step 

-- 
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, 15 Jul 2014 10:35:38 +0200

Hi Michael,

to go back to the place where this discussion started in
http://www.ietf.org/mail-archive/web/ace/current/msg00703.html.

There, I said that I believe the use case document rules out an
EAP/AAA solution because of a requirement for not having a real-time
interaction between the resource server and the AS.

This is pretty much reflected in the list of questions I asked to the
group, namely:

"
Are there requirements/use cases that allow anything other than the
OAuth/Kerberos design pattern?
"

If you use Kerberos wrapped in EAP then of course you change the EAP/AAA
model.

In a nutshell, I agree that Kerberos can meet the requirements currently
outlined in the requirements document. Whether the EAP/AAA can as well
depends a bit on how to conclude our work with the use
cases/requirements document.

Ciao
Hannes

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 15 Jul 2014 14:57:53 +0200

Hi Ludwig:

> It means exactly the kind of offline validation that Michael described above.

[Rafa] I had the following in mind:

The RS is deployed under the domain of a "controller". To ensure the controller and the RS are authenticated are authorized they use EAP/AAA (so we avoid a rogue controller or a rogue RS). EAP peer is the RS, the EAP authenticator is the "controller" and EAP server is placed on the AS. We can also think (to simplify) that controller/AS is the same entity for now.

> 
> 1. You need some initial enrollment of AS <-> RS (that could be online or offline & manual such as by reading off some QR code with the RSs initial key material and feeding that to the AS).

Then, one option is to do online enrollment with EAP/AAA.  

> 2. Then you need some online authorization decision step between C and AS.

I also think we can use online authorization decision based on EAP/AAA.

> 
> 3. Then (possibly later) there is some interaction between C and RS, that could be offline. Here RS needs to be able to do offline validation of the authorization decision from step 2.

That is possible if during the EAP/AAA interactions there is a bootstrapping of some short term credential (e.g. Kerberos tickets). For example, if we talk in Kerberos terminology, the "controller" could be the KDC. Then C could obtain a TGT first and then a ST to access the RS. As long as the C has the ST, it can access the RS and the RS can do the validation offline.

So, in summary, there could be an online enrollment and online authorization decision based on EAP/AAA that allows to bootstrap "something" that enables RS and C to have an offline interaction during a period of time (e.g. ticket lifetime).

My 0.02 cents.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 15 Jul 2014 14:08:27 +0000

> So, in summary, there could be an online enrollment and online
> authorization decision based on EAP/AAA that allows to bootstrap
> "something" that enables RS and C to have an offline interaction during a
> period of time (e.g. ticket lifetime).

Just by way of example, another "something" that could be bootstrapped by EAP/AAA (as an alternative or complement to a Kerberos ticket) could be a certificate. There is also running code demonstrating this.

Josh.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jul 2014 11:27:14 -0400

Rafa Marin Lopez <[email-masked]> wrote:
    > That is possible if during the EAP/AAA interactions there is a
    > bootstrapping of some short term credential (e.g. Kerberos
    > tickets). For example, if we talk in Kerberos terminology, the

Please don't build in any assumption in your thinking that the resulting
ticket is short term.  Some may wish it; but for many applications we are
talking about tickets that either never expire, or have expirations times
decades in the future.

    > Just by way of example, another "something" that could be bootstrapped
    > by EAP/AAA (as an alternative or complement to a Kerberos ticket) could
    > be a certificate. There is also running code demonstrating this.

Yes; exactly.  The certificate could contain Authorization Attributes rather
than identities.  Anyone who hasn't read rfc2692 and rfc2693 lately, should
do so.

Just think of the kerberos-like symmetric key token as being a certificate
that can only be validated by the originator.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jul 2014 11:29:56 -0400

> OAuth/Kerberos design pattern?

I wasn't arguing with you, but with others, I guess. Sorry.
I think that your question is not well stated.

"allow anything other" -- has a bunch of implicit negations, I'm not actually
sure how many, to be honest.

There are use cases that can only be satisified by the OAuth/Kerberos design
pattern.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 15 Jul 2014 17:36:22 +0200

Hi Michael:

> talking about tickets that either never expire, or have expirations times

I agree. I was talking about a typical case in Kerberos. But I do not have problem with having long-term credentials bootstrapped. That should be feasible. Nevertheless, please take into account that the bootstrapping phase might be used only once for decades (so the source code developed for it). 

> that can only be validated by the originator.

In fact, we have also considered the case of bootstrapping a certificate after an EAP/AAA authentication. So I have no problem at all with that. So +1 to that.

Best Regards.

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 18 Jul 2014 09:54:55 +0200

> operation. Here are some other supporting use cases:
[...]
> offline mode, for example Telcred. Their home page provides some more

I have a statement from Telcred here that might be of interest:

On 07/16/2014 12:12 PM, Carlo Pompili wrote:
> Dear Göran, Ludwig,
>
> Thanks for opportunity to comment on the need for offline access control / locks from our perspective.
>
> As you know, Telcred is a spinoff-company from SICS developing a solution for physical access control
> with support for offline operation, and we do indeed see a large market for offline access control
 > for the foreseeable future.
> In the short to medium term we believe that many infrastructure companies need this type of solution.
 > Examples include companies and organizations responsible for power 
generation and distribution, telecom,
 > water, sewage, road and rail infrastructure, etc. These companies 
have many remote sites which need to
 > be visited from time to time by e.g. service technicians. Although in 
many cases it would be feasible
 > to install an online solution, we know from our discussions with them 
that the cost is perceived as
 > prohibitive. An offline solution is also perceived as more robust. A 
common reason for sending a
 > technician to a site is that there is some problem which need to be 
fixed, and in this situation one
 > cannot assume that communications to the site will be available.
>
> Longer term we also believe that there is a great market for offline access control in transportation,
 > including both commercial and private vehicles, as well as many types 
of load carriers
 > (e.g. shipping containers). Undoubtedly, most cars and trucks will 
have an online connection, but it
 > cannot be guaranteed to always be available - consider for example 
parking garages.
>
> As should be clear from the above, we believe that offline is mainly relevant for access control in
 > an enterprise setting. Private homes interested in electronic access 
control can also be expected to
 > have a good broadband connection, WiFi etc.
>
> As you know, Telcred has developed a model for offline access control based on cryptographically signed
 > "tickets" and a compact way of expressing and verifying access 
rights, which can scale to a very large
 > number of locks while keeping the size of the tickets down.
>
> If you think we can contribute further to your work in this area we are happy to do so.
>
> Best regards,
>
> Carl Pompili
>
>

/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