Subject: [Secauth] revised version of secauth charter - Please review

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 1 Oct 2014 15:40:31 +0000

Folks,

After offlist discussion with Joel. He had a lot of helpful suggestions to improve the scope of this charter.

Please take your time and have a look on the proposed charter.

Tell me what you think and how better to go further.

I appreciate any inputs to the list either editorial, technical or questions.

Thanks,
Best,
Hosnieh

----------------------------------------------------------------------

Proposed charter and the working items of secauth
------------------------------------------------------------------------
There are various authentication and authorization mechanisms in use today. Some supports only particular devices, for instance, only available for constrained devices. Some others support the nodes with rich resources (CPU, memory, etc.). However, providing trust during the establishment of the communication is usually out of the scope of the existing security protocols. 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 as much as possible, providing user/device authentication and authorization, minimizing the need of human interaction and be able to assist other protocols to decrease the security gap in first point of trust is what secauth aim to address.  

Furthermore, secauth aims to remove the need of CAs and/or installation/configuration of any TA infrastructure for authentication and authorization. Although, if only domain names are in use, secauth need to use a DNS server to translate these names to their IP addresses. There are two scenarios here:

[1] a node can trust the network where it is connected in order to receive the IP address of a DNS server. This scenario is only when a node can receive the IP address of a resolver from secure Router Advertisement (RA) or there is any switch-based security available.
The scope of secauth here is to securely authenticate the DNS resolver and to securely authenticate an application or a device.

[2] a node cannot trust the network. The finger print of a DNS server needs to be set in the node manually as explained in http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig . This manual step is out of scope of secauth. After this step, like what explained in last scenario, secauth can verify the DNS resolver and securely authenticate an application or a device. 

If the communication is only IP based and a node uses a valid IP address. 

- In IPv6, dissimilar to [1] and [2], secauth can automate the whole process without any configuration. 
- In IPv4, this is similar to [1] and [2].
  
Secauth is not dependent to any IP based solution. However, when a node supports a valid global IP address, secauth does not need to receive any information from DNS. 

Summary of the scope of secauth
------------------------------------
- It is not dependent to an IP based solution.
- It depends on a secure solution on a switch or a secure RA for full automation as explained in [1]. Unless, it depends on a manual configuration [2].
- It removes the requirement for the use of a CA
- It depends on a DNS server to translate names to IP addresses but it can securely handle this process.
- The configuration of DNS server is out of scope of secauth. 
- The configuration of switches or providing secure RA is out of scope of secauth

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