Re: [Ace] a possible solution candidate?

[Hannes Tschofenig <[e-mail]>]

Hi Hosnieh

my initial reaction is that those are two separate efforts since we are
focusing on application layer authentication and authorization.

If you take a quick look at the updated charter text you will see the
different focus:
https://www.ietf.org/mail-archive/web/ace/current/msg00346.html

Ciao
Hannes


On 03/11/2014 07:55 PM, Hosnieh Rafiee wrote:
> Hi,
> 
> I just get to know this WG during IETF in London. Since I am also working in
> secure authentication and authorization in a non-WG group (CC), but in
> general and not only for constrained devices. In other words, the scope of
> your mailinglist is a small part of that. The outcome of secauth will be an
> API that allows the application layers' services or other layers' services
> to use this API for authentication purposes. Based on the needs, one can
> also integrate it with other approaches an duse it for securer
> authentication and at the same time avoid IP spoofing. This is why the work
> of this mailinglist grabbed my attention. Before IETF I was in a process of
> preparing a requirement document for using a network layer approach for
> authentication in other layers and still working on it (probably you can
> read more about my purpose there). One of the solution space approach that I
> thought might be useful for the start was one of my draft that is called
> SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ).
> -----The new version of this draft will be coming soon (I know the current
> version is messy.. :-| )------
> 
> I thought maybe you also find it useful as a candidate solution for your
> authentication purposes. I try to explain how SSAS can be helpful
> 
> General advantages
> -  Prevent IP spoofing (binding between the public key and the IP address)
> - The authentication can be only based on IP address (or one can also
> integrate it with other approaches)
> - Since IP spoofing can prevents other attacks such as MITM, TCP/UDP
> amplifications, 
> - It uses a short key size algorithm so that it avoids the use of large
> memories
> 
> Some of other advantages:
> - It is enough that the two communication nodes only know the IP address of
> each other, then they can ensure that there is no MITM.
> - It does not need to check the keys up to certain level to ensure that this
> key belongs to this node with this IP address (like what is needed for TLS
> if one wants to ensure about the key authorization).
> -  It doesn't need to buy a certificate for each single nodes in order to
> provide the node with a secure TLS or SSL authentication
> etc.
> 
> 
> 
> At the moment I integrated this approach for DNS confidentiality, data
> integrity and secure authentication (please refer to these slides
> http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf ). I also
> saw a paper that integrated SSAS as a secure authentication purposes in SIP
> protocol. This is because in SIP, an attacker can easily spoof the identity
> of the two ends of communication nodes. Since SSAS prevents IP spoofing,
> this prevents identity spoofing as well (if the identity is the IP address).
> 
> One disadvantage of this approach was that it only supports iPv6, I also
> tried to cover it (Please check the approach in the slides for CGA-TSIG).
> So, the support of IPv4 will appear in the next version of draft. 
> 
> If you have any question, do not hesitate to ask.
> 
> Thanks,
> Best,
> Hosnieh
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>