Subject: RE: 6MAN Adoption call on draft-rafiee-6man-ssas-07

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 00:52:34 +0100

Ole,

I guess how you posed this question is like someone can predict the future
and also you consider it as an entity which is dependent to SeND. But it is
not true. Can you really pose the same question for all the current drafts,
especially, the one that are now WG drafts? I guess no. They are not BCP to
easily answer the question like this otherwise you change the current
process of IETF and ask everybody first to implement, then write BCP and
then write standard draft. Moreover, SeND is dependent to this option but
not otherwise. IMHO, your question needs to be rephrased (see the following
questions). I guess the whole discussion until now was around the following
questions and this is the true discussion. It is true that the draft should
address the deployment processes that this is on process and also will
improve via receiving comments from operational experts and also open to
suggestions.  

-  Do we need security in layer 3?
-  Is it good to integrate security of layer 2 and layer 3 and have dynamic
MAC?
-  Is local security an important issue in network and do you care about
local security as you care about global security?
- Do you think all your nodes are not malicious in the network and will not
be malicious in future and you can trust all your nodes, any time and
always? 
- How do you rate the importance of the performance (0 not important ... 10
is so important; choose a number)

Since I believe that SSAS also can be used as a means of authentication in
other layers such as application (DNS, SIP, etc), I also included the
following questions because I think prove of IP address ownership can solve
many authentication issues and it is beyond the SeND scenario. It can also
integrate with other security approaches to provide a higher security.

- Do you want to have network layer authentication for your applications
(means you ensure about the owner of this IP and you ensure about that it is
not an spoofed IP)
- Do you want to have an access list based on an IP address but without
worrying that the attacker can spoof it?

Thanks,
Smile,
Hosnieh

> <nohat>
> 
> as Christian pointed out there is a challenge with lack of SEND
deployment.
> I'm not under the impression that CGA is the reason for that(?)
> 
> will SSAS make SEND more deployable?
> if the answer to that is no, then I'm not sure I would support spending
the
> effort on this.
> (working for a company that actually have implemented SEND).
> 
> cheers,
> Ole
> 
> > We reconsidered the action from Vancouver, and decided to have the
> discussion on this draft as part of the adoption call instead.
> > Please provide a view with reasons as to whether the WG should adopt
this
> or not.
> >
> > This message starts a one week 6MAN Working Group call on adopting:
> >
> > 	Title           : A Simple Secure Addressing Scheme for IPv6
> AutoConfiguration (SSAS)
> > 	Author(s)    : H. Rafiee, C. Meinel
> > 	Filename    : draft-rafiee-6man-ssas-07
> > 	Pages        : 15
> > 	Date          : 2013-11-4
> >
> >    http://tools.ietf.org/html/draft-rafiee-6man-ssas-07
> >
> > The call ends on November 26th, 2013.
> >
> > Regards,
> >
> > Bob Hinden & Ole Trøan
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Nov 2013 12:56:27 +0100

Hosnieh,

I agree with you that SSAS/SEND is a solution to the threats listed.
CGA/SEND is an existing solution to the threats.

the existing solution isn't deployed.
my question was, is there any reason that new proposal would change that situation?
or rhetorically, are we by standardising a competing algorithm just making the deployment situation worse.

that question could for example be answered by implementers stating they have plans to implement SSAS/SEND,
and/or didn't because of the issues with CGA.

note, that these threats are mitigated today in the network, with technologies like RA guard, SAVI, cisco's FHS and I'm sure other switch/router mechanisms.

I don't think the other uses of SSAS is within the scope of 6man.

cheers,
Ole

---

From: Hosnieh <[email-masked]>
Date: Thu, 21 Nov 2013 07:59:17 -0500 (EST)

Ole,

Thanks for clarification.

IMHO the reasons:
- No good deployment model (which is the focus of this draft  as I already
discussed about "how to" with Dan and Erik and using their comments)

- Not good understanding of the possible threats and problems and think the
current approaches are enough
This means you trust all your nodes, any time, any place and always and you say
none of them one day will be malicious. in RA gaurd, you care about the node
that claim to be a router and send a multicast RA. If you think RA gaurd can
really protect you let me here explain a practical scenario that we tested it in
our lab during last semester(IPv6SSL). We sent unicast router advertisement
(while it should be multicast) to a victim node. It worked and the victim node
chose this computer as a router and this worked fine and we didn't harm the
network as well!!. This fake ra prefix was valid in the node until the node
received a new RA message from the legitimate router. I guess you need to have a
very short RA interval to prevent such MITM attack but if you do so you only
increase the local network traffic while you could prevent it by easily using a
security mechanism.
It can be the problem of protocol that actually this is again what we planned to
address in SSAS to prevent such attacks!

- No motivation for implementors that care about latency and complexity. I guess
in other group yesterday I just saw a message (probably perpass mailing list!??)
someone discussed about this problem and had CGA an example of making latency
for applications that even small value of time is important.

I agree that applications are out of scope but we all know that the applications
are the one that use these IP addresses for communication purposes and actually
the latency has a meaning in application layer or other factors like
performance, complexity. So what I say here is you cannnot completely forget
about other layers but you do not need to focus on them.

Of course WG also might have more reasons to include to this list that might be
good again to be considered as an improvement to this draft.
Thanks,

