idnits 2.17.1 draft-ietf-ipsec-auth-01.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-04-19) 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 73 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 75: '...e authentication MAY ignore the Authen...' RFC 2119 keyword, line 95: '...th MTU Discovery MUST be used when int...' RFC 2119 keyword, line 106: '... - MUST...' RFC 2119 keyword, line 111: '... - SHOULD...' RFC 2119 keyword, line 118: '... - MAY...' (16 more instances...) 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.) -- The document date (25 April 1995) is 10587 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) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-esp is -00, but you're referring to -01. -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. 'BCCH94') -- Possible downref: Non-RFC (?) normative reference: ref. 'CER95' ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. 'GM93') -- No information found for draft-hinden-ipv6-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Hin94' ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') ** Downref: Normative reference to an Informational RFC: RFC 1435 (ref. 'Kno93') -- Possible downref: Non-RFC (?) normative reference: ref. 'MS95' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'Riv92') -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Randall Atkinson 3 Internet Draft Naval Research Laboratory 4 draft-ietf-ipsec-auth-01.txt 25 April 1995 6 IP Authentication Header 8 STATUS OF THIS MEMO 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of 6 months. 16 Internet Drafts may be updated, replaced, or obsoleted by other 17 documents at any time. It is not appropriate to use Internet Drafts as 18 reference material or to cite them other than as a "working draft" or 19 "work in progress". Please check the I-D abstract listing contained 20 in each Internet Draft directory to learn the current status of this 21 or any other Internet Draft. 23 This particular Internet Draft is a product of the IETF's IPng and 24 IPsec Working Groups. It is intended that a future version of this 25 draft will be submitted for consideration as a standards-track 26 document. Distribution of this document is unlimited. 28 0. ABSTRACT 29 This document describes a mechanism for providing cryptographic 30 authentication for IPv4 and IPv6 datagrams. An Authentication Header 31 (AH) is normally inserted after the main IP header and before the 32 other information being authenticated. 34 1. INTRODUCTION 36 The Authentication Header is a mechanism for providing strong 37 integrity and authentication for IP datagrams. It might also provide 38 non-repudiation, depending on which cryptographic algorithm is used 39 and how keying is performed. For example, use of an asymmetric 40 digital signature algorithm, for example RSA, could provide 41 non-repudiation. 43 Confidentiality, and protection from traffic analysis are not 45 provided by the Authentication Header. Users desiring confidentiality 46 should consider using the IP Encapsulating Security Protocol (ESP) 47 either in lieu of or in conjunction with the Authentication 48 Header. [Atk95b] This document assumes the reader has previously read 49 the related IP Security Architecture document which defines the 50 overall security architecture for IP and provides important background 51 information for this specification. [Atk95a] 53 1.1 Overview 54 The IP Authentication Header seeks to provide security by 55 adding authentication information to an IP datagram. This 56 authentication information is calculated using all of the fields in 57 the IP datagram (including not only the IP Header but also other 58 headers and the user data) which do not change in transit. Fields 59 which need to change in transit (e.g "hop count" or "routing pointer") 60 are omitted from the calculation of the authentication data. This 61 provides significantly more security than is currently present in IPv4 62 and might be sufficient for the needs of many users. 64 Use of this specification will increase the IP protocol processing 65 costs in participating end systems and will also increase the 66 communications latency. The increased latency is primarily due to the 67 calculation of the authentication data by the sender and the calculation 68 and comparison of the authentication data by the receiver for each IP 69 datagram containing an Authentication Header. The impact will vary 70 with authentication algorithm used and other factors. 72 In order for the Authentication Header to work properly without 73 changing the entire Internet infrastructure, the authentication data 74 is carried in its own payload. Systems that aren't participating in 75 the authentication MAY ignore the Authentication Data. When used with 76 IPv6, the Authentication Header is normally placed after the 77 Hop-by-Hop header, which is examined at each hop, and before the 78 End-to-End Header, which is never examined at an intermediate hop. 79 The information in the other IP headers is used to route the datagram 80 from origin to destination. When used with IPv4, the Authentication 81 Header immediately follows the main IPv4 header. 83 If a symmetric authentication algorithm is used and intermediate 84 authentication is desired, then the nodes performing such intermediate 85 authentication would need to be provided with the appropriate keys. 86 Possession of those keys would permit any one of those systems to 87 forge traffic claiming to be from the legitimate sender to the 88 legitimate receiver or to modify the contents of otherwise legitimate 89 traffic. In some environments such intermediate authentication might 90 be desirable. [BCCH94] If an asymmetric authentication algorithm is 91 used and the routers are aware of the appropriate public keys and 92 authentication algorithm, then the routers possessing the 93 authentication public key could authenticate the traffic being handled 94 without being able to forge or modify otherwise legitimate traffic. 95 Also, Path MTU Discovery MUST be used when intermediate 96 authentication of the Authentication Header is desired and IPv4 is in 97 use because it is not possible to authenticate a fragement of a 98 packet. [MD90] [Kno93] 100 1.2 Requirements Terminology 102 In this document, the words that are used to define the significance 103 of each particular requirement are usually capitalised. These words 104 are: 106 - MUST 108 This word or the adjective "REQUIRED" means that the item is an 109 absolute requirement of the specification. 111 - SHOULD 113 This word or the adjective "RECOMMENDED" means that there might 114 exist valid reasons in particular circumstances to ignore this item, 115 but the full implications should be understood and the case carefully 116 weighed before taking a different course. 118 - MAY 120 This word or the adjective "OPTIONAL" means that this item is truly 121 optional. One vendor might choose to include the item because a 122 particular marketplace requires it or because it enhances the product, 123 for example; another vendor may omit the same item. 125 2. KEY MANAGEMENT 127 Key management is an important part of the IP security architecture. 128 However, it is not integrated with this specification because of a 129 long history in the public literature of subtle flaws in key 130 management algorithms and protocols. The IP Authentication Header 131 tries to decouple the key management mechanisms from the security 132 protocol mechanisms. The only coupling between the key management 133 protocol and the security protocol is with the Security Association 134 Identifier (SPI), which is described in more detail below. This 135 decoupling permits several different key management mechanisms to be 136 used. More importantly, it permits the key management protocol to be 137 changed or corrected without unduly impacting the security protocol 138 implementations. 140 The key management mechanism is used to negotiate a number of 142 parameters for each "Security Association", including not only the 143 keys but also other information (e.g. the authentication algorithm and 144 mode) used by the communicating parties. The key management mechanism 145 creates and maintains a logical table containing the several 146 parameters for each current security association. An implementation 147 of the IP Authentication Header will need to read that logical table 148 of security parameters to determine how to process each datagram 149 containing an Authentication Header (e.g. to determine which 150 algorithm/mode and key to use in authentication). The combination of 151 Destination Address and SPI value is used to identify the appropriate 152 Security Association and hence the security parameters in use. 154 The IP Security Architecture document describes key management in 155 detail. It includes specification of the key management requirements 156 for this protocol, and is incorporated here by reference. [Atk95a] 158 3. AUTHENTICATION HEADER 160 The Authentication Header (AH) may appear after any other headers 161 which are examined at each hop, and before any other headers which 162 are not examined at an intermediate hop. The IPv4 or IPv6 header 163 immediately preceding the Authentication Header will contain the value 164 51 in its Next Header (or Protocol) field. [STD-2] 166 Example high-level diagrams of IP datagrams with the Authentication 167 Header follow. 169 +-------------+--------------------+-------------+--------+----------------+ 170 | IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol | 171 +-------------+--------------------+-------------+--------+----------------+ 173 IPv6 Example 174 When used with IPv6, the Authentication Header normally appears after 175 the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options. 177 +-------------+--------------+-------------------------------+ 178 | IPv4 Header | Auth Header | Upper Protocol (e.g TCP, UDP) | 179 +-------------+--------------+-------------------------------+ 181 IPv4 Example 182 When used with IPv4, the Authentication Header normally follows the 183 main IPv4 header. 185 3.1 Authentication Header Syntax 187 The authentication data is the output of the authentication 188 algorithm calculated over the the entire IP datagram as described in 189 more detail later in this document. The authentication calculation 190 must treat the Authentication Data field itself and all fields that 191 are normally modified in transit (e.g. TTL or Hop Limit) as if those 192 fields contained all zeros. All other Authentication Header fields 193 are included in the authentication calculation normally. 195 The IP Authentication Header has the following syntax: 197 +--------------+---------------+----------------+--------------+ 198 | Next Header | Length | RESERVED | 199 +--------------+---------------+----------------+--------------+ 200 | Security Parameters Index | 201 +--------------+---------------+----------------+--------------+ 202 | Authentication Data (variable number of 32-bit words) | 203 +--------------+---------------+----------------+--------------+ 204 | (more Authentication Data) | 205 +--------------+---------------+----------------+--------------+ 207 3.2 Fields of the Authentication Header 209 NEXT HEADER 210 8 bits wide. Identifies the next payload after the Authentication 211 Payload. This values in this field are the set of IP Protocol Numbers 212 as defined in the most recent RFC from the Internet Assigned Numbers 213 Authority (IANA) describing "Assigned Numbers". [STD-2] 215 PAYLOAD LENGTH 216 8 bits wide. The length of the Authentication Data field in 32-bit 217 words. Minimum value is 0 words, which is only used in the degenerate 218 case of a "null" authentication algorithm. 220 RESERVED 221 Reserved for future use. MUST be set to all zeros when sent and 222 ignored upon receipt. 224 SECURITY PARAMETERS INDEX (SPI) 226 A 32-bit pseudo-random value identifying the security association 227 for this datagram. The Ssecurity Parameters Index value 0 is 228 reserved to indicate that "no security association exists". 230 The set of Security Parameters Index values in the range 1 231 through 255 are reserved to the Internet Assigned Numbers 232 Authority (IANA) for future use. A reserved SPI value will not 233 normally be assigned by IANA unless the use of that particular 234 assigned SPI value is openly specified in an RFC. 236 _A_U_T_H_E_N_T_I_C_A_T_I_O_N _D_A_T_A 237 This length of this field is variable, but is always an integral 238 number of 32-bit words. 240 Many implementations require padding to other alignments, such as 241 64-bits, in order to improve performance. All implementations MUST 242 support such padding, which is specified by the Destination on a per 243 SPI basis. 245 An implementation will normally use the combination of Destination 246 Address and SPI to locate the Security Association which specifies 247 the field's size and use. The field retains the same format 248 for all datagrams of any given SPI and Destination Address pair. 250 The Authentication Data fills the field beginning immediately after 251 the SPI field. If the field is longer than necessary to store the 252 actual authentication data, then the unused bit positions are filled 253 with unspecified, implementation-dependent values. Those unused 254 bit positions MUST be ignored upon receipt. 256 Refer to each Authentication Mechanism specification for more 257 information regarding the contents of this field. 259 3.3 Sensitivity Labeling 261 As is discussed in greater detail in the IP Security Architecture 262 document, IPv6 will normally use implicit Security Labels rather than 263 the explicit labels that are currently used with IPv4. [Ken91] 264 [Atk95a] In some situations, users MAY choose to carry explicit labels 265 (for example, IPSO labels as defined by RFC-1108 might be used with 266 IPv4) in addition to using the implicit labels provided by the 267 Authentication Header. Explicit label options could be defined for 268 use with IPv6 (e.g. using the IPv6 end-to-end options header or the 269 IPv6 hop-by-hop options header). Implementations MAY support explicit 270 labels in addition to implicit labels, but implementations are not 271 required to support explicit labels. If explicit labels are in use, 272 then the explicit label MUST be included in the authentication 273 calculation. 275 4. CALCULATION OF THE AUTHENTICATION DATA 277 The authentication data is usually calculated using a message digest 278 algorithm (for example, MD5) either encrypting that message digest or 279 keying the message digest directly. [Riv92] Only algorithms that are 280 believed to be cryptographically strong one-way functions should be 281 used with this header. 283 Because conventional checksums (e.g. CRC-16) are not 284 cryptographically strong and can be reverse-engineered, they MUST NOT 285 be used with the Authentication Header. 287 If a block-oriented authentication algorithm (e.g. MD5, MD4) is in 288 use and the IP packet is not an integral number of blocks, the 289 authentication data calculation is performed using zero bytes at the 290 end to pad the length out to an integral number of blocks. [Riv92] 291 These block padding bytes are not included in the actual IP datagram 292 and are not sent over the wire because adding padding at that point in 293 IP protocol processing would make implementation of the MTU related 294 calculations very difficult. 296 The appropriate Security Association is first selected. This 297 selection is based at least upon the sending userid and the 298 Destination Address. When host-oriented keying is in use, all sending 299 userids will share the same Security Association to a given 300 destination. When user-oriented keying is in use, then different 301 users or possibly even different applications of the same user might 302 use different Security Associations. The Security Association 303 selected will indicate which algorithm, algorithm mode, key, and other 304 properties apply to the outgoing packet. 306 Fields which NECESSARILY are modified during transit from the sender 307 to the receiver (e.g. TTL or Hop Count) are included in the 308 authentication data calculation but the value zero is substituted for 309 the actual value of such fields in the IP packet. This substitution 310 of zero is used instead of omitting those fields because it preserves 311 alignment throughout the authentication data calculation and thereby 312 can significantly improve performance. 314 The sender MUST compute the authentication over the packet as it 315 will appear at the receiver. This requirement is placed in order to 316 allow for future IP optional headers which the receiver might not 317 know about but the sender necessarily knows about if it is including 318 such options in the packet. The sender places the calculated message 319 digest algorithm output into the Authentication Data field within the 320 Authentication Header. 322 Upon receipt of a packet containing an IP Authentication Header, the 323 receiver first uses the Destination Address and SPI value to locate 324 the correct Security Association. The receiver then independently 325 calculates the authentication data for the received packet. It then 326 compares the received Authentication Data field contents with the 327 calculated authentication value. If the two match, then the datagram 328 is accepted as authentic. If they differ, then the receiver SHOULD 329 discard the received IP datagram as non-authentic and MUST record the 330 authentication failure in the system log or audit log. If such a 331 failure occurs, the recorded log data MUST include the SPI value, 332 date/time received, clear-text Sending Address, clear-text Destination 333 Address, and clear-text Flow ID. The log data MAY also include other 334 information about the failed packet. 336 Not all of the fields of the IPv6 Hop-by-Hop Options header are 337 included in the authentication calculation. The third-highest-order 338 bit of the Option Type field within the IPv6 Hop-by-Hop Options Header 339 indicates whether any particular option is included within the 340 authentication calculation or is omitted from the authentication 341 calculation. If the particular option is to be omitted, that option 342 is skipped over during the authentication calculation as if it were 343 not present. Because of this bit encoding, an implementation can 344 authenticate newly defined IPv6 hop-by-hop options without having to 345 modify the authentication portion of the IP implementation. The IPv6 346 specification provides additional information on the IPv6 Hop-by-Hop 347 Options Header. [Hin94] 349 5. CONFORMANCE REQUIREMENTS 350 Implementations that claim conformance or compliance with this 351 specification MUST fully implement the header described here, MUST 352 support manual key distribution for use with this option, MUST comply 353 with all requirements of the "Security Architecuture for the Internet 354 Protocol" [Atk95a], and MUST support the use of keyed MD5 as described 355 in the companion document entitled "IP Authentication using Keyed MD5" 356 [MS95]. Implementations MAY also implement other authentication 357 algorithms. Implementors should consult the most recent version of 358 the "IAB Official Standards" RFC for further guidance on the status of 359 this document. 361 6. SECURITY CONSIDERATIONS 363 This entire RFC discusses an authentication mechanism for IP. 364 This mechanism is not a panacea to the several security issues in any 365 internetwork, however it does provide a component useful in building a 366 secure internetwork. 368 Users need to understand that the quality of the security provided 369 by this specification depends completely on the strength of whichever 370 cryptographic algorithm has been implemented, the strength of the key 371 being used, the correctness of that algorithm's implementation, upon 372 the security of the key management mechanism and its implementation, 373 and upon the correctness of the IP Authentication Header and IP 374 implementations in all of the participating systems. If any of these 375 assumptions do not hold, then little or no real security will be 376 provided to the user. Implementers are encouraged to use high 377 assurance methods to develop all of the security relevant parts of 378 their products. 380 Users interested in confidentiality should consider using the IP 381 Encapsulating Security Payload (ESP) instead of or in conjunction with 382 this specification. [Atk95b] Users seeking protection from traffic 383 analysis might consider the use of appropriate link encryption. 384 Description and specification of link encryption is outside the scope 385 of this note. [VK83] Users interested in combining the IP 386 Authentication Header with the IP Encapsulating Security Payload 387 should consult the IP Encapsulating Security Payload specification 388 for details. 390 One particular issue is that in some cases a packet which causes an 391 error to be reported back via ICMP might be so large as not to 392 entirely fit within the ICMP message returned. In such cases, it 393 might not be possible for the receiver of the ICMP message to 394 independently authenticate the portion of the returned message. This 395 could mean that the host receiving such an ICMP message would either 396 trust an unauthenticated ICMP message, which might in turn create some 397 security problem, or not trust and hence not react appropriately to 398 some legitimate ICMP message that should have been reacted to. It 399 is not clear that this issue can be fully resolved in the presence of 400 packets that are the same size as or larger than the minimum IP MTU. 401 Similar complications arise if an encrypted packet causes an ICMP 402 error message to be sent and that packet is truncated. 404 Active attacks are now widely known to exist in the Internet 405 [CER95]. The presence of active attacks means that unauthenticated 406 source routing, either unidirectional (receive-only) or with replies 407 following the original received source route represents a significant 408 security risk unless all received source routed packets are 409 authenticated using the IP Authentication Header or some other 410 cryptologic mechanism. It is noteworthy that the attacks described in 411 [CER95] include a subset of those described in [Bel89]. 413 This documented benefited greatly from work done by Bill Simpson, Perry 414 Metzger, and Phil Karn to make general the approach originally defined 415 by the author for SIP, SIPP, and finally IPv6. 417 The basic concept here is derived in large part from the SNMPv2 418 Security Protocol work described in [GM93]. Steve Bellovin, Steve 419 Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided 420 thoughtful critiques of early versions of this note. Francis Dupont 421 discovered and pointed out the security issue with ICMP in low IP MTU 422 links that is noted just above. 424 REFERENCES 425 [Atk95a] Randall Atkinson, Security Architecture for the Internet Protocol, 426 draft-ietf-ipsec-arch-sec-01.txt, 25 April 1995. 428 [Atk95b] Randall Atkinson, IP Encapsulating Security Payload, 429 draft-ietf-ipsec-esp-01.txt, 25 April 1995. 431 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 432 ACM Computer Communications Review, Vol. 19, No. 2, March 1989. 434 [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop 435 on Security in the Internet Architecture", RFC-1636, DDN Network 436 Information Center, 9 June 1994, pp. 21-34. 438 [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and 439 Hijacked Terminal Connections", CA-95:01, January 1995. 440 Available via anonymous ftp from info.cert.org in /pub/cert_advisories. 442 [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 443 of the Simple Network Management Protocol (SNMPv2), RFC-1446, 444 DDN Network Information Center, April 1993. 446 [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, 447 draft-hinden-ipv6-spec-00.txt, October 1994. 449 [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", 450 RFC-1108, DDN Network Information Center, November 1991. 452 [Kno93] Steve Knowles, "IESG Advice from Experience with Path MTU Discovery", 453 RFC-1435, DDN Network Information Center, March 1993. 455 [MS95] Perry Metzger & Bill Simpson, "IP Authentication with Keyed MD5", 456 Work in Progress, 21 March 1995. 458 [MD90] Jeff Mogul & Steve Deering, "Path MTU Discovery", RFC-1191, 459 DDN Network Information Center, November 1990. 461 [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 462 DDN Network Information Center, 20 October 1994. 464 [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information 465 Center, April 1992. 467 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", 468 ACM Computing Surveys, Vol. 15, No. 2, June 1983. 470 DISCLAIMER 472 The views and specification here are those of the author and are not 473 necessarily those of his employer. The Naval Research Laboratory has 474 not passed judgement on the merits, if any, of this work. The author 475 and his employer specifically disclaim responsibility for any problems 476 arising from correct or incorrect implementation or use of this 477 specification. 479 AUTHOR INFORMATION 481 Randall Atkinson 482 Information Technology Division 483 Naval Research Laboratory 484 Washington, DC 20375-5320 485 USA 487 Phone: (DSN) 354-8590 488 Fax: (DSN) 354-7942