Subject: [netlmm] Review of draft-ietf-netlmm-threats-02

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 07 Aug 2006 09:48:13 -0700

Review of draft-ietf-netlmm-threats-02:

Summary:  I think the draft needs a revision before submission to the 
AD and IESG.  As written the document seems to be focused on where 
threats might occur.  It might be better to focus on the assets (what 
is that we are protecting), actors and the potential adversaries 
(where they may be present comes then, IMO).  Beyond that, I think 
the notion of Network Access Identity and Section 3.1 need some more 
thinking and follow-up writing.  Vidya and I have done some of that 
(shameless self-promotion I acknowledge, but seriously, whereas I was 
not impressed with our own text when I read it recently, but it still 
seems like a good start) in Section 6.1.3. (and Section 6 in general) 
of draft-vidya-netlmm-netmob-00.  Finally, parts of the document 
touches on mitigation techniques, but I found that aspect of it is 
done inconsistently.  Perhaps it might work better if there is a 
paragraph or more discussing ideas on mitigation in each section, 
titled as such even.

Detailed notes:

Currently the threats document talks about attacks on interfaces 
between the LMA and the MAG and the MAG and the MN, and then talks 
about on or off-path attacks.  My suggestion is to follow the 
approach outlines in issues 1-3 below.

Issue 1:  Discuss what needs to be protected.

Along the lines of the following, say ...

MAGs signal the attachment of authenticated MNs to LMAs.  Signaling 
between MAGs and LMAs need to be protected to i) ensure service 
continuity for MNs, ii) ensure traffic protection (need to address 
only the vulnerabilities that NETLMM itself causes; others as written 
in the I-D, fall within the realm of normal IP traffic protection), 
including making sure that NETLMM protocols and mechanisms do not 
result in traffic being sent to unauthorized entities.

Issue 2: List who the actors are and what they are supposed to do.

Again, along the lines of ...

MNs, MAGs, and LMAs.

MAGs are supposed to signal presence of authenticated mobiles (after 
also verifying that they are authorized to use their claimed IPv6 
address) to LMAs.

LMAs are supposed to accept such requests from authenticated MAGs, 
and make an attempt to verify the authorization of a MAG to signal 
the presence of a given MN.

Issue 3: Describe potential attackers

Say along the lines of ...

External attackers may target the protocols and mechanisms of NETLMM 
(can be mitigated with entity authentication) or launch DoS attacks.
The other threat is from "internal attackers" -- authenticated 
entities -- engaging in unauthorized or illegal behavior.  We can 
also call this compromise of MNs, MAGs and/or LMAs.  It might then be 
worthwhile to explain whether it is possible to recover from such 
comprises (for instance, unauthorized behavior of an LMA is hard, if 
not impossible to detect).

+++++++

The following set of issues (4-5) are on the MN to MAG interaction(s).

Issue 4: In Section 1.1, the definition of network access identity 
needs to be revised.  In fact, that term itself is overloaded in this 
draft and needs to be changed.  NAI is a well-known term and what's 
being defined in the threats document is a new notion and needs a new 
term.  The MAG is concerned about whether an MN is authorized to use 
its claimed IP address.

Issue 5: Section 3.1 needs a revision.

On paragraph 1:  I am not sure I fully understand paragraph 1.  My 
understanding is that NAI and AAA-assisted authentication only 
establish that the MN is authenticated for network access.  There is 
no guarantee that the MN is authorized to use its claimed IP 
address.  We need to define the problem/issue more clearly.

On mitigating that attack: IP address authorization is one 
technique.  Others include verification of whether the claimed IP 
address is unused at the MAG and subsequently at the LMA level.

On paragraph 2: My main observation is it needs clarification.  I am 
not sure binding between NAI and IP address is required.  I am also 
not sure what binding between the NAI and authentication keys 
associated with the IP address; please clarify.

Surely the binding needs in transit protection.  But, in addition to 
authentication verification, authorization for IP address use is also required.

In closing, the simplest solution is a binding between authenticated 
L2 address and the L3 address (perhaps being assigned via DHCP etc., 
after L2 authentication and the MAG observes the assignment and makes 
a note of it).  Of course the problem is quite complex in that as the 
MN moves, there need not be L2 authentication (with advances in EAP 
keying, it is plausible for an MN to re-use old authentication) and 
the new MAG will definitely not have the benefit of observing any 
DHCP assignments.

Address authorization using either SEND or a AAA-based solution is a 
possibility.

Finally, address verification (somewhat akin to the DAD process) at 
the MAG and at the LMA is another method.

++++++++++

Issue 6: Suggestion to discuss mitigation clearly after each attack.

Some of this is already there, it just needs to be clearly 
identified, but in some cases, mitigation techniques are not quite covered.

++++++

Hope that helps.

regards,
Lakshminath

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

---

From: Christian Vogt <[email-masked]>
Date: Mon, 07 Aug 2006 23:24:08 +0200

Hi Lakshminath,

thanks for the review!  My responses in-line...

> (where they may be present comes then, IMO).

It would certainly be valuable to talk about the assets first.  But the
draft should then get into the threats.  Getting into the threats
ensures that the draft is in line with related threats documents in the
mobility area, such as RFCs 3756 or 4225.

Would you agree to include a section at the beginning of the document
where we describe the assets on a general basis before the subsequent
sections get into the specifics?

>                                               Beyond that, I think
> of draft-vidya-netlmm-netmob-00.

Yes, we might need a different terminology for what is now the "network
access identity".  I refrained from using the acronym "NAI" for this
term, as "NAI" is already used widely for "network access identifier",
which is something different.  We used the term "mobile-node identity"
for some time.  How about going back to this wording?

>                                   Finally, parts of the document

Actually, the intent is to NOT touch on solutions in this document, but
stick to the threats.  I'll look through the draft again to make sure
that we eliminate any proposed solutions.  Which sections did you
particularly have in mind?

> the presence of a given MN.

Right, issues 1 and 2 would fit well into the introductory part of the
document.  We have to be careful, however, not to write a second NETLMM
Architecture or Requirements document. ;-)

> not impossible to detect).

Per se, compromise is a general threat and not NETLMM-specific.  But I
agree that, where the properties of the NETLMM architecture make the
potential damage of a compromise attack worse, this should be documented.

> term.  The MAG is concerned about whether an MN is authorized to use

Right, see my comment above.

> address.  We need to define the problem/issue more clearly.

Not sure what you mean.  The paragraph currently says:  "The network
access identity is conceptually independent of the mobile node's IP or
link-layer addresses."  Can you clarify, please?

> associated with the IP address; please clarify.

Ok.  The paragraph is a bit SEND-specific, I guess.  It should better
approach the issue like this:  The goal is to allow the MAG to securely
"deduce that the mobile node has handed over onto the MAG's access
link", so the MAG must be able to securely bind the MN's handoff
signaling messages (be it at L2 or L3) to the MN's network access identity.

This should already be sufficient; it does not matter at this point
whether the MAG uses the MN's IP address or something else for MN
authentication.

BTW, the paragraph is talking about the "network access identity", not
the "network access identifier" AKA NAI.  I agree this causes confusion.

> the MAG and at the LMA is another method.

Ok, but again:  The Threats document is scoped to not include possible
solutions.

But it's nonetheless worthwhile to think about them, of course. ;-)

> identified, but in some cases, mitigation techniques are not quite

Yes, but see my above remarks about solution proposals.

Thanks, Lakshminath.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)