Subject: [Ace] Questions for the IETF#90 Meeting

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 09 Jul 2014 09:58:00 +0200

To me there appear to be four questions for the group:

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

Partially the answer should come from the use case document.

2) Should the design re-use existing work or should the design start
from scratch?

This is more a question of taste / preference but will obviously have a
huge impact on the subsequent work in the group.

3) Should the design be based on symmetric or asymmetric crypto?
  (or both?)

We have various documents that talk about this issue, for example
draft-seitz-ace-design-considerations-00 and
draft-seitz-ace-problem-description-01

4) How to address cross-domain support in the initial protocol design?
Is it a feature that can be added later easily?

draft-gerdes-ace-actors-01 talks about this aspect.

If we could get an answer to these questions during the meeting that
would be good step forward.

Ciao
Hannes

PS: One question that has been answered by all document in the same way
at the moment is about the use of DTLS. Currently, everyone seems to be
focused on using DTLS everywhere. There would be alternative approaches
as well.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Jul 2014 01:29:09 -0700

> OAuth/Kerberos design pattern?
Allow?  Any square peg (Kerberos) could be allowed to fill a round hole
with a large enough hammer.

I have requirements for P2P consumer connections that will not
initially have any Internet connectivity.  Direct enrollment and
management of headless consumer devices is important
and especially during bootstrapping from out-of-box does not
fit well into OAuth/Kerberos

> 2) Should the design re-use existing work or should the design start
Scratch.

> 3) Should the design be based on symmetric or asymmetric crypto?
Both of course, and hash algorithms.  
Asymmetric crypto should be used for key establishment and identity.
Algorithms should be lumped together as a Cipher Suite that defines
a set of algorithms for key established/authentication, encryption, hashing, etc.

> draft-gerdes-ace-actors-01 talks about this aspect.
from this ...
"   According to the Internet Security Glossary [RFC4949], authentication
   is "the process of verifying a claim that a system entity or system
   resource has a certain attribute value."  Examples for attribute
   values are the ID of a device, the type of the device or the name of
   its owner.  Authentication attributes might be (but not necessarily
   are) suitable to uniquely identify an individual entity.”

The hash of the public key is a attribute that can be directly
authenticated by the key holder and is unique. The hash
process should include the encoding of the Cipher Suite
values to bind the algorithms to the instance of a key.
Other attribute bindings can be built on these unique ‘ids'

Paul

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 09 Jul 2014 11:02:16 +0200

Hi Paul,

thanks for responding to so quickly.

One remark regarding the first question:

> fit well into OAuth/Kerberos

The reason why I have listed the question here is because the
requirements document currently rules out a certain class of solutions
that require communication between the resource server and the
authorization server in real-time.

Regarding the terminology (resource server, client, authorization
server) please take a look at Section 2 of
http://tools.ietf.org/html/draft-seitz-ace-problem-description-01

Regarding your use case: Could you say a few words about what the
participating entities are and how the interact with each other?

I am not sure what you mean by "P2P consumer connections".

Ciao
Hannes

---

From: Ralph Droms <[email-masked]>
Date: Wed, 9 Jul 2014 07:22:22 -0400

> On Jul 9, 2014, at 4:29 AM, Paul Lambert <[email-masked]> wrote:
> 
> 

I disagree with the characterization as "taste/preference".  In my opinion, there needs to be strong evidence for the need for a design from scratch and an implicit bias toward reusing existing technologies.

Use cases like the one outlined above should be reviewed to see if they constitute evidence in support of a design from scratch.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Jul 2014 10:09:13 -0400

> OAuth/Kerberos design pattern?

I think that there are two questions here:
  1) is the OAuth/Kerberos design pattern sufficient? (does it do everything)
  2) is the OAUTH/Kerberos design pattern necessary?  (can we throw something away?)

My instinct is that it handles all of the operational parts, but it does not
handle any of the enrollment parts, particularly for the case where the
parties are offline.   You will recall that you felt at the BOF that the
enrollment case was out of scope.

    > huge impact on the subsequent work in the group.

I think that it worth spending some time to think about a CBOR encoding of
OAuth2, which I think makes use of JSON.  I don't think we have any mapping
of Kerberos into JSON, but I could be wrong.  The idea is to start with a
baseline situation and then decided if we should innovate.

    > draft-seitz-ace-problem-description-01

After enrollment, symmetric crypto is sufficient.

    > draft-gerdes-ace-actors-01 talks about this aspect.

It must be present from day one.  That is one thing which dis-recommends a
pure Kerberos pattern, or at least observes Kerberos to include all the pkinit and 
cross-realm stuff from the beginning.  My limited experience with kerberos is
that there must be significant operational hurdles to doing cross-realm
things, or it would occur far more often.

    > focused on using DTLS everywhere. There would be alternative approaches

