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

[Robert Cragie <[e-mail]>]

Hi Hannes,

My view on your questions.

Robert

On 09/07/2014 8:58 AM, Hannes Tschofenig wrote:
> 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.
<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>

>
> 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.
<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>
>
> 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
<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>
>
> 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.
<RCC>I think it needs to be considered from the get-go but the solution 
should scalable to accommodate cross-domain support</RCC>
>
> 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.
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace