Subject: Re: [Secauth] [saag] secauth requirements and usecase scenarios - link

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: "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,
> 
> [ That is, B's certificate is signed by a CA trusted by A. ]

True

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

True 

> > 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. ]

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.
> 
> Indeed, 3 is better than 2.
> 
> > 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.
> 
> 	s/certification/certificate/
> 
> Don't see where you're going with the second sentence.

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.

> It is unclear what your intentions are in this space.
> 
> > Please note that this is only an example scenario. The main focus is
> > also on virtualization and authentication in dynamic environment.
> 
> You probably need to be a bit more specific than that.

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

> 
> On Tue, Aug 19, 2014 at 12:10 AM, Hosnieh Rafiee <[email-masked]>
> wrote:
> > Hi Nikco,
> >> These are requirements and use cases for what protocol work?  what WG?
> >>
> >
> > Secauth . it is not yet WG.
> 
> 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:
...
> So an attacker cannot spoof this connection even in first place.
...

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: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 08:25:41 +0000

Thanks again Viktor for your continuous suggestions and comments.
> 
> On Tue, Aug 19, 2014 at 03:20:00PM +0000, Hosnieh Rafiee wrote:
> 
> > > 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
> > 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.

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. 

> > 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?

Yes

> Possibly also allow the application layer to in part control the
> network-layer security association for a particular flow?

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

> 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.

Agreed.

Thanks,
Best,
Hosnieh