I don't prefer to have any alternative approaches be considered. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Jul 2014 14:52:03 -0700

> http://tools.ietf.org/html/draft-seitz-ace-problem-description-01

Ok, my mistake with understanding your question about “allow”.
I agree that C and RS should not be required to contact the AS
for a policy decision.

> I am not sure what you mean by "P2P consumer connections”.

Wireless (e.g. Wi-Fi ) based direct connections from one device to another.
 - between two smart phones
 - smart phone to headless device (e.g. hot water heater)
Typically no Internet connection guaranteed to be available.

The interesting part is the “enrollment” which appears to be
out-of-scope for this group.  The initial ‘pairing’ is effectively
the AS function being introduced to a C or RS and providing
initial configuration of policy (aka authorization information)

Paul

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Jul 2014 14:59:04 -0700

> I disagree with the characterization as "taste/preference".  In my opinion, there needs to be strong evidence for the need for a design from scratch and an implicit bias toward reusing existing tec…

Interesting that there is a perception that new work is harder.  At some point we overload our existing protocols too far and they become cumbersome (e.g. X.509)  Other industries innovate now faster than the IETF.   We have much more rapid changes in PHY and MAC communications.   If other groups were so biased we’d all still be using RS-232

> Use cases like the one outlined above should be reviewed to see if they constitute evidence in support of a design from scratch.

Or … be open to compare proposals rather than assuming DTLS, OAuth or Kerberos are the ultimate solutions.

Paul

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jul 2014 01:52:47 +0200

On 09 Jul 2014, at 23:59, Paul Lambert <[email-masked]> wrote:

> Interesting that there is a perception that new work is harder.

In the late 1990s, I sat through a couple of years of developing the SIP protocol, from the protocol that was “almost compatible with HTTP, just a little different because it was about phone calls” to the protocol that was considerably damaged by people inappropriately applying their HTTP intuitions to a completely different protocol that was just using the same names for different things.

We mentioned this in section 2.6 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, but this specific fallacy of “building on existing protocols” probably deserves a more complete treatment.

Grüße, Carsten

PS.: http://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 09:44:24 +0200

Hi Paul,

> Typically no Internet connection guaranteed to be available.

As currently described in the use cases an initial interaction between
the client and the authorization server would be needed to get the
protocol interaction working. If there is only connectivity from the
client to the resource server and nothing else then this is currently
not covered by the use cases.

> initial configuration of policy (aka authorization information)

The interaction between the client and the AS is within the scope. We
didn't call this enrollment though.

---

From: Göran Selander <[email-masked]>
Date: Thu, 10 Jul 2014 18:22:21 +0000

Hi Hannes

On 09/07/14 09:58, "Hannes Tschofenig" <[email-masked]> wrote:

>focused on using DTLS everywhere.

In don¹t understand this statement. Section 3.3 and the requirement in
section 4.8 of draft-seitz-ace-problem-description-01 is explicitly
considering alternative communication security paradigms. Section 4.2 of
the same draft mentionS issues with DTLS. What is the meaning of "everyone
seems to be
focused on using DTLS everywhere²?

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 20:26:50 +0200

Hi Göran

thanks for pointing this out.

When writing the email I was thinking about the solution documents I had
gone through. In those solutions I saw the focus on DTLS, which sort of
makes sense.

Ciao
Hannes

---

From: Paul Lambert <[email-masked]>
Date: Thu, 10 Jul 2014 12:04:52 -0700

Carsten,

> We mentioned this in section 2.6 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, but this specific fallacy of “building on existing protocols” probably deserves a more complete tr…

Thanks for your support on this topic.  Technical proposals should be considered based on their merit and not solely on reuse of existing RFCs.  In the IETF, we need to more conciously examine what has been done well and where improvements are possible.  

Paul

---

From: Paul Lambert <[email-masked]>
Date: Thu, 10 Jul 2014 15:56:45 -0700

Hannes,

> protocol interaction working.
Thank you for the clarification … that makes sense now rereading.

I do have fundamental problems with the overall server centric 
framework, for example:

"    U4.3.  Devices can access resources on other devices only if a
      rule exists in the authorization server (default deny)."
and
"U4.5.  Devices may cache authorization rules locally.”

I do  not see why a server is required.  The authorization/policy information
required to make the decision might better be modeled as as
a functional element in the RS.  The authorization information
should be available locally to the RS, but could reach out to
one or more servers in some implementions ions.

> If there is only connectivity from the

If the RS is a Kerberos like system that uses symmetric key enrollment 
you get one particular world view and set of capabilities.

