Subject: Re: [Secauth] Any opinion on charter?

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Oct 2014 16:39:32 +0200

Hi Hosnieh,

a few remarks inline.

On 09/29/2014 01:54 PM, Hosnieh Rafiee wrote:
> Folks,
> 
> I asked ADs for a side meeting (room request) in upcoming IETF. I still do not know the time but as soon as I know this, I will let you know. 
> 
> I still did not received any opinion on the charter. I welcome your inputs so that it can be as clear as possible.
> 
> Thanks,
> Best,
> Hosnieh
>>
>> Proposed charter and the working items of secauth
>> -----------------------------------------------------------------------
>> -
>> There are various authentication and authorization mechanisms in use
>> today.
>> These mechanisms might only support particular devices, for instance,
>> only available for constrained devices or it might only focuses on
>> nodes with rich resources (CPU, memory, etc.) without the possibility
>> for them to be used for constrained devices. Therefore, there are
>> different types of heterogeneous protocols available and use over the
>> internet that cannot authenticate or work together. This is why, there
>> is usually a need that both devices support the same mechanism. Thereby,
>> Having a mechanism to interoperate between all available mechanisms and
>> enable different mechanisms to work together for a robust
>> authentication and authorization, without the need for the nodes to
>> support individual protocols is demanding.

You will always need to have some commonly agreed mechanism in order for
devices from different vendors to talk to each other. There is no way
around that.

>> In other word, using a simple, light approach (like a language) that
>> can be supported by all current devices so that it provides the
>> possibility for two devices that uses two different authentication and
>> authorization protocols to exchange their secure parameters in a secure
>> manner.

I am trying to understand where you are getting with this. It almost
seems that you are suggesting to use a language (like JavaScript with
the Crypto API) to then accomplish interoperability between devices.

Do I understand the idea correctly?

 Therefore, one of the purpose of secauth is to eliminate
>> security gaps during authentication and authorization and provide a
>> simple solution that can be supported by different nodes with different
>> resources and play a role of interoperate protocol.

This paragraph sounds more like you would like to standardize another
authentication protocol that can then be supported everywhere.
Of course, adding another authentication protocol to the already
existing toolbox does not make it the only one and the deployment does
not happen by magic either.

>>
>> In addition, providing trust during the establishment of the
>> communication is usually out of the scope of the existing security
>> protocols.

I personally try to avoid the term "trust" since it is so fuzzy. If you
use it then you need to say "who trust whom to do what".

 This is why there is usually a big gap that demands some to
>> many manual configurations to provide a node with a secure
>> authentication/authorization. Automating the establishment of this
>> communication, providing user/device authentication and authorization,
>> minimizing the need of human interaction and interoperate between other
>> protocols to provide a robust secure authentication and authorization
>> between two heterogeneous protocols is what this group aim to address.
>>
>> Furthermore, secauth aims to remove the need of CAs or
>> installation/configuration of any infrastructure for the purpose of
>> authentication and authorization. This allows the wide use of this
>> protocol over the networks.

In a protocol that offers authentication and authorization you need to
provision some information. Of course, nobody likes provisioning but if
you don't do that then you get something like opportunistic security,
which of course does not cover many scenarios either. There is just no
free lunch.

I fear that you will need a few examples of technologies you want to
standardize to give folks an idea about the direction you are heading.
The current charter text is very generic. In the discussion about
scenarios you had raised a couple of different directions and it might
be good to focus on something small at the beginning; something very
specific to get folks interested.

>>
>>
>> The tasks of this group includes:
>> ------------------------------------
>> 1) Produce problem statement, requirements and use cases
>> 2) Identify the design and architecture for providing first point of
>> trust and reduce the security gap as much as possible and consider
>> confidentiality for this solution
>> 3) Identify the existing protocols that needs this interoperation
>> 4) Identify the light cryptographic approaches that can be used for
>> authentication and authorization purposes
>>

Ciao
Hannes

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