Subject: [saag] secauth requirements and usecase scenarios

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 18 Aug 2014 15:41:33 +0000

Hello,
Just in case you are not aware of the activities of this secauth group. 
< https://www.ietf.org/mailman/listinfo/secauth >
I haven't yet submitted this document to IETF but would like to receive some comments before to do so.

Please share your comments either editorial or technical. :-) thanks

Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 18 Aug 2014 16:07:19 +0000

Follow up,

This is also a link to where you can find the document
< http://editor.rozanak.com/show.aspx?u=AZ6AA4BFD809BB71B2544CTAM >

Best,
Hosnieh

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Aug 2014 16:39:57 +0000

On Mon, Aug 18, 2014 at 04:07:19PM +0000, Hosnieh Rafiee wrote:

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

> I haven't yet submitted this document to IETF but would like to receive some comments before to do so.

Quick note on wording, what a user or device gets from a CA (i.e.
a "certification authority") is a "certificate".  Somehow you've
reversed these, so that in the draft "ceritificate authorities"
(not correct, though not entirely uncommon) issue "certifications"
(definitely not correct).

In terms of content, it seems as yet unclear where this draft is
going based on the current outline.

You might want to read draft-dukhovni-opportunistic-security and
RFC6698 depending on where you're heading with this.

Is the intent to provide an API for application-level awareness/control
of network-layer security services?

   This document addresses the following problems: 

   - self certification and avoiding identity spoofing of a node (for 
     example, a self certified mail server) 

   - Secure authentication 

   - Privacy and data confidentiality 

   - authentication of devices in case of proxy servers 

   - etc. 

   Therefore, the purpose of this document is to define 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.

   ...

   4.  Requirements 

   This section defines the scope of this document and introduces the 
   requirement of an API for this protocol.

Still not clear where this is going...

-- 
	Viktor.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 18 Aug 2014 23:25:14 +0200

Hi Viktor,
Thanks a lot for your comments. Please see my responses inline.

> > < https://www.ietf.org/mailman/listinfo/secauth > I haven't yet
> > submitted this document to IETF but would like to receive some comments
> before to do so.
> 
> a "certification authority") is a "certificate".  Somehow you've reversed
these,
> so that in the draft "ceritificate authorities"

I changed it. I always used the abbreviation. I heard both but I wasn't sure
which one to use.
It appears that Wikipedia also used both.... 
< http://en.wikipedia.org/wiki/Certificate_authority  >

> In terms of content, it seems as yet unclear where this draft is going
based on
> the current outline.

This draft is related to the requirements for an authentication and
authorization API (it might be later a protocol but at the moment the focus
is on API). We want to use the network layer security approaches and make it
available to other layers for a robust authentication. This is because
network layer knows about the  IP information. Many attacks are initiated on
applications using network layer. This is true that there are also some
application layer attacks that network layer cannot help to detect them.
Such as cross scripting attacks. This is why the aim of this API to provide
a means of network layer security and let the application to use this
approach easily without the need to have information about node's IP.  Of
course, there are other purposes here as well like privacy, automation, and
try to have this security without the use of any public CA.  
The reasons are written in the draft. 
The purpose is to be able to use this approach for authentication of two
devices and also a user to device. 

> RFC6698 depending on where you're heading with this.

Today before I start finishing this requirement, I was reading this draft.
About the RFC, I have read it some time ago. I cannot exactly remember the
detail but there are some differences with the approach planned for this API
and their approaches. This API might be one of the options for
authentication as explained in opportunistic-security. Because the aim is to
simplify authentication and authorization processes as much as possible and
to be able to support different nodes with different resources. The aim is
also automation. This is why the goal is the use of less infrastructure
(ideally no infrastructure) to support such API.
 
> Is the intent to provide an API for application-level awareness/control of
> network-layer security services?

Not exactly, no application is supposed to control network layer but only
access to it (a transparent intermediate interface between network layer and
application layer)

>    requirement of an API for this protocol.
At the moment it is only API not protocol. It was typing mistake... I
removed it.  

Thanks again,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Aug 2014 00:10:49 +0200

