[Secauth] Revised version of requirements and use cases (version 2)

[Hosnieh Rafiee <[e-mail]>]

Thanks Hannes, Joel and Will for your comments. 


@Folks,

I revised the requirement and use case drafts to cover the same scope as does the current proposed secauth charter. 

< https://tools.ietf.org/html/draft-rafiee-secauth-usecase >

There are a lot of people in this group however there are a few active people. Therefore, I think there should be some motivation to have more active members.  To understand weak points and having more contributions I appreciate your clear answers to the following questions:

- Do you support to continue this work?
If No: what is missing? Do you see any possibility to improve it? 

If Yes: Is there anything that we can improve or we forget to address?

- What do you think about the scope? 


What is your opinion about the proposed charter (following)?


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, reliable communication in first point of contact 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. Providing reliability during the first point of contact (decrease the security gap) and automating the establishment of this communication as much as possible and providing device authentication and authorization in virtual environment where NFV and SDN based techniques are in use 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. (provide security for DNS servers)
- 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 reliable communication in first point of contact 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


Thanks,
Best,
Hosnieh







P.S Please note that secauth is not yet a WG. The charter needs to be approved by ADs.