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

[Paul Lambert <[e-mail]>]

On Jul 9, 2014, at 12:58 AM, Hannes Tschofenig <[e-mail]> 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?
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

> 
> 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?
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?)
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.


> 
> 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.
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

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