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

[Paul Lambert <[e-mail]>]

On Jul 9, 2014, at 4:22 AM, Ralph Droms <[e-mail]> wrote:

> 
> 
>> On Jul 9, 2014, at 4:29 AM, Paul Lambert <[e-mail]> wrote:
>> 
>> 
>>> 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.
> 
> 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.

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

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