Subject: [Mipshop] Review of draft-haddad-mipshop-fmipv6-auth-02

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 10 Nov 2006 14:34:36 -0800

Folks,

I promised a review of this document, so here goes.  I have to say 
that in its current shape it is hard to understand.  Let's start with 
a brief summary of my understanding of how things work (I am going to 
try to make the specification uniform and hope the authors adopt 
something like this in the future to make it easy to analyze the protocol):

The goal is to establish MN to AR key (handoff key) without having to 
use public key operations at each handoff.

There are two hash chains:

MN hash chain:  V0 <-- V1 <-- ...  <-- Vn;   Vi = h(Vi+1), where h is 
a cryptographic hash function.  Vn is randomly generated by the MN 
and is 128 bits in length.

[Q1]: Why is this 128 bits in length?  IPv6 address size?  We can 
truncate as needed, so that cannot be a consideration. Do you have 
HMAC-MD5 in mind for a MAC algorithm?  If so, why?

HV:                 HV0 --> HV1 --> ...           HVi+1 = h(HVi)

Step 1: MN generates the "MN hash chain"; it has to pick a value for 
n to do so.  The length of each value of the OWHC SHOULD be equal to 
128 bits and SHOULD be used together with another parameter to 
generate each nCoA interface identifier (IID).

Step 2: MN sends a RtSol message signed with a CGA, prior to 
handoff.  The RtSol message contains V0.  The message is not encrypted.

Step 3: AR sends HV0, 64 bits in length, encrypted with the MN's 
public key, in the RtAdv message. AR stores the MN's current IPv6 
address, V0 and HV0 in its cache.

Step 4: MN initiates fast handoff as follows:
    4.1.  Auto-configures nCoA, where nCoA(IID) = (first 64 bits of V1) XOR HV1

[Q2]: The draft says "first" 64 bits of
    4.2                                          defines HE = (second 
64 bits of V1) XOR HV1
The FBU contains the HE
The FBU is authenticated using V1

[Q3]:  There is something about including the result of the 
authentication in "BAD."  I am not sure what that means.

Step 5: The pAR receives the FBU and processes it as follows:
    5.1  Checks in MCE for pCoA
    5.2  Uses HV1 (computes HV0 --> HV1) and nCoA(IID)||HE to derive V1
    5.3  Uses V1 to verify the FBU

Step 6: The pAR sends the FBAck authenticated with V1 to the MN
    6.1 The pAR sends V1 and HV1 to nAR

Assuming I understood all of that correctly, here are the problems I 
have with all of this:

P1. I am concerned about "Note that we assume that all links between 
ARs are secure and the network access infrastructure can be 
trusted."   Please see Vidya's presentation on mobility threat models 
(presented at the INTarea meeting).

[Q4]: Is the assumption that there is a mesh of security associations 
between the ARs?

P2. The short key length is an issue, but that is fixable.  The key 
length MUST be based on the hash algorithm selection.

P3. V1 is used to compute the MAC (see 5.3 and 6).  However, h(V1) == 
V0 is already public.  That is a security hole.  My suggestion is to 
use a derived key for the MAC.

P4. The FBack is protected with a key known to the nAR.  The nAR can 
modify the FBack without detection.  The MN cannot trust the source 
of the message to be the claimed source: one of the consequences is 
that the lifetime of the binding can be modified.

P5. It appears that XOR is being used to "protect" the value 
V1.  That appears to be a substitution for encryption.  In any event, 
note that a passive attacker has access to XOR of the top 64 bits of 
V1 and the bottom 64 bits of V1.  That in effect reduces the key 
length to 64 bits.  If encryption is needed, let's use 
encryption.  But, there is a more fundamental problem, see P7.

P6. On address authorization, I guess the claim is the initial SEND 
procedure is the anchor to the entire security model.  That in itself 
is not a problem; however, I would like to see an analysis on the 
trust brokering this way.

P7. This is somewhat of an extension of P5.  In brief, the domino 
attack is an issue here.  If an AR is compromised, all the FMIP 
security brokered by that entity is compromised.  Specifically all 
the 64-bit HVs will be compromised.  Since FBUs contain V1 XOR'ed 
with HV, it is easy for an attacker who takes control over an AR has 
control over the network.

If this is seen as a non-problem, see Russ's security criteria and 
also Steve Bellovin's talk at the SAAG meeting in San Diego.

I'll stop here.  I will conclude saying that there are a number of 
fundamental problems to the proposed design of fmipv6 security in 
draft-haddad-mipshop-fmipv6-auth-02.  Perhaps, some rethinking might 
be in order.

regards,
Lakshminath

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 29 Nov 2006 13:17:44 +0200 (EET)

Hi,

Thanks for your review. Note that you rushed a bit too fast to your
conclusion.
Note that am not sure that you have fully understood the proposal in order
to review it but this does not seem a problem...

So let's start:

> (presented at the INTarea meeting).

=> We assume that when a service such as FMIPv6 requires a close
collaboration between ARs then the links between them are secure.

> [Q4]: Is the assumption that there is a mesh of security associations

=> If I understand correctly what you mean by mesh then the answer is NO

> length MUST be based on the hash algorithm selection.

=> the key lenght is not an issue. 128 bits is enough.

> use a derived key for the MAC.

=> Can you please explain why it is a security hole?

Regards,

Wassim H.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 29 Nov 2006 04:09:13 -0800

>to review it but this does not seem a problem...

Let us not get into this kind of debate please.  I don't have the 
time or energy for it.

>collaboration between ARs then the links between them are secure.

Well, this is not practical and hence not acceptable.  Actually, let 
me ask you write your full threat model and share with the group.

>=> If I understand correctly what you mean by mesh then the answer is NO

I can see that there is no need for SAs between ARs if you assume the 
links are all secure.  Like I said above, that is not practical.

>=> the key lenght is not an issue. 128 bits is enough.

Wassim, we don't make these decisions piecemeal.  Like I note above, 
there is a rule, let's follow it.  Let's not make up cryptographic 
best practices as we go.

>=> Can you please explain why it is a security hole?

Please read the TESLA RFC.

BTW, what happened to the rest of the review?

best,
Lakshminath

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 29 Nov 2006 16:55:35 +0200 (EET)

> me ask you write your full threat model and share with the group.

=> What is not practical?? Is establishing SAs between ARs not practical?!

> links are all secure.  Like I said above, that is not practical.

=> Oh sorry! I thought you were hinting to something else. We assume there
are SAs.

> Please read the TESLA RFC.

=> Section 3.3 says: The last key chain K_0 will be signed by the sender,
and all receivers will verify the signature with the public key of the
signer.

Is my reading correct?

> BTW, what happened to the rest of the review?

=> just give me more time please.

Regards,

Wassim H.