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

> On Jul 9, 2014, at 4:29 AM, Paul Lambert <paul@nymbus.net> wrote:
> 
> 
>> On Jul 9, 2014, at 12:58 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> 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.

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

>> 
>> 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
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace