idnits 2.17.1 draft-perkins-mip4-authreqd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '...on Reply messages MUST contain a valid...' RFC 2119 keyword, line 101: '...tication Extension MUST be the same as...' RFC 2119 keyword, line 107: '... Mobile Node MUST silently discard t...' RFC 2119 keyword, line 108: '...rd", the mobile node MUST NOT use that...' RFC 2119 keyword, line 115: '... node MAY be configured especially F...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2009) is 5310 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group C. Perkins 3 Internet-Draft WiChorus Inc. 4 Expires: April 15, 2010 October 12, 2009 6 Authentication Mandate for All Registration Reply Messages 7 draft-perkins-mip4-authreqd-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 15, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 Some implementations of Mobile IP home agents have been observed to 46 supply zero authentication data when sending a Registration Reply to 47 the mobile node that contains rejection code 131 (Mobile Node Failed 48 Authentication). This creates a vulnerability whereby a mobile node 49 could be denied service from its home agent, and thus lose 50 connectivity to the Internet even though mobile node and home agent 51 were otherwise functioning properly. 53 1. Introduction 55 When a mobile node sends a Registration Request to its home agent, it 56 expects a Registration Reply with a return code of 0 or 1. Other 57 return codes indicate that the registration was unsuccessful. All 58 registration messages, whether indicating success or failure, are 59 expected to be equipped with authentication data so that the mobile 60 node and home agent can verify that the information in the 61 registration messages is really supplied by the home agent or the 62 mobile node respectively. 64 This is true even for registration messages that indicate failure. A 65 mobile node should be able to verify that Registration Reply messages 66 containing a failure code are really generated by its home agent. 67 Otherwise, the mobile node might unnecessarily take the actions 68 corresponding to a failure to register, perhaps causing at least a 69 temporary disconnection. Even if the mobile node does retransmit the 70 Registration Reply message, the only result might be to receive 71 shortly thereafter yet another bogus Registration Reply message with 72 the same rejection code. Soon enough, the mobile node will give up 73 the attempt to register at its current care-of address, even though 74 the home agent had indeed registered the care-of address and sent a 75 Registration Reply message indicating success. 77 In the specific case of rejection Code 131, there is a likelihood 78 that the mobile node's security association with its home agent needs 79 to be refreshed, if the authentication data supplied with the 80 Registration Request message were not correct. It would be an 81 unfortunate error if a malicious agent were able to trigger re- 82 establishment of the mobile node's Mobility Security Association. 83 Since, for Code 131, there are no retries specified in the Mobile-IP 84 protocol specification [1]. a single malicious packet could trigger 85 the loss of even a newly established and valid Mobility Security 86 Association between the mobile node and the home agent. Worse, such 87 an action could trigger an exception condition in the home domain, if 88 the home domain policy excluded too-frequent attempts for the 89 establishment of such security associations. 91 2. Mobile Node Handling for Unauthenticated Registration Replies 93 We propose that all Registration Reply messages MUST contain a valid 94 Mobile-Home Authentication Extension, with nonzero authentication 95 data generated according to the security algorithm indicated by the 96 SPI present in the Authentication extension. This is required 97 whether or not the Mobile Node is identified putely by its IP 98 address, or if the Mobile Node NAI extension is also supplied. 100 The registration message data protected by the Authentication Data in 101 the Mobile-Home Authentication Extension MUST be the same as 102 specified in [1]. 104 As specified in section 3.6.2.1 of [1], if a Mobile Node receives a 105 Registration Reply message that does not contain a Mobile-Home 106 Authentication Extension, or one with zero authentication data, the 107 Mobile Node MUST silently discard that packet. According to the 108 meaning of "silently discard", the mobile node MUST NOT use that 109 packet as a trigger for retransmitting the Registration Request 110 message. 112 3. Security Parameters Index 114 A mobility security association between the Home Agent and the Mobile 115 node MAY be configured especially For the purpose of supplying the 116 authentication data to the Mobile Node when a Registration Request is 117 rejected, This alternative security association MAY use a default SPI 118 number, or any other different SPI that may be convenient. This may 119 also include an SPI in the range of well-known SPI numbers, but not 120 any reserved value for the SPI. 122 4. Foreign Agent Handling for Unauthenticated Registration Replies 124 Similarly, in accordance with section 3.7.3.1 of [1], when a Foreign 125 Agent has a security association with a Home Agent, each Registration 126 Reply from that home agent MUST contain a Foreign-Home Authentication 127 Extension with nonzero authentication data. Otherwise, when a 128 Foreign Agent has a security association with a Home Agent, that 129 Registration Reply MUST be silently discarded. 131 5. Security Considerations 133 This document identifies a security exposure that might disrupt a 134 mobile node's ability to connect to the Internet, and proposes a 135 solution to eliminate this exposure. It does not create any new 136 security exposures. 138 6. Normative References 140 [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 141 August 2002. 143 Author's Address 145 Charles E. Perkins 146 WiChorus Inc. 147 3590 N. 1st Street, Suite 300 148 San Jose CA 95134 149 USA 151 Email: charliep@computer.org