Follow up,
Let me give you an example:
Consider a scenario where Client A wants to connect to mail server B. Mail
server B needs to authenticate client A and then let it to mail server B to
submits its email. both nodes uses TLS to secure this process.  If B
supports a CA, then A can easily trust it. If not, A has 3 options, 1- stop
using B,2- change to plain text or 3-accepts B's certificate as it is. Both
2 and 3 are not quite secure but the latter approach is better than the
former one since the attacker only at the beginning of this communication
might spoof the identity of B and steal User A's credential. 
If the hardcopy certification of B is available in node A then, the
likelihood of this attacks is almost zero. However in this case A should
keep the mapping of IP and keys otherwise other approaches are in use.

This API is supposed to help in similar scenarios without having complexity
or dependency to any infrastructure. Combination of network layer approaches
with other layer above network layer are better handle this secure
authentication since it already has an opportunity to authenticate node B in
network layer and in case its identity is ok, let the application to process
any other authentication such as password based, token based, etc. 

Please note that this is only an example scenario. The main focus is also on
virtualization and authentication in dynamic environment.

Best,
Hosnieh
P.S. we also welcome any contributors :-)

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Aug 2014 17:46:41 -0500

These are requirements and use cases for what protocol work?  what WG?

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 00:39:27 +0000

On Tue, Aug 19, 2014 at 12:10:49AM +0200, Hosnieh Rafiee wrote:

> submits its email.  Both nodes uses TLS to secure this process.  If B
> supports a CA,