> On November 21, 2013 at 6:56 AM Ole Troan <[email-masked]> wrote:
>
>
> Hosnieh,
>
> note, that these threats are mitigated today in the network, with technologies
> like RA guard, SAVI, cisco's FHS and I'm sure other switch/router mechanisms.
>
---
Hosnieh
Sorry for tpyos from my chubby fingers typing on my phone

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Nov 2013 15:03:24 +0100

Hosnieh,

> - No good deployment model (which is the focus of this draft  as I already discussed about "how to" with Dan and Erik and using their comments)

what I got out of that discussion was: "really, really, hard".
did you mean something else?

> - Not good understanding of the possible threats and problems and think the current approaches are enough
> This means you trust all your nodes, any time, any place and always and you say none of them one day will be malicious. in RA gaurd, you care about the node that claim to be a router and send a multicast RA. If you think RA gaurd can really protect you let me here explain a practical scenario that we tested it in our lab during last semester(IPv6SSL). We sent unicast router advertisement (while it should be multicast) to a victim node. It worked and the victim node chose this computer as a router and this worked fine and we didn't harm the network as well!!. This fake ra prefix was valid in the node until the node received a new RA message from the legitimate router. I guess you need to have a very short RA interval to prevent such MITM attack but if you do so you only increase the local network traffic while you could prevent it by easily using a security mechanism.
> It can be the problem of protocol that actually this is again what we planned to address in SSAS to prevent such attacks!

please don't put words in my mouth. all solutions require a correct implementation.
what I said was:
- existing SEND/CGA solves the problem
- in current deployments, because of no deployment of SEND it is solved in the network.
  given mechanisms like SAVI, FHS, and a link model where there is a switch or router that intercepts all on-link traffic,
  these threats can be mitigated in the network. those mechanisms benefit from address registration with DHCP or ARO,
  and implement first come first serve. do you disagree that these threats can be mitigated in the network?

I'm not saying solving this in the network is the best approach, but it is deployable. and that's what matters.

I am trying to understand if standardising SSAS would help the situation?

> - No motivation for implementors that care about latency and complexity. I guess in other group yesterday I just saw a message (probably perpass mailing list!??) someone discussed about this problem and had CGA an example of making latency for applications that even small value of time is important.

so you are saying that given SSAS's smaller computational requirements there are people who would implement this.
could they speak up on this list?

> I agree that applications are out of scope but we all know that the applications are the one that use these IP addresses for communication purposes and actually the latency has a meaning in application layer or other factors like performance, complexity. So what I say here is you cannnot completely forget about other layers but you do not need to focus on them.

right, but this set of problems can also be solved elsewhere, ipsec, or higher layer security.

> Of course WG also might have more reasons to include to this list that might be good again to be considered as an improvement to this draft.

cheers,
Ole

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Thu, 21 Nov 2013 16:11:54 +0000

Hi,
SeND is a two players game: host & routers. Playing alone is not fun...
As one among very few implementers of rfc3971 (SeND), in a router stack,
and having talked many times over many years with host stack vendors, I
can give you a few hints on where the problems are:
- It is not deployed because host stack vendors have not implemented it.

- For the first part (CGA), they have not done CGA because they don't see
that as a very high priority item. There is no performance issue (1 sec to
generate an address with sec-lvl=1 these days), no big security issue (yes
it could be better), no big privacy issue (key pair can be re-generated
every hour if you want) and no deployment issue (does not rely on any key
distribution or other pki).
- For the second part (Router authorization), it is not deployable across
administrative boundaries (no "verisign" infrastructure for authorizing
routers), so has very limited value.

I read though the draft and I don't see how it is helping in any of these
two areas.
- change CGA with something else, and we will move from 1 player (router
vendors) to no players at all. Not good for a two players game...
- It does not address the deployability challenge around router
authorization.
Until we get any deployment experience, or there is a breakthrough
proposal for improving the deployability, I don't support protocol
algorithmic or protocol changes.
Eric

On 21/11/13 12:56, "Ole Troan" <[email-masked]> wrote:

>note, that these threats are mitigated today in the network, with
>technologies like RA guard, SAVI, cisco's FHS and I'm sure other
>switch/router mechanisms.
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Nov 2013 09:28:03 -0800

At Thu, 21 Nov 2013 12:56:27 +0100,

> and/or didn't because of the issues with CGA.

FWIW: when we discussed whether to implement SEND and dropped the idea
in the end at the KAME project (developing an open-source reference
implementation of IPv6 for BSDs) years ago, one major blocking issue
was the CGA's IPR.

We didn't like licenses such as "(only) free for non commercial use"
or "if you don't sue us we won't sue you on this either".  Even though
the project itself could clear these conditions, we didn't like to
implement anything if its users (including those of BSD variants with
this integration for commercial purposes) have to worry about these.

I guess many open source developers would still react this way today.
So, if SAAS avoids infringing patents for CGA, I think it'll have a
better chance of adoption in those communities.  I'd note, however,
that "I have not copy or follow the CGA algorithm, it does not follow
the patent" (from
http://www.ietf.org/mail-archive/web/ipv6/current/msg19570.html) is
quite weak as a proof that SAAS is not susceptible to the patent.  One
would have to carefully check all of the patent claims and confirm
none of them could apply.  The above cited sentence doesn't seem to
mean such careful and comprehensive check.

--
jinmei

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 18:54:37 +0100

Hi Jinmei,

