idnits 2.17.1 draft-perkins-mobileip-spi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 116: '...rity association SHOULD NOT be used fo...' RFC 2119 keyword, line 125: '...ld rolls over, the node SHOULD NOT use...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3220 (ref. '3') (Obsoleted by RFC 3344) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 15 June 2002 Vijay Devarapalli 4 Nokia Research Center 6 SPI Option for Mobile IPv6 Authentication Data Option 7 draft-perkins-mobileip-spi-00.txt 9 Status of This Memo 11 This document is a submission by the IETF Mobile IP Working Group 12 Working Group of the Internet Engineering Task Force (IETF). 13 Comments should be submitted to the mobile-ip@sunroof.eng.sun.com 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document specifies a new SPI (Security Parameters Index) 37 option for use with the Binding Authorization Data option. The 38 new SPI option allows for selection of a particular mobility 39 security association to handle the case when several such security 40 associations may exist between nodes exchanging messages containing 41 a mobility header requiring authorization. The SPI value may be set 42 during manual configuration of the security association between two 43 nodes, for example a mobile node and its home agent, or between a 44 mobile node and a favored correspondent node. 46 1. Introduction 48 This document specifies a new SPI (Security Parameters Index) option 49 for use with the Binding Authorization Data option which has been 50 defined for use with Mobile IPv6 [2]. The new SPI option allows for 51 selection of a particular mobility security association to handle 52 the case when several such security associations may exist between 53 nodes exchanging messages containing a mobility header requiring 54 authorization. The SPI value may be set during manual configuration 55 of the security association between two nodes, for example a mobile 56 node and its home agent, or between a mobile node and a favored 57 correspondent node. This use of SPI closely models the existing 58 practice for home agents and mobile nodes using Mobile IP for 59 IPv4 [3]. 61 2. Terminology 63 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [1]. This 66 section defines other terminology used that is not already defined 67 in [2]. 69 SPI 71 An index identifying a security association between a pair 72 of nodes among those available in the Mobility Security 73 Association. 75 3. SPI Option Format 77 The format of the SPI option conforms to the general format specified 78 for Mobile IPv6 [2]. 80 0 1 2 3 81 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Type | Length | SPI | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 Type 88 90 Length 92 2 94 SPI 96 A 16-bit value specifying which SPI is to be used for verifying 97 the authorization data in the Binding Authorization Data option 99 4. Operation and Use of the SPI Option 101 A mobile node may have established one or more mobility security 102 associations with the sender or intended receiver of a message 103 containing a Binding Authorization Data option (which is present 104 along with a Mobility Header). In such cases, the SPI option can be 105 used to identify the particular security association which should be 106 used to verify the authorization data in the Binding Authorization 107 Data option. 109 The option is required to occur immediately before the Binding 110 Authorization Data option, to simplify processing of the latter 111 option. 113 Replay protection can be assured by the sending node in several 114 ways, each affording longer effective use of the same security 115 association identified by the SPI. When replay protection can no 116 longer be provided, the security association SHOULD NOT be used for 117 authorizing any future mobility header operations. See section 7 for 118 more information. 120 Replay protection can be assured in either of the following ways: 122 - The node can make use of the sequence # field of the Binding 123 Update or Binding Acknownledgement message. This allow up 124 to 65,535 uses of the same security association. When the 125 sequence number field rolls over, the node SHOULD NOT use 126 the same security association for future Binding Updates or 127 Acknowledgements. 129 - The node can keep a hash table of values corresponding to the 130 leading bits of the authorization data. The hash buckets can 131 contain an arbitrary number of (longer!) values for specific 132 instances of the Authorization data used in previous messages. 134 The latter method works for all messages using Mobility Headers, not 135 just the messages which have a Sequence number field. Furthermore, 136 it works to check arbitrarily many messages against replay attempts, 137 at the cost of using more memory than the simple sequence # counting 138 method. 140 The SPI feature is intended to be used just as the analogous feature 141 for Mobile IPv4 is used today. To that end, the first 255 values 142 are reserved, and not to be used when carrying out the operations in 143 section 5. 145 5. Manual Configuration 147 The SPI option can be used to facilitate manual configuration of 148 security associations between a mobile node and its home agent. 149 For each security association, a configuration manager has to 150 establish the information about the secret key and the cryptographic 151 algorithm to be used to create the authorization data in the Binding 152 Authorization Data option. The SPI option is to be used to allow 153 the mobile node and home agent node to specify which of the security 154 associations is to be used for the authorization data send with the 155 binding message in the mobility header. 157 Likewise, specialized correspondent nodes (e.g., servers with 158 a special relationship with the mobile node) could have manual 159 configuration of security associations with the mobile node, each 160 with varying degrees of strength. The SPI option is to be used to 161 allow the mobile node and correspondent node to specify which of the 162 security associations is to be used for the authorization data. 164 While nothing in this specification depends on AAA, a great deal of 165 work has been expended to develop methods by which AAA can help to 166 establish security associations between mobile nodes and mobility 167 agents in Mobile IPv4. It is expected that similar methods will 168 be developed for Mobile IPv6. The SPI option will help the use of 169 such methods by enabling them to make better use of the Binding 170 Authorization Data option. 172 6. IANA Considerations 174 This specification reserves one number for the SPI option(see 175 section 3) from the space of numbers for options defined in the 176 specification for Mobile IPv6 [2]. 178 7. Security Considerations 180 The option in this document allows for additional security 181 associations to be used for authorizing Mobile IPv6 binding messages. 182 This will encourage the use of security methods that are stronger 183 than the existing Return Routability methods. 185 If the same security association is used after the replay protection 186 method is no longer guaranteed to work, then an attacker could 187 attempt to replay one of its stored messages and the receiver would 188 not have a good way to to detect the attack. Thus, it is strongly 189 recommended that the security association be recreated (at least 190 by re-keying) before the replay protection method is no longer 191 guaranteed to offer the desired protection. 193 References 195 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 196 Levels. Request for Comments (Best Current Practice) 2119, 197 Internet Engineering Task Force, March 1997. 199 [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 200 progress). Internet Draft, Internet Engineering Task Force, 201 March 2001. 203 [3] C. Perkins. IP Mobility Support. Request for Comments (Proposed 204 Standard) 3220, Internet Engineering Task Force, December 2001. 206 Addresses 208 The working group can be contacted via the current chairs: 210 Basavaraj Patil Phil Roberts 211 Nokia Megisto Corp. 212 6000 Connection Dr. Suite 120 213 20251 Century Blvd 214 Irving, TX. 75039 Germantown MD 20874 215 USA USA 216 Phone: +1 972-894-6709 Phone: +1 847-202-9314 217 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 219 Questions about this memo can also be directed to the authors: 221 Charles E. Perkins Vijay Devarapalli 222 Communications Systems Lab Communications Systems Lab 223 Nokia Research Center Nokia Research Center 224 313 Fairchild Drive 313 Fairchild Drive 226 Mountain View, California 94043 Mountain View, California 94043 227 USA USA 228 Phone: +1-650 625-2986 Phone: +1-650 625-2320 229 Fax: +1 650 625-2502 Fax: +1 650 625-2502 230 EMail: charliep@iprg.nokia.com EMail: vijayd@iprg.nokia.com