If the RS is not a symmetric key server, but a policy ‘authority’ (PA) that can sign
authorization statements, you get a different set of potential topologies
and capabilities.

This set of specifications quickly to a ‘third party’ server,
and eliminates more dynamic and distributed models. These tend
to drive the solution space to a factory pre configuration of
devices with credentials of a RS.

Having the ‘authority’ in my mobile device is my preferred use
case.  Design overview:
 - mobile device has loaded a “configuration” app
   Configuration Apps use common setup and authorization
   protocols
 - multiple devices from multiple vendors (supporting
   this provisioning technology) can be managed by the app
 - No factory provisioned are required
   Devices come from multiple vendors that may not agree
   on a single server or authorization authority
   Devices may include factory installed information signed
   by their facities
 - Every device conforming to this methodolgy is authenticated
   peer-to-peer using self generated public keys
 - ‘dumb’ headless devices have a long term static public key 
   bound to label information to support secure initial pairing
 - headless devices after initial pairing generate a new long
   term key for authentication to other devices
 - out-of-box, devices (C or RS in ACE model) must be
   paired/setup by an Authority (in this example the mobile
   device with pairing application)
  - setup of a new device establishes the RA (as opposed
    to RS) as the identity with authority to set policies
    in the enrollee (C/RS).  
  - Access control is an Attribute based model where
    attributes may be associated to a key.
   Attributes of a key include it’s ‘id’ (hash of
   key, cipher suite id, type), and arbitrary tag/value
    pairs.
   - Typical assigned tags might include be ‘group’
     (e.g.   group: foo)
   - Configuration of end device (RS/C) by RA will
     set local policy consisting of Attribute based
     rules for actions (e.g. ACL of ids, group or other)
  - RA can configure other devices (usually a smart
    phone) to have some or all of the authority for
    a name space.  This allows delegation and
    support of multiple RAs
  - Reset of headless devices consists of deleting
    current public/private key pair.  Simple reset
    is button on device.  Secure reset is by 
    authorized RA
  - RA only needs to configure pair-wise to each
    device once when using simple group
    attribute policies.  Group membership
    is indicated from device-to-device 
    without central server.  Group membership
    is a tag/value assignment from RA to
    C/RS signed by RA.  
   - where central monitoring/loggin required, 
     authorization decision could be based on
    implementation of policy function as proxy to server
  - public key replacement, backup, RA cloning is
    handled by signed delegation of RA key to
    another key to become RA

Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Jul 2014 11:30:16 +0200

Hi Michael,

thanks for the feedback.

One minor remark on the Kerberos cross-realm authentication.

My understanding of the challenge with deployments (from discussions
with the Kerberos folks) is that there have to be business reasons for
deploying cross-realm authentication. These business reasons are not
always there and they require a considerable amount of effort since
business agreements (including legal aspects) do not necessarily scale
in the same way as technology could do.

This is also a painful lesson the original OpenID guys learned (which is
why it is dead now). They approached the problem of federations in a
technical way and failed to understand that federations are 95%
business/legal constructs and only 5% technology.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Jul 2014 11:34:07 +0200

Hi Paul,

I believe our misunderstanding is based on the difference between roles
and physical boxes. The authorization server is a role and it can of
course be dumped into any physical box. As you explain below, it can be
combined with the client into a smart phone.

At least that's my reading of the current requirements.

Now, when you consider smart phones as clients then many of the
challenges disappear since smart phones are pretty sophisticated devices
and there is no need to optimize the last hack out of them.

In fact, this is something I noted when I wrote the OAuth IoT document
(which I recently submitted to the group). If you have a smart phone
than most of the ACE challenges disappear.

This might be something to double-check as we go through the use cases.

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Jul 2014 11:42:17 +0200

> one or more servers in some implementions ions.

Citing from draft-seitz-ace-problem-description-01:

    Finally we also assume that in a significant number of cases, the
    server and/or the client are too constrained to handle the
    authorization policies and related configuration on their own.  Many
    authorization solutions involve a centralized, trusted third party,
    supporting the client and/or resource server.  A trusted third party
    provides a more scalable way to centrally manage authorization
    policies, in order to ensure consistent authorization decisions.  The
    physical separation of policy decision and policy enforcement is an
    established principle in policy based management, e.g. [RFC2748].

To be a bit more specific:

* In many cases evaluating authorization policies (not simple ACLs) will 
require network lookups (e.g. checking client attributes in an identity 
provider database). This kind of processing is too expensive for 
constrained devices in terms of delay time and, for battery powered 
devices, energy consumption.

* You typically want to manage authorization policies centrally in order 
to keep a consistent picture of their current state.

* You also typically want to centralize authorization decisions in order 
to generate complete audit logs.