I ensure you that SSAS does not have any patent. It was a result of academic
research after many experiments on CGA usability and performance. You can
only find an academic IEEE paper about this (One of the reference of this
draft but besides that there is no patent or other legal issue.) It has its
own algorithm and different than CGA. It also has its own options and
parameters and its deployment can also not necessarily dependent to SeND but
it can be dependent to a new RPKI model that was in first versions of this
draft but due to the fact that some people thought it should be in a
separate draft I just removed it.  

http://www.ietf.org/proceedings/88/slides/slides-88-6man-11.pdf here in
slide 4, you can find CGA algorithm. 

Thank you,

> So, if SAAS avoids infringing patents for CGA, I think it'll have a better
chance
> of adoption in those communities.  I'd note, however, that "I have not
copy or
> follow the CGA algorithm, it does not follow the patent" (from
> http://www.ietf.org/mail-archive/web/ipv6/current/msg19570.html) is quite
> weak as a proof that SAAS is not susceptible to the patent.  One would
have to
> carefully check all of the patent claims and confirm none of them could
apply.
> The above cited sentence doesn't seem to mean such careful and
> comprehensive check.
> 
> --
> jinmei

Smile,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 19:21:58 +0100

Ole,

Sorry when I said "you", I meant "you" as a sample or a general one but not
you as an individual. Next time I will use "someone" that nobody thinks I
want to put words in his/her mouth. 

> > - No good deployment model (which is the focus of this draft  as I
> > already discussed about "how to" with Dan and Erik and using their
> > comments)
> 

Probably with the current specifications that SeND has, they see it like
this. But I guess we can make it better in this draft. This is why I would
like to ask to extend the deadline for this adoption call that I have a
chance to apply the current comments and upload a new version.

> > - Not good understanding of the possible threats and problems and
> > think the current approaches are enough This means you trust all your
> nodes, any time, any place and always and you say none of them one day
will
> be malicious. in RA gaurd, you care about the node that claim to be a
router
> and send a multicast RA. If you think RA gaurd can really protect you let
me
> here explain a practical scenario that we tested it in our lab during last
> semester(IPv6SSL). We sent unicast router advertisement (while it should
be
> multicast) to a victim node. It worked and the victim node chose this
computer
> as a router and this worked fine and we didn't harm the network as well!!.
This
> fake ra prefix was valid in the node until the node received a new RA
message
> from the legitimate router. I guess you need to have a very short RA
interval
> to prevent such MITM attack but if you do so you only increase the local
> network traffic while you could prevent it by easily using a security
> mechanism.
> > It can be the problem of protocol that actually this is again what we
planned
> to address in SSAS to prevent such attacks!
> 
>   given mechanisms like SAVI, FHS, and a link model where there is a
switch or
> router that intercepts all on-link traffic,
>   these threats can be mitigated in the network. those mechanisms benefit
> from address registration with DHCP or ARO,
>   and implement first come first serve. do you disagree that these threats
can
> be mitigated in the network?

The problem might be Patent based on an offlist discussion and I say what he
exactly said
" I think that the FUD around the patents are definitely of concern to some.
Did that stop code from being contributed to Linux?  Maybe."

My question here is, DHCPv6 itself is not secure. So, am I understand you
correctly here that someone can combine some insecure approaches with
monitoring and have a security approach out of it? Do monitoring systems can
perform well in critical situation? Isn't it better to have real local
security approach and combine it with monitoring to prevent this attack
instead of mitigation?

> I am trying to understand if standardising SSAS would help the situation?

I guess it helps. Not only performance that Eric not agrees but I still say
it can help since we have also to consider verifications and also
generation. But packet size is another issue with CGA that I guess Eric was
concerned about it in other thread. 

> > - No motivation for implementors that care about latency and complexity.
I
> guess in other group yesterday I just saw a message (probably perpass
mailing
> list!??) someone discussed about this problem and had CGA an example of
> making latency for applications that even small value of time is
important.
> 
> so you are saying that given SSAS's smaller computational requirements
there
> are people who would implement this.

I just posted it to application area. Probably if nobody wants to contribute
in this mailing list, you can also find some discussions in intarea in IETF
86 for CGA-TSIG. 50% of people who were against it at that time was because
of CGA performance. This was actually formed this idea.  

Thanks,
Smile,
Hosnieh

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Nov 2013 10:32:00 -0800

At Thu, 21 Nov 2013 18:54:37 +0100,
"Hosnieh Rafiee" <[email-masked]> wrote:

> research after many experiments on CGA usability and performance.

That's not what I meant (or more important, what today's open source
developers would care about).  The question is whether SAAS infringes
any existing patents for CGA.

> It has its

These don't necessarily mean SAAS is safe against the CGA patents.  As
I said in my previous message, what one would have to do is to examine
the patent claims (not the technical specs of CGA) and confirm none of
them applies to SAAS (if you don't understand how these two are
different, ask your lawyer).

Basically, it should be  actual developers and vendors who is responsible for
doing such research.  But, in cases where developers are more or less
skeptical and the protocol designer (= you) is trying to convince
them, you'd be the person to prove that if you want to entice them to
implement it.

--
JINMEI, Tatuya

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 21:09:12 +0100

Hi Eric and for those who thinks CGA is secure!

