Subject: [saag] Review request- secauth - authentication and authorization - first draft

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 1 Sep 2014 09:26:55 +0000

Folks,

I have received a few comments offlist. I would welcome more comments if any. Please consider reviewing it and share your ideas to know whether or not we considered all your thoughts or we need to work more.

I would prefer to receive comments on the mailinglist rather than offlist. Because other folks might also include something to your comments or there might be supporters or non-supporters of certain idea.

Thanks,
Best,
Hosnieh
http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 1 Sep 2014 23:17:29 +0000

On Mon, Sep 01, 2014 at 09:26:55AM +0000, Hosnieh Rafiee wrote:

> I have received a few comments offlist. I would welcome more
> comments if any. Please consider reviewing it and share your ideas
> to know whether or not we considered all your thoughts or we need
> to work more.

The draft seems to have much text in 3.1 on various flavours of
authentication mechanisms at the application layer.  It is not
clear why these are there, if the goal is primarily to explore the
requirements for an API that exposes network-layer security to the
application layer.

It is not clear what the purpose of section 3.2 is.

Section 3.3 seems to talk about virtual network infrastructure.
Is this API between the application layer and local network-layer
security such as IPSEC, ... Or is it an interface to talk to
network infrastructure?  (Switches, Proxies, ...)

The remaining sections seem too sketchy.

Critically, the last paragraph of the introduction:

       Therefore, The purpose of this document is to reduce the
       security gap between end users and devices or devices to
       end devices during authentication and authorization where
       other authentication or authorization approaches are unable
       to address this problem easily without many pre-configurations.
       In other words, this API aims to assist a secure authentication
       and authorization for the last mile of the Internet. This
       document defines the problem statement and identifies the
       requirements for a robust easy secure authentication and
       authorization of nodes using a combination of network layer
       and application layer security approaches.

seems rather unclear.  Is securing the last mile an API problem?

As yet, there does not seem to be very much text actually addressing
the API requirements.

One example requirement is to expose a channel-binding between the
network layer encrypted channel, and the application data stream,
which can be used in combination with higher-layer mechanisms to
create an authenticated application-layer message stream out of
from a network layer that provides unauthenticated encryption
with integrity protection.

Other requirements might include functionality to query the
security state of the network layer, or control it.

If I am not misreading the intended scope of the draft, it seems
too early to review it, because so little is there...

-- 
	Viktor.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 2 Sep 2014 11:11:22 +0000

Viktor,

Again thanks a lot for your comments which I really appreciated it. 
> authentication mechanisms at the application layer.  It is not clear
> why these are there, if the goal is primarily to explore the

Yes, as the title of this draft also shows, the purpose is only requirements and use cases and still I don't plan to go through the solution space. However, I have some ideas but I guess it makes sense to go through it after we have an acceptable version of the requirement document.

> security such as IPSEC, ... Or is it an interface to talk to network
> infrastructure?  (Switches, Proxies, ...)

No, this API is inside each node and handles the secure authentication between two devices that there can be user behind one of these device or there can be also another device. 
And the infrastructure can be switches, proxy servers, etc.

Please consider the following cases
Authentication /authorization (for short: Auth2) of a user to a device (this is of course not possible without an application. So to summarize it, it is Auth2 of the application1 to application2 where application 2 is on another node located on different network or the same network)
So for this use case scenario, 

Virtualization falls into the category of Auth2 of device to device. This is , of course, via some applications but the differences is that there is no human or user in between and all the things are done automatically between two devices that can be on a same network or on different networks. 
This is like a policy enforcer protocol wants to setup authentication and authorization

Now about this Auth2 in detail for second scenario that is virtualization (I guess this was the confusing part. right?)

Virtual device (VD) x wants to add a new rule in virtual device y. VD x needs to authenticate VD y and then authorize it before it allows it to add or modify any resources on VD y. VD x uses secauth api and sends authentication request to VD y, based on secauth configuration, it first uses a network layer authentication to create the first level of trust. After VD y uses secauth and authenticates VD x, it authorizes VD x to use some resources or modify a resources on VD y. This step can be handled by other mechanisms (like Oauth) or still can be handled by secauth because the first point of trust was the main purpose of secauth and the other parts can be handled by other protocols or secauth as well. Such as starting a secure channel to encrypt all data, etc.  

Do you think my example is clear? 
Secauth might also use other mechanisms to create this first trust efficiently. 

This is what I tried to explain or expand the virtualization section. 

> seems rather unclear.  Is securing the last mile an API problem?

Not an API problem, but the current problems with current protocols and the purpose is to eliminate this problem or eliminate the gap in first point of trust.

> network layer encrypted channel, and the application data stream, which
> can be used in combination with higher-layer mechanisms to create an
> authenticated application-layer message stream out of from a network
> layer that provides unauthenticated encryption with integrity
> protection.

Do you mean I need to go to more detail about requirements? Isn't it considered as a use case scenario that how the things need to work? I mean shall I expand the use case section or requirement section?

> Other requirements might include functionality to query the security
> state of the network layer, or control it.
> 
> If I am not misreading the intended scope of the draft, it seems too
> early to review it, because so little is there...

