idnits 2.17.1 draft-murphy-ospf-signature-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 40 has weird spacing: '...nerable becau...' -- 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.) -- The document date (March 1995) is 10606 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 1583 (ref. '1') (Obsoleted by RFC 2178) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sandra Murphy 3 INTERNET DRAFT Madelyn Badger 4 draft-murphy-ospf-signature-00.txt Trusted Information Systems 5 March 1995 7 OSPF with Digital Signatures 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet Drafts as reference material or to cite 19 them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow 23 Directories on ds.internic.net (US East Coast), venera.isi.edu (US West 24 Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 26 Abstract 28 This memo describes the extensions to OSPF required to add digital 29 signature authentication to Link State data. The augmented design is 30 backward compatible with standard OSPF V2 [1]. Routers supporting 31 digital signatures will be able to provide authenticated routing as an 32 IP TOS or by source routing. 34 1. Introduction 36 There is a need for greater security in routing protocols. OSPF 37 currently provides "simple password" authentication where the password 38 travels "in the clear", and there is work in progress to provide keyed 39 MD5 authentication for OSPF protocol packets. The simple password 40 authentication is vulnerable because any listener can discover and use 41 the password. MD5 authentication is very useful for protocol packets 42 between neighbors, but does not address authentication of routing data 43 from its source through multiple hops to its eventual destination. 45 The basic idea of this proposal is to add digital signatures to OSPF LSA 46 data, and to recommend the use of a neighbor-to-neighbor authentication 47 algorithm (like keyed MD5) to protect other protocol exchanges. Link 48 State information will be signed by the originator of that information 49 and the signature will stay with the data in its travels via OSPF 50 flooding. This will provide end-to-end integrity and authentication for 51 LSA data. Routers providing digital signatures will be "authenticated 52 routers", and can be mixed with non-authenticated routers. An 53 application will be able to specify authenticated routing as an IP TOS, 54 and have packets forwarded accordingly. 56 A digital signature attached to an LSA by the source router provides 57 assurance that the data really does come from the advertising router. 58 It will insure that the data has not been modified in transit. In the 59 case where incorrect routing data is distributed by a faulty router, the 60 signature provides a way to trace the problem to its source. 62 Digital signatures for OSPF LSAs can be implemented with the following 63 major elements: 65 (1) Add support for a digital signature algorithm in authenticated 66 routers. 68 (2) Support a signed version of all routing information LSAs 70 (3) Support a new LSA: Router Public Key LSA 72 (4) Add an IP TOS for Authenticated Routing. 74 (5) Support TOS routing and forwarding in Authenticated Routers. 76 (6) Implement a mechanism for Key Certification and Distribution. 78 (7) A router will need to be configured with, or supplied with: 80 Public Key of Trusted Entity 81 The following can be for the router or per area if needed: 83 Router Private Key 84 Router Public Key, Id and Role certified by a Trusted 85 Entity 86 Signature Algorithm Information (type, parameters) 87 Hash Algorithm Information (type, parameters) 88 Environment flag (authenticated, non-authenticated, mixed) 90 2. Overview 92 Authenticated OSPF routers perform all the normal functions of a 93 standard OSPF router. In addition to the standard functionality, an 94 authenticated OSPF router generates signed routing information LSAs, 95 sends a new key information LSA, manages key and signature algorithm 96 information, and verifies signatures received. An authenticated OSPF 97 router must support TOS routing, specifically for TOS=authenticated 98 routing. 100 Authenticated OSPF routers can send out a signed and an unsigned version 101 of each LSA. The unsigned version is for backward compatibility with 102 non-authenticated routers. The signed LSAs contain the same routing 103 information, and are flooded, aged, and used in routing calculation like 104 unsigned LSAs. There is an environment flag per area that tells the 105 router whether to send signed LSAs, unsigned LSAs, or both. If all 106 routers in an AS are authenticated then only signed LSAs must be sent. 107 If authentication is turned off, then only unsigned LSAs are sent. If 108 authenticated and non-authenticated routers are mixed in an area, then 109 signed and unsigned versions of the same LSAs must be sent out. This 110 design works best if all the routers in an AS are authenticated, but it 111 can still be useful in a mixed environment. 113 Standard OSPF routers will discard the unfamiliar LSAs containing key 114 and signature data, so, in a mixed environment there will be "islands" 115 of authenticated routers. Authenticated routing will function on each 116 "island", which might be an OSPF area, as follows. Each authenticated 117 router builds an SPF tree for TOS=Authenticated Routing, using metrics 118 from the signed LSAs, and stores the paths that result in the routing 119 table. To take advantage of the routes supplied, an application must 120 set the TOS=Authenticated Routing bit in the IP header, and the IP 121 forwarding code must use the TOS routes from the routing table. 122 Alternatively, source routes could be generated using the TOS routing 123 information. TOS 0 routing will function normally throughout the AS. 125 3. LSA Processing 127 The router sends a Router Public Key LSA in the same manner as all other 128 LSAs. This LSA contains the router's public key and some identifying 129 information that has been certified by a trusted entity. The router 130 public key is used to verify signatures produced by this router. When 131 forming an adjacency or synchronizing databases, the Router Public Key 132 LSAs should be sent/requested before other LSAs. The Router Public Key 133 LSA is sent at intervals like all other LSAs, and it is sent immediately 134 if a router obtains a new key to distribute. 136 When the router receives a Router Public Key LSA (with a valid 137 signature), it must store the key information for use in verifying 138 signatures from the advertising router. For every authenticated router 139 that this router is in contact with, there may be one or more Router 140 Public Key LSAs stored at any given time. The LSAs are differentiated 141 by the Key Id stored in the Link State Id field of the LSA Header. The 142 current key is defined as the key with the longest time remaining to 143 expiration. A key can be flushed from routing tables by a properly 144 signed MaxAge version of the Router Public Key LSA sent by the 145 originating router (see section on MaxAge). If the Router Public Key 146 LSA ages to MaxAge before the key reaches its expiration time, the key 147 should be retained in the database until it expires or is flushed by the 148 originating router. 150 When the router builds a routing information LSA, in a mixed environment 151 it must build a signed and an unsigned version of the LSA. The unsigned 152 version of the LSA will be the standard OSPF V2 [1] LSA. All LSAs will 153 have the TOS capable bit set in the OSPF options field. The signed LSAs 154 will have the top bit of the LSA type field set to indicate the presence 155 of a signature, the metrics (if present) will include TOS = 156 Authenticated Routing, and the LSA will have signature information and a 157 signature in it. The signature is computed on the LSA header and data, 158 starting with the Options field and continuing to the end of the message 159 (except in the case of MaxAge LSAs - see section on MaxAge). 161 When the router receives a routing information LSA, the type field is 162 examined. Unsigned LSAs are handled in the standard OSPF V2 [1] way. 163 When a signed LSA is received, the signature should be verified using 164 the current public key of the advertising router. If there is no key 165 stored for the advertising router, then the signed LSA must be 166 discarded. If the signature verification fails the LSA must be 167 discarded. If the signature verifies, then the signed LSA is stored for 168 use in the routing calculations. The TOS = Authenticated Routing 169 metrics in the signed LSA will be used in the construction of a SPF tree 170 for this TOS, and these routes will be put into the OSPF routing table. 172 4. LSA formats 174 4.1. Options field 176 There is an Options Field in LSAs, Hellos, and Database Description 177 Packets. This field describes the optional capabilities supported by 178 the advertising OSPF router. The TOS bit must be set in the Options 179 field of all LSAs/packets sent by an Authenticated Router. 181 4.2. LSA Type Field 183 This proposal requires a new LSA type for the Router Public Key LSA. 185 The top bit of the LSA Type field will be set to indicate that an LSA is 186 signed. This creates a new signed LSA type for each existing type. 188 4.3. Router Public Key LSA 190 This LSA is the vehicle for an authenticated router to provide its 191 public key to other authenticated routers. This public key is what 192 other routers use to verify the signatures created by this router. A 193 Router Public Key LSA will be communicated in the usual database 194 exchange and flooding mechanisms. This LSA contains the Public Key of 195 the advertising router and a certification of that key by a Trusted 196 Entity. Certification is: the (Router Id, Role and Public Key) signed 197 with the Trusted Entity's private key. This signature can be verified 198 using the Trusted Entity's public key which must be known to all 199 authenticated routers. The regular period for sending this LSA should 200 be LSRefreshTime. The Router Public Key LSA will also be sent when key 201 management provides a new key for distribution. 203 ROUTER PUBLIC KEY LSA 204 +------------------------------------+ 205 | LSA Header(standard) | 206 | LS AGE Options LS Type=X | 207 | Link State Id = Key Id | 208 | Advertising Router = Router Id | 209 | LS Sequence Number | 210 | LS Checksum Length | 211 +------------------------------------+ 212 | SigType HashAlgID Key Size | 213 | Cert Length Sig Length | 214 | Router Id | 215 | Router Role (R, ABR, ASBR) | 216 | Router Public Key | 217 | Key Expiration Time | 218 | Certification | 219 | Signature | 220 +------------------------------------+ 222 The LSA Header is standard as defined in RFC 1583. 223 LS Type: X for Router Public Key LSA. Top bit set to indicate a 224 signed LSA. 225 LS ID: Key Id. This is the Identifier of the Router Public Key. 227 This Id will differentiate between multiple keys 228 supplied by the same router. 229 Advertising Router: Router's OSPF Router Id. 230 Length: total length of the LSA. 231 Sig Type: Signature algorithm to be used. Identifies the type of 232 the Router Public Key, the Certification, and the 233 Signature. Currently defined values = RSA(1), DSA(2). 234 HashAlg Id: Identifies the hash algorithm used to hash data 235 prior to signing. Identifies the hash to use with the 236 given key, the hash used to process Router information 237 for the Certification, and that used on this message 238 before signing. Currently defined values = MD5(1), 239 SHA(2) 240 Key Size: the size in bits of the Router Public Key. 241 (Note: the length in bytes of the Router Public Key 242 field can be computed from the key size.) 243 Certification Length: the length of the Certification field. 244 Signature Length: the length of the Signature field. 245 Router Id: Same OSPF router Id given in the header 246 Router Role: Router (R=1), Area Border Router (ABR=2), 247 Autonomous System Border Router (ASBR=3). 248 Router Public Key: A key that can be used by other routers to 249 verify the signatures produced by this router. 250 Key Expiration Time: The time by which the Router Public Key 251 should be replaced by a newer key value. 252 Certification: The trusted Server's signature of the Router Id, 253 Role, Expiration Time and Public Key given above. 254 Signature: The advertising router signs this message using it's 255 private key. This signature can be verified using the 256 enclosed certified public key. The signature covers the 257 message starting with the options field when LS Age is 258 not MaxAge. When LS AGE = MaxAge, the signature starts 259 with the Age field. (See the section on MaxAge). 261 4.4. Signed LSA 263 A signed LSA can be any OSPF LSA with a digital signature attached. The 264 top bit of the LSA Type field is set to indicate the presence of a 265 signature. A signature type and offset follow the LSA header. The 266 metrics in the LSA must include metrics for TOS = Authenticated Routing. 267 The actual signature follows the LSA Data. Signed LSAs are sent via 268 OSPF reliable flooding, like other LSAs. 270 SIGNED LSA 271 +------------------------------------+ 272 | LSA Header(standard) | 273 | LS AGE Options LS Type | 274 | Link State Id | 275 | Advertising Router = Router Id | 276 | LS Sequence Number | 277 | LS Checksum Length | 278 +------------------------------------+ 279 | SigType HashAlgId Key Size | 280 | Key Id Sig Offset | 281 : ... : 282 / LSA Data / 283 : ... : 284 | Signature | 285 +------------------------------------+ 287 The LSA Header format is standard as defined in RFC 1583. 288 LS Type: Standard LSA type + the top bit set to indicate the 289 presence of a signature 290 Sig Type: Signature algorithm to be used. Currently defined 291 values = RSA(1), DSA(2). 292 Hash Alg Id: Identifies the hash algorithm used. 293 Currently defined values = MD5(1), SHA(2) 294 Key Size: the size in bits of the Router Public Key. 295 Key ID = This is the Identifier of the router public/private key 296 pair. This Id will differentiate between multiple keys 297 supplied by the same router. 298 Sig Offset: The offset from the front of the header to the start 299 of the signature. 300 Signature: Digital signature of the signed LSA from the start of 301 the LSA Header Options field (except for MaxAge LSAs - 302 see section on MaxAge) to the end of the LSA data. 304 5. Processing Max Age 306 The age field in the OSPF LSA header is used to keep track of how long a 307 given LSA has been in the system. This, along with the sequence number, 308 allows a router to decide which LSAs are current, and allows old or 309 inaccurate LSAs to be flushed from the system. When the age field 310 reaches MaxAge, routers stop using the LSA for routing, and they flood 311 the MaxAge LSA to make sure that all routers stop using this LSA. When 312 a router fails, eventually its LSAs age out of the system in this way. 313 If a router wants to flush its own LSA from the system it can set the 314 age to MaxAge and flood the LSA. 316 This element of the protocol is difficult to protect using digital 317 signatures. The age field cannot generally be included in the 318 signature, because it must be updated by routers other than the 319 originating router. For the same reason, the age field is not included 320 in the checksum computation. The age field should be protected, because 321 if a faulty router started to age out other router's LSAs, it would 322 effectively deny service to those other routers. 324 To protect the age field, the signature should include the age field 325 when, and only when, the age field value is MaxAge. Verification of the 326 signature on a signed LSA should include the age field when, and only 327 when, the age field value is MaxAge. 329 The processing of MaxAge will also change slightly for authenticated 330 routers. An LSA will be removed from any router's Link State Database 331 in one of two ways: 1) the router receives a version of the LSA with the 332 age field set to MaxAge, or 2) the LSA incrementally reaches MaxAge 333 while it is stored by the router. A received LSA with the age field set 334 to MaxAge could have been sent by the originating router or by any other 335 router which had aged the LSA to MaxAge in its database. But for 336 authenticated routers, only the MaxAge LSA sent by the originating 337 router would be recognized as valid, as only the originating router can 338 generate a signature covering the age field. A signed LSA with age 339 MaxAge flooded by a router that is not the LSA's originating router will 340 be ignored by all authenticated routers. In this way, the originating 341 authenticated router can prematurely age an LSA, but other routers 342 cannot. It is also true that a non-originating router's flooding of 343 signed LSAs that have reached MaxAge in its database will be ignored. 344 If an authenticated router goes down, its signed LSAs will be aged out 345 by each remaining router individually. This will slow database 346 convergence when an authenticated router goes down, but the databases 347 will still converge, and a fairly obvious security hole will be closed. 349 6. Of Cryptography and Keys 351 This design relies on Public Key cryptography. The common examples are 352 RSA and DSA, but a specific algorithm is not mandated by this design. 353 There are some good books on the subject [2], but the high level view of 354 how this design uses Public-Key cryptography is as follows: 356 Each router has a private key that must be secret, and a public key that 357 everyone may know. A signature can be generated with the private key, 358 and verified using the public key. This verification ensures that the 359 data signed has not been altered in transit, and that it was signed by 360 the router having the correct private key. There is a Trusted Entity 361 somewhere that has a secret private key, and a public key that all 362 routers must know. A router must be configured with it's own pair of 363 keys (public and private), and with the public key of the Trusted 364 Entity. It must obtain a copy of its own public key plus some 365 identifying data (id and role), signed by the Trusted entity. The 366 signature by the Trusted Entity is its certification that it has 367 verified, according to autonomous system policy, the binding between the 368 Router ID and the public key. 370 An authenticated router sends its certified public key in a Router 371 Public Key LSA via OSPF flooding. All authenticated routers receiving 372 this key store it to use in verifying the advertising router's 373 signatures. The certification can be checked using the Trusted Entity's 374 public key, which, again, all routers must know. 376 Each router signs its LSAs by first running a one-way hash algorithm 377 (like MD5 or SHA, not mandated) on the data, and then using its private 378 key to sign the digested data. The signature for an LSA is appended to 379 the LSA. 381 Periodically, keys will have to be changed, and the new router public 382 keys will have to be certified by the Trusted Entity. A router could 383 generate its new key pair, or could receive them via a key distribution 384 scheme. Certification could be done out-of-band, or via an encrypted 385 exchange of information with the Trusted Entity. Key distribution is 386 beyond the scope of this memo. 388 Each router must be able to store several keys for each authenticated 389 router in the area and each ASBR. When a new key is distributed by a 390 router, both the new and the old key must be valid for a key-rollover 391 period. 393 7. Security Considerations 395 This entire memo is about security considerations. 397 8. References 399 [1] John Moy. OSPF Version 2. RFC 1583, March 1994 401 [2] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and 402 Source Code in C, John Wiley & Sons, Inc 1994 404 9. Author's Address 406 Sandra Murphy 407 Trusted Information Systems 408 3060 Washington Road 409 Glenwood, MD 21738 410 EMail: murphy@tis.com 412 Madelyn Badger 413 Trusted Information Systems 414 3060 Washington Road 415 Glenwood, MD 21738 416 EMail: mrb@tis.com 417 Table of Contents 419 Status of this Memo .............................................. 1 420 Abstract ......................................................... 1 421 1 Introduction .................................................... 1 422 2 Overview ........................................................ 3 423 3 LSA Processing .................................................. 3 424 4 LSA formats ..................................................... 4 425 4.1 Options field ................................................. 4 426 4.2 LSA Type Field ................................................ 5 427 4.3 Router Public Key LSA ......................................... 5 428 4.4 Signed LSA .................................................... 6 429 5 Processing Max Age .............................................. 7 430 6 Of Cryptography and Keys ........................................ 8 431 7 Security Considerations ......................................... 9 432 8 References ...................................................... 9 433 9 Author's Address ................................................ 10