can
> give you a few hints on where the problems are:
that
> as a very high priority item. There is no performance issue (1 sec to
generate
> an address with sec-lvl=1 these days), no big security issue (yes it could
be
> better), no big privacy issue (key pair can be re-generated every hour if
you
> want) and no deployment issue (does not rely on any key distribution or
other
> pki).
two
> areas.
authorization.
> Until we get any deployment experience, or there is a breakthrough
proposal
> for improving the deployability, I don't support protocol algorithmic or
> protocol changes.
> Eric
> 

CGA has one BIG  security issue. It just came to my mind while I was writing
a brute force attack against CGA (sometimes bad guy implementation really
helps...). In CGA algorithm the 3 bits of sec value is ignored in
verification process and only be used as a way to detect the sec value.
Since the verifier node ignore these bits. For attacker it is not important
to do brute force attacks against CGA with sec value 0 or n. So, I as an
attacker choose sec value 0 and try to find the similar value. That's it.
For me as an attacker, is only important to do brute force attack against 59
bits. If we say ok we also include bits u and g then 61 bits. It is even
weaker than SSAS initial version and can never compare to SSAS current
version.

I refer you to step 4 verificaton of CGA algorithm
4. Compare Hash1 with the interface identifier (i.e., the rightmost
      64 bits) of the address.  Differences in the three leftmost bits
      and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored.  If
      the 64-bit values differ (other than in the five ignored bits),
      the CGA verification fails.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:16:15 +0100

> verification process and only be used as a way to detect the sec value.

 From RFC3972, section 5 CGA Verification

(which describes the verification process)

    5. Read the security parameter Sec from the three leftmost bits of
       the 64-bit interface identifier of the address.  (Sec is an
       unsigned 3-bit integer.)

    6. Concatenate from left to right the modifier, 9 zero octets, the
       public key, and any extension fields that follow the public key in
       the CGA Parameters data structure.  Execute the SHA-1 algorithm on
       the concatenation.  Take the 112 leftmost bits of the SHA-1 hash
       value.  The result is Hash2.

    7. Compare the 16*Sec leftmost bits of Hash2 with zero.  If any one
       of them is not zero, the CGA verification fails.  Otherwise, the
       verification succeeds.  (If Sec=0, the CGA verification never
       fails at this step.)

Regards, marcelo

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 21:23:39 +0100

> > CGA has one BIG  security issue. It just came to my mind while I was
> > writing a brute force attack against CGA (sometimes bad guy
> > implementation really helps...). In CGA algorithm the 3 bits of sec
> > value is ignored in verification process and only be used as a way to
detect
> the sec value.

The case is you ignore the sec when you're comparing it with interface ID. I
choose sec value 0, you choose sec value 1.  I can generate the same value
as you. I send it as a multicast message. You compare mine with your
interface ID and ignore sec value. It is the same! Now you process the other
part of verification based on my sec value. Mine is 0 and correct. Your is 1
and for your value is also correct. None failed not for attacker and not for
me. I could cheat you with my value.

Smile, 
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:48:19 +0100

> me. I could cheat you with my value.

I dont follow the attack.

if you change the SEC, you change the resulting address, so you would be 
stealing a different address, not the initial CGA.

I mean, the whole point of the CGA tool is to prove that whoever is 
sending a message is the owner of the CGA.
Changing the address in an attack kind of beats the purpose of the 
attack afaict

In other words, please expand the description of the attack, what is the 
attacker trying to achieve?

Regards, marcelo

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 21:56:09 +0100

> >>> to
> > The case is you ignore the sec when you're comparing it with interface
> > ID. I choose sec value 0, you choose sec value 1.  I can generate the
> > same value as you. I send it as a multicast message. You compare mine
> > with your interface ID and ignore sec value. It is the same! Now you
> > process the other part of verification based on my sec value. Mine is
> > 0 and correct. Your is 1 and for your value is also correct. None
> > failed not for attacker and not for me. I could cheat you with my value.
> 
sending a
> message is the owner of the CGA.
> Changing the address in an attack kind of beats the purpose of the attack
> afaict
> 

Avoid prove of address ownership since he can claim the ownership or poison
the cache of neighboring nodes with false value and force the original CGA
node to waive his rights of having that address. 

This attack is exactly what CGA claim to made it so hard for the attacker
but it really didn't and instead with sec value it increased the complexity,
latency and performance as I before, also talked about complexity and
performance of CGA 

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Nov 2013 21:59:44 +0100

El 21/11/13 21:56, Hosnieh Rafiee escribió:
> Avoid prove of address ownership since he can claim the ownership

If you change the SEC value, you change the address itslef, hence you 
can claim ownership of a different address, hence the attack against the 
CGA has failed.

Regards, marcelo

>   or poison

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 23:00:24 +0100

> 
> El 21/11/13 22:14, Hosnieh Rafiee escribió:
> > If you change the SEC value, you change the address itslef, hence 
> > you can claim ownership of a different address, hence the attack 
> > against the CGA has failed.
> >
> > The important thing is that you set the target address to your 
> > victim address and send it to multicast address. Since all nodes and 
> > your victim node see the same address and process it. Then my attack 
> > is successful because during verification everything goes well.
> 
> still dont understand what your attack is trying to achieve...
> 
> If you would mind describing in detail what is the goal of the attack, 
> it would be useful for me
> 
> Regards, marceo