Thanks again,
Best,
Hosnieh

---

From: Paul Lambert <[email-masked]>
Date: Tue, 2 Sep 2014 21:02:55 -0700

]-----Original Message-----
]From: saag [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
]Sent: Monday, September 01, 2014 2:27 AM
]To: [email-masked]
]Cc: [email-masked]
]Subject: [saag] Review request- secauth - authentication and
]authorization - first draft
]
]Folks,
]
]I have received a few comments offlist. I would welcome more comments if
]any. Please consider reviewing it and share your ideas to know whether
]or not we considered all your thoughts or we need to work more.

I find the abstract and purpose of the document confusing.
It's hard to tell purpose of the requirements.

"... use cases and requirements for secure
   authentication in other layers above the network layer ..."
Not sure why layers matter in the abstract for AuthN/AuthZ
services.

"... and the use of network layer security approaches
   for this purpose. ..."

The first part excludes network layer and 
now you include network layer.

" 3.1. Authentication/Authorization of a User to a Device"
Not sure why this would be in scope since the user
is not an 'application'. 
This is also not a well formed use case
(e.g. a banking application that needed
to validate that a user had direct control over a application
might be a viable use case)

" 3.1.1.  Biometric Authentication"
This is not a use case, it's a mechanism.

" 3.1.5. NAT Scenario"
Useful use case for network layer ...
Not clearly articulated why it's interesting.
Not so important above layer three.
Not clear about scope of this document.

" 3.1.6. Valid IP address"
Does not make sense in section 3.1
Not really the right term for the scenario.
Not really a use case, but one possible addressing
Situation.

Use cases might beter include users:
 - home user behind firewall
 - home gateway with static IP address (valid)
 - home IoT widget with IPv6 based on device MAC address (privacy issues)
 - home IoT widget with IPv6 based on Ephemeral MAC address
 - etc

" 3.3. Authentication and Authorization of Virtual Devices"
Not clear if this is in scope for IETF work. Internal security of
Virtualized services is not apparent over-the-wire. A virtual server
is typically indistinguishable from a non-virtual server.

]
]I would prefer to receive comments on the mailinglist rather than
]offlist. Because other folks might also include something to your
]comments or there might be supporters or non-supporters of certain idea.

Draft is a bit rough at the moment.  Clarity in abstract and purpose 
would be a good starting point.

Paul

]
]Thanks,
]Best,
]Hosnieh
]http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 3 Sep 2014 13:17:48 +0200

Hi Paul,

Thanks a lot for your comments and suggestions. I will consider them all in
next version. Please see my responses inline...

> It's hard to tell purpose of the requirements.

I kept the abstract so short. But if it is needed I would expand it.

> Not sure why layers matter in the abstract for AuthN/AuthZ services.
> 
> The first part excludes network layer and now you include network layer.

You are right. I guess it is wording problem. The purpose is to use Network
layer approaches as means of authentication in other layers. This network
layer approaches also can combine with other available approaches. For
instance for the start, the authentication is network layer and after the
establishment of this trust, it  can be application layer or user based
password authentication or token based to authorize this user to access to
certain resources. Like two level authentication and authorization.

> Not sure why this would be in scope since the user is not an
'application'.
> to validate that a user had direct control over a application might be a
viable
> use case)

I would like to remove the requirements for CA for each single node. CA
might be useful for many cases but not when we supposed to use it for each
single user and single node. So the purpose is to remove CAs and also
automation when we plan not to use CA. because by removing CA, the problem
would be the establishment of trust. So, now the purpose is to provide this
trust with less efforts. Since most spoofing attacks happens in network
layer, we aim to prevent this attack in this layer. 

Please consider that the aim is not only the authentication and
authorization of a user to access some resources but also a node to update,
or modify something on another node. This is why the cases like proxy
servers are important.
Since we are talking about network layer approaches to easily avoid IP
spoofing and other kinds of spoofing problems, then NAT MIGHT cause a
problem and that was a reason that I considered a scenario where one of our
nodes are behind NAT.

Do you think it is clear now? 

> Not really a use case, but one possible addressing Situation.

Ok, then change it to something else.

>  - home IoT widget with IPv6 based on Ephemeral MAC address

Thanks for the suggestion. Ok, I will consider them.

> Not clear if this is in scope for IETF work. Internal security of
Virtualized
> services is not apparent over-the-wire. A virtual server is typically
> indistinguishable from a non-virtual server.
> 
> 
> 
> Draft is a bit rough at the moment.  Clarity in abstract and purpose would
be a
> good starting point.

Ok I will try to address them and will prepare next version.
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 15 Sep 2014 15:22:32 +0000

Hello,

I have revised the secauth requirement and use case draft. I would appreciate your inputs on this new version.

I am going to upload after receiving more feedback
The current pre-upload version can be found here:

< http://editor.rozanak.com/show.aspx?u=AZ6AA4BFD809BB71B2544CTAM >

@Paul, Viktor: would you please check to see whether the document is clear and satisfy the changes you have asked.

@folks: I welcome more comments before uploading new version. Please share your inputs on editorial, document organization or technical.

Thanks,
Best,
Hosnieh