[ That is, B's certificate is signed by a CA trusted by A. ]

> then A can easily trust it.  

[ Then A can authenticate the security of its TLS-encrypted channel to B. ]

> If not, A has 3 options,
>
>	1-stop using B,
>	2- change to plain text or
>	3-accepts B's certificate as it is.

[ There is also a possibility of B using DANE, and A's MUA (some day)
  supporting DANE, in which case the need for a mutually trusted CA
  goes away. ]

Option 2 is wrong, and specifically highlighted as such in the
opportunistic TLS draft.

> Both 2 and 3 are not quite secure but the latter approach is better than the

Indeed, 3 is better than 2.

> keep the mapping of IP and keys otherwise other approaches are in use.

	s/certification/certificate/

Don't see where you're going with the second sentence.

> or dependency to any infrastructure.

What API?  What problem is the new API intended to address?  On what foundation
is the API supposed to be implemented?

> Combination of network layer approaches

Well, in many cases the mapping from B's DNS name in A's configuration
to B's IP address is over insecure DNS.  Then it does not matter
if A can get a secure connection to B's IP address.  The MiTM wins by
spoofing the DNS replies.  You'd need a network-layer security association
that is tied to DNS names, and indeed APIs to establish network connections
that communicate these name to the network layer.  This is a difficult problem.

It is unclear what your intentions are in this space.

> virtualization and authentication in dynamic environment.

You probably need to be a bit more specific than that.

-- 
	Viktor.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Aug 2014 07:10:45 +0200

Hi Nikco,
> These are requirements and use cases for what protocol work?  what WG?

Secauth . it is not yet WG.

Best,
Hosnieh

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Aug 2014 00:23:48 -0500

> Secauth . it is not yet WG.

Are there any BoF materials?  Proceedings?

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Aug 2014 07:37:18 +0200

Thanks again Viktor, please see my responses inline...

> 
> > Consider a scenario where Client A wants to connect to mail server B.
> > Mail server B needs to authenticate client A and then let it to mail
> > server B to submits its email.  Both nodes uses TLS to secure this
> > process.  If B supports a CA,
> 

True

> [ Then A can authenticate the security of its TLS-encrypted channel to B.
]

True 

>   supporting DANE, in which case the need for a mutually trusted CA

Have you ever had a chance to read CGA-TSIG draft (In new version I will
remove many unrelated sections)?  This is supposed to help for the last
miles of Internet or supposed to help DNSSEC in last miles where it is not
easy to handle data confidentiality and secure authentication. It supposed
to automate this process. (it is of course not about only CGA but other
network layer approaches to support both IPv4 and iPv6 enabled network)

That draft is an example of what secauth plan to do but, of course, we are
not planning to use CGA but some other approaches. 
DANE uses DNSSEC that is not easy to handle the last miles again and such
approaches like secauth can help in this regard where not easily can
authenticate a node. In other words, secauth plans to use easier approach or
only IP based and then you can combine this approach with TLS or any other
approaches above network layer. This is what I meant in the draft. 

Let me give you another example about SSH. 

(it is also mentioned in opportunistic TLS)
Client A wants to connect to server B via SSH. Server B does not support
certificate signed by a CA. So it is vulnerable in first point. Now,
supposed a scenario where secauth is in use. A knows the IP address or
domain name of B. A and B supports secauth and implemented it. A request for
connecting to B. B sends its certificate that is bound to B's IP address.
Since A knows the IP address of B, A ensures that this certificate is from
B. 
So an attacker cannot spoof this connection even in first place.

Is it clear?

> Option 2 is wrong, and specifically highlighted as such in the
opportunistic TLS
> draft.

True
Opportunistic TLS highlighted the problem. But secauth is a possible
solution to a problem

> > Both 2 and 3 are not quite secure but the latter approach is better
> > than the former one since the attacker only at the beginning of this
> > communication might spoof the identity of B and steal User A's
credential.
> > likelihood of this attacks is almost zero. However in this case A
> > should keep the mapping of IP and keys otherwise other approaches are in
> use.
> 

Please see above.

> > This API is supposed to help in similar scenarios without having
> > complexity or dependency to any infrastructure.
> 
> What API?  What problem is the new API intended to address?  On what
> foundation is the API supposed to be implemented?

The authentication and authorization without the need of infrastructure and
help other services where not easy to handle the last miles. It can be DANE,
DNSSEC, etc.

> > Combination of network layer approaches with other layer above network
> > layer are better handle this secure authentication since it already
> > has an opportunity to authenticate node B in network layer and in case
> > its identity is ok, let the application to process any other
> > authentication such as password based, token based, etc.
> 
> Well, in many cases the mapping from B's DNS name in A's configuration to
B's
> IP address is over insecure DNS.  Then it does not matter if A can get a
secure
> connection to B's IP address.  The MiTM wins by spoofing the DNS replies.
> You'd need a network-layer security association that is tied to DNS names,
and
> indeed APIs to establish network connections that communicate these name
> to the network layer.  This is a difficult problem.

No, please check CGA-TSIG draft. That is supposed to answer that question.

> > Please note that this is only an example scenario. The main focus is
> > also on virtualization and authentication in dynamic environment.
> 

I hope that is clear.
I am planning to have an online discussion next week.
I will be glad to explain to anyone who is interested.
http://doodle.com/se3gyys9dnre4nyr

If these time doesn't work for anyone, feel free to suggest other times.

Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Aug 2014 07:44:55 +0200

> Are there any BoF materials?  Proceedings?

There are discussions of mailinglist
http://www.ietf.org/mail-archive/web/secauth/current/maillist.html

I also summarized last messages discussed on mailinglist. It was not so active recently because I needed to complete first version of the requirement draft before I can start any discussion but now I am following it and will actively answer questions, concerns, plans, etc.
You can find the link in " [Secauth] All messages, Hosnieh Rafiee"
I plan to have a BoF for the upcoming IETF in Hawaii.

Next week also I prepared some slides to explain this approach and welcome online participation. 
There is a doodle poll for the times and dates (as I already explained in my last message to Viktor)
http://doodle.com/se3gyys9dnre4nyr 

Thanks for asking,
Best,
Hosnieh

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 19 Aug 2014 08:23:42 -0400

Hosnieh,

I think it would help a lot if you could add more background and context to the introduction so folks know if it's relevant to their areas of work.  The draft jumps right in without that.

Viktor's message was helpful if that's what you had intended to cover (last mile description he provided).

Thanks,
Kathleen

Sent from my iPhone

On Aug 19, 2014, at 1:44 AM, "Hosnieh Rafiee" <[email-masked]> wrote:

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

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 19 Aug 2014 13:01:33 +0000

Hi Kathleen,

Thanks for your suggestion.
> 
> I think it would help a lot if you could add more background and
> context to the introduction so folks know if it's relevant to their
> areas of work.  The draft jumps right in without that.
> 

Ok, I will add more background text and will also cover the discussion that I had with Viktor. By his comments, I also noticed that there is missing section in the draft while I thought everything is clear :-| 

Thanks,
Best,
Hosnieh

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Aug 2014 10:53:54 -0400

Trimming...

On 8/19/14, 1:37 AM, Hosnieh Rafiee wrote:
...
...

As far as I can tell, any solution which assumes A knows the current IP 
address of B without DNS or any other rendezvous protocol is a non-starter.

If it is using DNS, then the DNS needs to be protected, or the structure 
fails.

If DNS is protected, then DANE could be used.  With greater flexibility 
and less modification of existing tools.

Yours,
Joel

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 19 Aug 2014 15:20:00 +0000

Hi Joel,

Thanks for your comment. See my response inline..
> If it is using DNS, then the DNS needs to be protected, or the
> structure fails.
> 

As far as I understood from DANE document, by knowing only the IP address of a node, DANE cannot work because IP spoofing is still possible and there is no CA to protect this. No bindings of IP address is available.

The purpose of secauth is to provide this binding for other mechanisms.
For instance, it is possible to use secauth for a part of this authentication and combine it with DANE or any other approaches. Secauth only provides a transparent API for you to use it in other layers.

I am adding some background information but in the meanwhile you can also check CGA-TSIG draft to see how a solution like secauth suppose to work.

Best,
Hosnieh

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 15:31:37 +0000

On Tue, Aug 19, 2014 at 03:20:00PM +0000, Hosnieh Rafiee wrote:

> As far as I understood from DANE document, by knowing only the
> IP address of a node, DANE cannot work because IP spoofing is still
> possible and there is no CA to protect this. No bindings of IP
> address is available.

This is not a DANE-specific issue.  Typically, applications want
channel security to a destination that is a domain name, not a
network address.  Absent a secure mapping from one to the other,
there is little that network-layer security, that authenticates
only the network endpoint, can do to close the gap.

This problem applies equally to DANE, Web PKI, ...

> Secauth only provides a transparent API for you to use it in other
> layers.

The requirements draft is very unclear on this.  Is this an attempt
to expose the security state of the network layer to applications?
Possibly also allow the application layer to in part control the
network-layer security association for a particular flow?

If so, the draft should probably talk more about what state it intends
to expose and what control mechanisms it intends to provide.  Or
at least what the requirements are for exposing state and controls.

-- 
	Viktor.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 08:25:41 +0000

Thanks again Viktor for your continuous suggestions and comments.
> > > If DNS is protected, then DANE could be used.  With greater
> > > flexibility and less modification of existing tools.
> >
> > As far as I understood from DANE document, by knowing only the IP
> > address of a node, DANE cannot work because IP spoofing is still
> address
> > is available.
> channel security to a destination that is a domain name, not a network
> address.  Absent a secure mapping from one to the other, there is
> little that network-layer security, that authenticates only the network
> endpoint, can do to close the gap.

I agree that there is a gap in security especially in the end points. But I guess it is also important to try to remove this gap. Maybe it is not possible to completely remove it but do as much efforts as possible. 
I still think that secauth can work on making this gap smaller by network security. I agree that most applications are working with domain names and not the IP address. But where they bring this domain name? So, the initial connection is with an IP address. As I also mentioned the cga-tsig draft as an example case, it can secure the communication in end point with DNS server where DNSSEC or other approaches are unable to do this or they cannot easily do this. And of course secauth also wants to consider privacy, this is why encryption is a part of that. But it can be handle by other protocols. like my example about SSH. 

To be clear, the plan of this API is to offer solutions in first point of connection or automate this step as much as possible. When first point can be secure then you can combine this approach with TLS to also encrypt all the data or use the offered solution by secauth to encrypt the data. This is then your choice.  

> This problem applies equally to DANE, Web PKI, ...

So  it appears that we agree on the problem and we are talking about the same problem. I think the solution I plan will work... 
I am not quite sure but I think for requirement draft, it is important to identify the problem(s) and explain the requirements to solve this problem. And of course there can be some usecase scenario that where we want to go and how we can use this approach.

If there is other things need to be added to the requirement document, I welcome any suggestions. 

Today I am working on the requirement draft to cover what we discussed here. 

> The requirements draft is very unclear on this.  Is this an attempt to
> expose the security state of the network layer to applications?

Yes

> network-layer security association for a particular flow?

About this, I am not sure.. depends on other's opinions.. and decisions.

> to expose and what control mechanisms it intends to provide.  Or at
> least what the requirements are for exposing state and controls.

Agreed.

Thanks,
Best,
Hosnieh