I forge your identity and force you as a real owner of this IP to give up
using it. 
The node verification happens in two scenario:
- during DAD process
If I am able to successfully process my attack and find the same CGA value,
I do not let you as a real or owner of the proper CGA value to configure
your IP address. After some tries your node give up and stop any more tries
otherwise you reboot your node to give it another chance to try again but
this can happen the next times as well.

- during neighbor reachability check( an example scenario but I guess you
can find better scenarios) or starting a communication with other node My
CGA node A wants to communicate with CGA node B. I , as an attacker, forged
the A IP address. B start asking A, I sniff the network and claim to be A.
The IP address verification is successful. It choose me as a A. I can make
busy the real A with other verification processes (false packets). I can be
also MITM. Since I can also forge the identity of B and do not make A busy.
Both of them thinks they are communicating to eachother since they believed
on CGA verification that avoid IP spoofing. But it is not a case here. I am
in the middle of their communications.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Nov 2013 07:32:16 +0100

> this can happen the next times as well.

so the impact of this attack is to reply to DAD and claim you have some 
else's address?
If that is the case, this is well known issue (you dont even need to 
have any crypto material for this as CGAs are supposed to co exist with 
non crypto addresses, so you can you send a normal DAD response and the 
initiator node will give up the address, so I am not sure there is a new 
vulnerability here

> the A IP address.

but if i understood it correctly you are not forging A's address because 
the attacker address has a different SEC value, hence a different IP 
address!

Anyway, i suggest that if you have found an attack against CGAs or SeND, 
document it in a draft, so we can take a look to it in detail. At this 
point it doesnt seem feasible to me to understand your attack via email.

Regards, marcelo

>   B start asking A, I sniff the network and claim to be A.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 22 Nov 2013 08:18:35 +0100

> >> If you would mind describing in detail what is the goal of the
> >> attack, it would be useful for me
> >>
> >> Regards, marceo
> > I forge your identity and force you as a real owner of this IP to give
> > up using it.
> > If I am able to successfully process my attack and find the same CGA
> > value, I do not let you as a real or owner of the proper CGA value to
> > configure your IP address. After some tries your node give up and stop
> > any more tries otherwise you reboot your node to give it another
> > chance to try again but this can happen the next times as well.
> 
else's
> address?

Yes. 

> If that is the case, this is well known issue (you dont even need to have
any
> crypto material for this as CGAs are supposed to co exist with non crypto
> addresses, so you can you send a normal DAD response and the initiator
node
> will give up the address, so I am not sure there is a new vulnerability
here
> 
> >
> > - during neighbor reachability check( an example scenario but I guess
> > you can find better scenarios) or starting a communication with other
> > node My CGA node A wants to communicate with CGA node B. I , as an
> > attacker, forged the A IP address.
> 
the
> attacker address has a different SEC value, hence a different IP address!
> 
point it
> doesnt seem feasible to me to understand your attack via email.
> 

When two nodes want to start communication, they send messages (NS/NA) that
who has this IP address. If someone can send a solicited message with the
correct nonce as a response and the verification is successful, then they
accept him as the owner.  In NDP, this forge identity is so easy since there
is no security and I can copy and paste all the content of your message. In
SeND, since there is signature, everybody thought either they need to break
the public key which is not easy if you choose a good one or break the SHA1
hash of CGA. Because of this problem in CGA, the attacker choose to break
SHA1 or find a collision but with his own different value. He even doesn't
need everytime to generate a public/private key. He can use any key(poor
value or high secure value) with any sizes once and just play with modifier.

This feature added to NDP which is similar to ARP. So,  It doesn't matter
that 3 bits is different since the other node can verify me and I pass the
verification process. In IPv4 they were doing this to find the MAC address
of the other nodes (ARP) so that they can start their communication. This is
the same feature in NDP. Or SeND.

I hope it is more understandable here. I will add it in SSAS draft. 

Smile,
Hosnieh

---

From: Dan Luedtke <[email-masked]>
Date: Fri, 22 Nov 2013 12:29:30 +0100

Hosnieh Rafiee wrote:
> Because of this problem in CGA, the attacker choose to break
> SHA1 or find a collision but with his own different value.
AFAIK one does not simply find a SHA-1 collision. According to [1] one
could reduce the complexity down to 2^60 which still seems a lot to
me.

> I will add it in SSAS draft.
Thanks!
I would like to see more about your attack since I still do not get it.

[1] http://2012.sharcs.org/slides/stevens.pdf

-- 
Dan Luedtke
http://www.danrl.de

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Fri, 22 Nov 2013 15:06:07 +0000

Hi Hosnieh,
I don't get it. The sec value is not ignored by the verifier. It is
extracted out of the prefix (step 5 in rfc3972/section 5) and used to
verify the 16*sec leftmost bits of hash2 (step 6). So if you were to use a
sec 0 and announce a sec of 3, your hash would not match. If you were
announcing a sec of 0, the address would not match.

I guess since you claim you can break a sec-level=1 CGA value (this is
what we currently can generate in a short enough time), the best is to
prove it. There are a few router implementations out there, pick up one,
and break it. If you don't have the router, provide a tool that someone
with a router could use.
This will certainly help your case.
Eric

On 21/11/13 21:09, "Hosnieh Rafiee" <[email-masked]> wrote:

>writing

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 22 Nov 2013 22:27:09 +0100

> AFAIK one does not simply find a SHA-1 collision. According to [1] one could
> reduce the complexity down to 2^60 which still seems a lot to me.

According to [1,2] maximum it is 2^80 for a full SHA1 (means 160 bits not only 59 or 61 bits). In CGA you're using only a part of SHA1 because of the interface ID. According to [3], this value is 2^60 for the full SHA1. 
Since we have only 3/8 of the SHA1 hashes in CGA, then this value  would be about 2^22.5.  

[1] https://www.schneier.com/blog/archives/2005/02/sha1_broken.html
[2] http://en.wikipedia.org/wiki/SHA-1 
[3] http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf

Smile,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 22 Nov 2013 22:37:38 +0100

Follow up,

> > could reduce the complexity down to 2^60 which still seems a lot to me.
> 
> According to [1,2] maximum it is 2^80 for a full SHA1 (means 160 bits not
only
> 59 or 61 bits). In CGA you're using only a part of SHA1 because of the
> interface ID. According to [3], this value is 2^60 for the full SHA1.
> Since we have only 3/8 of the SHA1 hashes in CGA, then this value  would
be
> about 2^22.5.

I do not need to match my value to the whole SHA1. If only 61 bits matches,
it is enough for me. This is why I said it is a security issue in CGA since
you're dealing with 1/3 of real strengthen of SHA1 algorithm.

Smile,
Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sat, 23 Nov 2013 08:12:28 +0000

> According to [1,2] maximum it is 2^80 for a full SHA1 (means 160 bits not only 59 or 61 bits). In CGA you're using only a part of SHA1 because of the 

Uh? 

The value 2^80 corresponds to a "birthday paradox" event. If the hash is 160 bits long, it takes 2^80 attempts to find two strings that hash to the same value. But this paradox does not apply in the scenario.

Then you mention a figure based on using just 60 bits, or 59. In that case, the birthday paradox says that you will find two strings that match to the same random IID in 2^29.5 attempts. Definitely not 22.5 -- you don't get to just "multiply the number of bits by 3/8."  You will also find two keys that have the same SSAS signature in 2^32 attempts. But if you want to find a string that matches a specific IID, you will need about 2^59 attempts, or 2^75 with SEC=1.

Now, we could indeed rework the CGA spec to allow for algorithm agility, and protect against a possible crypto analysis of SHA1. And use the u/g bits. Like any other effort related to CGA/SEND, the urgency of such efforts depends on the priority of the SEND scenario. 

The main attack observed to date is RA spoofing. CGA does not protect against that.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 23 Nov 2013 09:37:24 +0100

Hi Christian,

below...

>> Now, we could indeed rework the CGA spec to allow for algorithm agility, and protect against a possible crypto analysis of SHA1. And use the u/g bits. Like any other effort related to CGA/SEND, th…

This is already done, please see:

http://www.ietf.org/rfc/rfc4982.txt

Regards, marcelo

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 23 Nov 2013 11:39:50 +0100

> >> AFAIK one does not simply find a SHA-1 collision. According to [1]
> >> one could  reduce the complexity down to 2^60 which still seems a lot
to
> me.
> >
> > According to [1,2] maximum it is 2^80 for a full SHA1 (means 160 bits
> > not only 59 or 61 bits). In CGA you're using only a part of SHA1 because
of
> the interface ID. According to [3], this value is 2^60 for the full SHA1.
> be about 2^22.5.
> The value 2^80 corresponds to a "birthday paradox" event. If the hash is
160
> bits long, it takes 2^80 attempts to find two strings that hash to the
same
> value. But this paradox does not apply in the scenario.

I said about not exactly...

> Then you mention a figure based on using just 60 bits, or 59. In that
case, the
> birthday paradox says that you will find two strings that match to the
same
> random IID in 2^29.5 attempts. Definitely not 22.5 -- you don't get to
just
> "multiply the number of bits by 3/8."  You will also find two keys that
have the
> same SSAS signature in 2^32 attempts. But if you want to find a string
that
> matches a specific IID, you will need about 2^59 attempts, or 2^75 with
> SEC=1.

Sec value ignores so just consider sec value 0. It is not different what sec
value you use. Attacker only uses sec value 0 and sha1 not sha2 or n. 
Based on some suggestion, I am going to write an informational draft about
CGA possible attacks and just refer to it in SSAS.

> Now, we could indeed rework the CGA spec to allow for algorithm agility,
and
> protect against a possible crypto analysis of SHA1. And use the u/g bits.
Like
> any other effort related to CGA/SEND, the urgency of such efforts depends
on
> the priority of the SEND scenario.
> 
> The main attack observed to date is RA spoofing. CGA does not protect
against
> that.

I didn't talk about RA spoofing. I talked about NA and NS spoofing. I know
that without the RPKI either SSAS or CGA cannot protect RA spoofing.

Smile
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 23 Nov 2013 11:44:35 +0100

> and protect against a possible crypto analysis of SHA1. And use the u/g
bits.
> Like any other effort related to CGA/SEND, the urgency of such efforts
> depends on the priority of the SEND scenario.
> 

This specification cannot help CGA again since they use the 3 ignored bits. 
About the deployments. What I understood from one of implementers, he
worries about IPR of CGA. However, Christian said someone can sell it and it
is royalty free , etc. But  he  just do not like the idea of IPR on
something.  

Smile,
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Nov 2013 08:12:09 +1300

Marcelo,

On 23/11/2013 21:37, marcelo bagnulo braun wrote:
>>> Now, we could indeed rework the CGA spec to allow for algorithm
>>> agility, and protect against a possible crypto analysis of SHA1. And
>>> use the u/g bits. Like any other effort related to CGA/SEND, the
>>> urgency of such efforts depends on the priority of the SEND scenario.
> 

Should we mention this in  draft-ietf-6man-ug?
It's just in IETF Last Call so this is the last chance. Actually
the -ug draft liberates these bits for CGAs, in contrast to
the text in http://tools.ietf.org/html/rfc4982#section-4.1

   Brian

>>> against that.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 23 Nov 2013 20:43:06 +0100

Brian,
> It's just in IETF Last Call so this is the last chance. Actually the -ug draft liberates
> these bits for CGAs, in contrast to the text in
> http://tools.ietf.org/html/rfc4982#section-4.1
> 
>    Brian
> 
> >
If CGA does not use bits u and g for the original hash (a part of original hash), then the strengthen of CGA will be lower since they need to ignore these bits as well! If we considered 61 bits for CGA, it was because we also considered that these bits does not have any special meanings otherwise we have to consider 59 bits.
Anyway, the current problem and current attack is somewhere else and not these bits. These bits also cannot help much.

Smile,
Hosnieh

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 23 Nov 2013 21:01:15 +0100

El 23/11/13 11:44, Hosnieh Rafiee escribió:
> agility,

ok, this is my last attempt
SEC value is part of the address. Changing the SEc value changes the 
address, hence, if you manage to proof the onership of a CGA with a 
different SEC value you are in fact attacking a different address.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 23 Nov 2013 21:06:41 +0100

> >> Like any other effort related to CGA/SEND, the urgency of such
> >> efforts depends on the priority of the SEND scenario.
> >>
address,
> hence, if you manage to proof the onership of a CGA with a different SEC
> value you are in fact attacking a different address.
> 

You follow the NDP protocol specification since SeND only add 4 different
options and explains these options. Your node only check the target address
with his own address, if it is the same then he starts the verification on
the source address.
Target address = victim address
Source address= attacker different sec value cga address (only attacker
value is different in sec and not other parts)

Verification is successful since the node take the sec value from the source
address. I'm writing new draft about this attack. If still it is not clear,
I will try to explain it by pictures in that draft.

Smile,
Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sat, 23 Nov 2013 20:10:13 +0000

Hosnieh,

I have witnessed many discussions of CGA that stem from a misunderstanding of the SEC mechanism, and this is clearly one of them. I understand that you are very concerned with the CPU workload implied by the SEC mechanism, and thus very motivated to find an alternative. Regrettably, mathematics stand between you and your goal.

The fundamental problem with the CGA approach, or any similar mechanism, is that the 64 bits IID makes for a very weak proof. Whatever the mechanism, it will take only 2^64 attempts to break it. If we follow NIST recommendations, we should aim for 80 bits of proof today, and 128 bits soon.

The CGA design addresses this problem with the SEC mechanism. The idea is to embed both a signature and a puzzle in the IID. The signature's size is fixed, but the puzzle can be made arbitrarily complex. With the specific design picked for CGA, each successive increment of SEC is equivalent to adding 16 bits to the identifier size, allowing deployments to remain secure in the future. On the other hand, any design that fixes the proof size to a constant number, such as 64 bits, is guaranteed to become obsolete in a short time. In fact, one can argue that 64 bits is already insecure today.

The puzzle has indeed a price, and the price has to be paid at the time of address generation. It takes 2^16 attempts to find a key suitable for SEC=1, 2^32 for SEC=2, and so on. On a PC, the 2^16  attempts take a fraction of a second. On a mobile phone, with a slower processor, it arguably takes longer and depletes the battery somewhat. But there are probably ways to accelerate the process. Smartphone now have capable GPUs, the puzzle resolution can be trivially parallelized,  and thus could be accelerated using the smart phone's GPU.

The nice part of the CGA design is that it only requires the puzzle solving when the address is generated, not when address ownership is verified. That makes the design asymmetric: no cost for the communication partners, some cost at generation time for the owner, huge cost for the attacker. 

The SEC protection works even on the collision attack. Yes, it takes an average of 2^29.5 trials to find 2 keys and salts that hash to the same CGA address, regardless of the value of the SEC field. But with SEC=N, each trial has a cost of 2^(16*N), so the complexity of the collision attack is 2^(29.5 + 16*N). With a simple 64 bit proof and no SEC, the cost would be 2^32.

Any secure CGA variant will require some form of puzzle. 64  bits is just not long enough. It is also clear that there will have to be a way to make the puzzle more complex over time, as attacks just get better. For that reason, I am very skeptical of the SSAS design, which lacks any such puzzle and locks the proof to exactly 64 bits. I don't believe we should take a fundamentally insecure design as a working group item. On the other hand, your draft brings a number of clarifications on the SEND protocol work items, and that's very valuable. If you could split out that part as for example "draft-rafiee-6man-send," we would be very close to consensus.

-- Christian Huitema

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 25 Nov 2013 23:33:03 +0100

Hi Christian,

If you think I did not understand the meaning of sec values, please refer to
the vulnerability that I am talking in the following draft. Secondly, my
whole research during the last years was about CGA and SeND.

http://www.ietf.org/id/draft-rafiee-6man-cga-attack-00.txt 

> 
> > Sec value ignores so just consider sec value 0. It is not different
> > what sec value you use. Attacker only uses sec value 0 and sha1 not sha2
or
> n.
> > Based on some suggestion, I am going to write an informational draft
> > about CGA possible attacks and just refer to it in SSAS.
> 
> Hosnieh,
> 
> I have witnessed many discussions of CGA that stem from a misunderstanding
> of the SEC mechanism, and this is clearly one of them. I understand that
you
> are very concerned with the CPU workload implied by the SEC mechanism,
> and thus very motivated to find an alternative. Regrettably, mathematics
stand
> between you and your goal.
> 
> The fundamental problem with the CGA approach, or any similar mechanism,
> is that the 64 bits IID makes for a very weak proof. Whatever the
mechanism,
> it will take only 2^64 attempts to break it. If we follow NIST
recommendations,
> we should aim for 80 bits of proof today, and 128 bits soon.
> 
> The CGA design addresses this problem with the SEC mechanism. The idea is
> to embed both a signature and a puzzle in the IID. The signature's size is
fixed,
> but the puzzle can be made arbitrarily complex. With the specific design
> picked for CGA, each successive increment of SEC is equivalent to adding
16
> bits to the identifier size, allowing deployments to remain secure in the
> future. On the other hand, any design that fixes the proof size to a
constant
> number, such as 64 bits, is guaranteed to become obsolete in a short time.
In
> fact, one can argue that 64 bits is already insecure today.
> 
> The puzzle has indeed a price, and the price has to be paid at the time of
> address generation. It takes 2^16 attempts to find a key suitable for
SEC=1,
> 2^32 for SEC=2, and so on. On a PC, the 2^16  attempts take a fraction of
a
> second. On a mobile phone, with a slower processor, it arguably takes
longer
> and depletes the battery somewhat. But there are probably ways to
> accelerate the process. Smartphone now have capable GPUs, the puzzle
> resolution can be trivially parallelized,  and thus could be accelerated
using
> the smart phone's GPU.
> 
> The nice part of the CGA design is that it only requires the puzzle
solving when
> the address is generated, not when address ownership is verified. That
makes
> the design asymmetric: no cost for the communication partners, some cost
at
> generation time for the owner, huge cost for the attacker.
> 
> The SEC protection works even on the collision attack. Yes, it takes an
average
> of 2^29.5 trials to find 2 keys and salts that hash to the same CGA
address,
> regardless of the value of the SEC field. But with SEC=N, each trial has a
cost of
> 2^(16*N), so the complexity of the collision attack is 2^(29.5 + 16*N).
With a
> simple 64 bit proof and no SEC, the cost would be 2^32.
> 
> Any secure CGA variant will require some form of puzzle. 64  bits is just
not
> long enough. It is also clear that there will have to be a way to make the
puzzle
> more complex over time, as attacks just get better. For that reason, I am
very
> skeptical of the SSAS design, which lacks any such puzzle and locks the
proof
> to exactly 64 bits. I don't believe we should take a fundamentally
insecure
> design as a working group item. On the other hand, your draft brings a
> number of clarifications on the SEND protocol work items, and that's very
> valuable. If you could split out that part as for example
"draft-rafiee-6man-
> send," we would be very close to consensus.

The problem is that the section that you're talking about "such as keeping
public key in the node's cache, etc) is a part of SSAS to make it more
secure and give it the security of the whole public key without increasing
complexity or playing with its performance.  It is like CGA that sec value
is a part of that. It is how the algorithm works and it is what I thought to
find a higher security values as the people who suggested CGA thought about
sec value. The security of CGA algorithm is depends on the security of hash
functions. If we assume that the attack on sec value (the new
vulnerabilities that I wrote as a draft) does not exist, with SHA1 and sec
value 1, you need to do brute force attacks maximum on 2^(31.5+16)=2^47.5
now compare this value with SSAS. We all know that for immediate deployment
of CGA, the higher sec value will not be used since nobody are willing to
wait for 3 hours for sec value 2. 
With our current situation, SSAS is more secure and faster than CGA (even
sec value 1) and if also we consider the special cases where to also keep
the public key in node's neighboring cache, then CGA cannot be comparable
with SSAS.

Secondly, you said that CGA IPR is no problem but we also saw in this
mailinglist  from other implementers  that they do not like this CGA IPR,
either it is free for sale nor not. What I understood, they do not like
something have IPR and in most cases they are not being motivated to
implement CGA with its current situation.

Thirdly, To solve the current vulnerability of CGA, you need to change the
protocol specification while in SSAS these problems are considered
beforehand you do not need to do so.

Finally, I agree that local security is really important but the question is
that what is the cost providing it? SSAS can be used for all kinds of nodes
either with limited resources, for mobile phones, etc. But CGA is not
capable since it uses higher range of battery to generate just sec value 1.
We all know that in future most devices are going to be smaller in size and
unfortunately still the battery technology is not as advanced as it can
support the heavy computation, the one like CGA so again the SeND deployment
will be stopped because nobody is willing to use it on these devices while
SSAS is for all devices either with limited resources or without. Either you
are thinking about the current day or future, we need something simple but
secure. You can improve CGA but how much?? SSAS with two process provide a
high level of security that a node can expect but CGA might be able to do
the same with considering a high cost. 

-----------smile----------
Hosnieh

BTW, unfortunately I am unable to response your emails in the next 3
upcoming days since I have to attend a conference and travelling. Please
consider delay on my responses.