* If authorization policies change frequently you want to avoid having 
to provision each of these updates to all the affected resource servers.

Note the separation of policy decisions and policy enforcement here. The 
Authorization Server is expected to do decisions, while the RS does 
enforcement.

I hope that clarifies things a bit.

/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: Robert Cragie <[email-masked]>
Date: Mon, 14 Jul 2014 13:36:42 +0100

Hi Hannes,

My view on your questions.

Robert

> Partially the answer should come from the use case document.
<RCC>
I think one of the issues which seems to be evident from the responses 
already is that, like all good engineers, we are coming up with 
solutions before we have fully analyzed the problem. The starting point 
is "some entity wants to access information on another entity, which 
will be allowed or denied". We agreed on using the client/server model 
and basing it on a RESTful architecture, even going as far as specifying 
the transfer protocols (HTTP or CoAP). We also say the the client and/or 
the server may be constrained. But beyond that, especially with regard 
to the basis access is allowed or denied, I think no further solutions 
should be assumed or implied as developing solutions is the project work.

The charter talks about CoAP using DTLS and mediatiion of an 
authorization server so already that is nodding towards solutions and 
this similar nodding is evident in the problem statement as early on in 
section 2 of the problem statement when it says "Many authorization 
solutions..."

It is reasonable to use both a top-down and bottom-up approach but to be 
effective the bottom up approach must always be cognizant of the 
requirements coming down from the top; the "peg" and the "hole" to use 
the typical analogy.

The thing is, as far as I can tell, neither OAuth or Kerberos is a 
design pattern in itself so can we relate either or both to some 
definitive design pattern? If we can, my guess is that that pattern will 
be sufficient.
</RCC>

> huge impact on the subsequent work in the group.
<RCC>The first rule of engineering is not to reinvent the wheel. It 
depends how existing work is reused. If it the basis (i.e. the bottom of 
a bottom-up, top down approach) then I think that is the right approach. 
Using verbatim may not be appropriate, especially in constrained 
environments. However, based on experience, it is easy to be pessimistic 
about the suitability of existing protocols verbatim. As usual, there is 
a tradeoff; the most efficient protocol in a particular scenario is 
unlikely to be an existing one but conversely it is likely existing 
protocols would be suitable, if not the most efficient</RCC>
> draft-seitz-ace-problem-description-01
<RCC>I think it has to be both. There is a place for both. Security 
policy and deployment scenarios will often dictate what is most 
appropriate</RCC>
> draft-gerdes-ace-actors-01 talks about this aspect.
<RCC>I think it needs to be considered from the get-go but the solution 
should scalable to accommodate cross-domain support</RCC>

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Jul 2014 14:51:36 +0200

On 07/14/2014 02:36 PM, Robert Cragie wrote:
> will be allowed or denied".

Sorry for nit-picking, but since we are engineers lets be precise:

"some entity wants to access a resource on another entity"

This could be information, but it could also be the setting some 
actuator. My point being: We don't only talk about read access.

> We agreed on using the client/server model

I don't know if this qualifies as a design pattern, but I had RFC2904 in
mind when writing the problem statement.

Most of us agree that we need third party mediation for authorization, 
feel free to argue the contrary, I'm all ears.

/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: Robert Cragie <[email-masked]>
Date: Mon, 14 Jul 2014 15:09:30 +0100

> actuator. My point being: We don't only talk about read access.
<RCC2>I was being deliberately general, which is why I didn't use the 
'read' or 'data' words. Accessing a resource could involve data flow in 
both directions, i.e. writing data as well.</RCC2>
> feel free to argue the contrary, I'm all ears.
<RCC2>RFC 2904 describes itself as a framework; I am not sure if people 
view a framework as the same as a design pattern. In my view, a pattern 
is a more general concept but YMMV. Re. third party mediation. I am not 
arguing the contrary, it is at what point that mediation comes into 
play. At the moment there seems to be an assumption authorization will 
be grant-based but online is possible. Perhaps it may be more 
appropriate to develop these initially as paradigms then refine into 
design patterns, then frameworks then protocols.</RCC2>

---

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

> in the same way as technology could do.

This is a fair statement;  but I think that there are sufficient
technological hurdles that only enterprises with legal departments even
consider it :-)

    > business/legal constructs and only 5% technology.

If possible, it might be good to understand if the technology was simply
appeared too powerful (i.e. too dangerous), and if there is something we can
do.  Is there a grey beard from the original OpenID space that might be able
to explain more?

I think that it is reasonable for my neighbour to want to give me permission
to turn *some* things on/off at their house when they are away.
I can construct industrial scenarios easily, and it seems that the container
situation is an ideal use case to consider.

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