Subject: [netlmm] #129: Fundamental security problem not addressed by REQ

From: netlmm <[email-masked]>
Date: Tue, 12 Sep 2006 16:33:21 -0000

#129: Fundamental security problem not addressed by REQ
------------------------------------------+---------------------------------
 Reporter:  [email-masked]      |       Owner:  [email-masked]
     Type:  defect                        |      Status:  new                     
 Priority:  major                         |   Milestone:  milestone4              
Component:  draft-ietf-netlmm-nohost-req  |     Version:  2.0                     
 Keywords:  REQ draft                     |  
------------------------------------------+---------------------------------
 Eric Rescorla says:

 > There's a fundamental security question that isn't addressed in any
 > of these documents as far as I can tell. What's the expected
 > threat/deployment model. In particular, is it expected that
 > people should be able to roam across administrative domains?
 > It seems clear from S 2 and 3 of the -threats document that
 > rogue elements can do very large amounts of damage. Is this
 > a case where the elements might be mutually suspicious? If so,
 > that seems to imply much more strict security constraints.
 >

-- 
Ticket URL: <http://tools.ietf.org/wg/netlmm/trac/ticket/129>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: netlmm <[email-masked]>
Date: Tue, 12 Sep 2006 16:45:39 -0000

#129: Fundamental security problem not addressed by REQ
-------------------------------------------+--------------------------------
  Reporter:  [email-masked]      |       Owner:  [email-masked]
      Type:  defect                        |      Status:  closed                  
  Priority:  major                         |   Milestone:  milestone4              
 Component:  draft-ietf-netlmm-nohost-req  |     Version:  2.0                     
Resolution:  fixed                         |    Keywords:  REQ draft               
-------------------------------------------+--------------------------------
Changes (by [email-masked]):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Goal #6 (now #5 due to a renumbering described in a different issue
 record) was not clear about the requirement for security in NETLMM. This
 has been changed. The modified text is below, and is very specific about
 what the expectation is w.r.t. NETLMM host to network security. In
 addition, the text in the gap analysis appendix has been modified to
 describe how existing protocols deal with security. In the case of MIPv6
 and HMIP, there is in addition text in the appendix describing the risk of
 DoS attack from known global addresses for the HA and MAP, which doesn't
 occur with NETLMM.

 ---------------------------------------------------
 3.5     Simplify Mobile Node Mobility Management Security by Deriving from
 IP Network Access Security (Goal #5)

 Localized mobility management protocols that have signaling between the
 mobile node and network require an additional security association between
 the mobile node and the network entity that is the target of the
 signaling, beyond the authentication and authorization required for simple
 network access. Establishing a security association specifically for
 localized mobility service in a roaming situation may prove difficult,
 because provisioning a mobile node with security credentials for
 authenticating and authorizing localized mobility service in each roaming
 partner's network may be unrealistic from a deployment perspective.
 Reducing the complexity of mobile node to network security for localized
 mobility management can therefore reduce barriers to deployment.

 In NETLMM, the network (specifically the MAG) derives the occurrence of a
 mobility event requiring a routing update for a mobile node from link
 layer handover signaling or IP layer movement detection signaling. This
 information is used to update routing for the mobile node. The handover or
 movement detection signaling must provide the network with proper
 authentication and authorization so that the network can definitively
 identify the mobile node and determine its authorization. The
 authorization may be at the IP level, for example using something like
 SEND [3], or it may be tied to the original network access authentication
 and link layer authorization for handover. Some link layers, especially
 cellular protocols, feature full support and strong security for handover
 at the link level, and require no IP support for handover. If such link
 security is not available, however, then it must be provided at the IP
 level. If NETLMM security is tied to link layer authentication and
 authorization for network access, then such authentication and
 authorization is required on handover in order that the mobile node can be
 definitively identified. Security threats to the NETLMM protocol are
 discussed in [2].

 The goal is that security for NETLMM mobile node mobility management
 should derive from IP network access security, such as SEND or network
 access authentication, and not require any additional security
 associations or additional signaling between the mobile node and the
 network.

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/129>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm