1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
<pre>Network Working Group T. Li
Request for Comments: 3567 Procket Networks
Category: Informational R. Atkinson
Extreme Networks
July 2003
<span class="h1">Intermediate System to Intermediate System (IS-IS)</span>
<span class="h1">Cryptographic Authentication</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the authentication of Intermediate System to
Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
algorithm as found in <a href="./rfc2104">RFC 2104</a>. IS-IS is specified in International
Standards Organization (ISO) 10589, with extensions to support
Internet Protocol version 4 (IPv4) described in <a href="./rfc1195">RFC 1195</a>. The base
specification includes an authentication mechanism that allows for
multiple authentication algorithms. The base specification only
specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that allows
the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IS-IS protocol, as specified in ISO 10589 [<a href="#ref-1" title=""Intermediate System to Intermediate System Routing Information Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">1</a>], provides for the
authentication of Link State PDUs (LSPs) through the inclusion of
authentication information as part of the LSP. This authentication
information is encoded as a Type-Length-Value (TLV) tuple. The use
of IS-IS for IPv4 networks is described in [<a href="#ref-3" title=""Use of OSI IS-IS for Routing in TCP/IP and Dual environments"">3</a>].
The type of the TLV is specified as 10. The length of the TLV is
variable. The value of the TLV depends on the authentication
algorithm and related secrets being used. The first octet of the
value is used to specify the authentication type. Type 0 is
<span class="grey">Li & Atkinson Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3567">RFC 3567</a> IS-IS Cryptographic Authentication July 2003</span>
reserved, type 1 indicates a cleartext password, and type 255 is used
for routing domain private authentication methods. The remainder of
the TLV value is known as the Authentication Value.
This document extends the above situation by allocating a new
authentication type for HMAC-MD5 and specifying the algorithms for
the computation of the Authentication Value. This document also
describes modifications to the base protocol to ensure that the
authentication mechanisms described in this document are effective.
This document is a publication of the IS-IS Working Group within the
IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
inclusion with ISO 10589.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Authentication Procedures</span>
The authentication type used for HMAC-MD5 is 54 (0x36). The length
of the Authentication Value for HMAC-MD5 is 16, and the length field
in the TLV is 17.
The HMAC-MD5 algorithm requires a key K and text T as input [<a href="#ref-2" title=""HMAC: Keyed-Hashing for Message Authentication"">2</a>]. The
key K is the password for the PDU type, as specified in ISO 10589.
The text T is the IS-IS PDU to be authenticated with the
Authentication Value field inside of the Authentication Information
TLV set to zero. Note that the Authentication Type is set to 54 and
the length of the TLV is set to 17 before authentication is computed.
When LSPs are authenticated, the Checksum and Remaining Lifetime
fields are set to zero (0) before authentication is computed. The
result of the algorithm is placed in the Authentication Value field.
When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
1 Sequence Number PDUs SHALL use the Area Authentication string as in
Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the
domain authentication string as in Level 2 Link State PDUs. IS-IS
HELLO PDUs SHALL use the Link Level Authentication String, which MAY
be different from that of Link State PDUs. The HMAC-MD5 result for
the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded
to the MTU size, if padding is not disabled. Implementations that
support the optional checksum for the Sequence Number PDUs and IS-IS
HELLO PDUs MUST NOT include the Checksum TLV.
To authenticate an incoming PDU, a system should save the values of
the Authentication Value field, the Checksum and the Remaining
Lifetime field, set these fields to zero, compute authentication, and
then restore the values of these fields.
<span class="grey">Li & Atkinson Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3567">RFC 3567</a> IS-IS Cryptographic Authentication July 2003</span>
An implementation that implements HMAC-MD5 authentication and
receives HMAC-MD5 Authentication Information MUST discard the PDU if
the Authentication Value is incorrect.
An implementation MAY have a transition mode where it includes HMAC-
MD5 Authentication Information in PDUs but does not verify the HMAC-
MD5 authentication information. This is a transition aid for
networks in the process of deploying authentication.
An implementation MAY check a set of passwords when verifying the
Authentication Value. This provides a mechanism for incrementally
changing passwords in a network.
An implementation that does not implement HMAC-MD5 authentication MAY
accept a PDU that contains the HMAC-MD5 Authentication Type. ISes
(routers) that implement HMAC-MD5 authentication and initiate LSP
purges MUST remove the body of the LSP and add the authentication
TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept
unauthenticated purges. ISes MUST NOT accept purges that contain
TLVs other than the authentication TLV. These restrictions are
necessary to prevent a hostile system from receiving an LSP, setting
the Remaining Lifetime field to zero, and flooding it, thereby
initiating a purge without knowing the authentication password.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Implementation Considerations</span>
There is an implementation issue just after password rollover on an
IS-IS router that might benefit from additional commentary.
Immediately after password rollover on the router, the router or IS-
IS process may restart. If this happens, this causes the LSP
Sequence Number restarts from the value 1 using the new password.
However, neighbors will reject those new LSPs because the Sequence
Number is smaller. The router can not increase its own LSP Sequence
Number because it fails to authenticate its own old LSP that
neighbors keep sending to it. So the router can not update its LSP
Sequence Number to its neighbors until all the neighbors time out all
of the original LSPs. One possible solution to this problem is for
the IS-IS process to detect if any inbound LSP with an authentication
failure has the local System ID and also has a higher Sequence Number
than the IS-IS process has. In this event, the IS-IS process SHOULD
increase its own LSP Sequence Number accordingly and re-flood the
LSPs. However, as this scenario could also be triggered by an active
attack by an adversary, it is recommended that a counter also be kept
on this case to mitigate the risk from such an active attack.
<span class="grey">Li & Atkinson Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3567">RFC 3567</a> IS-IS Cryptographic Authentication July 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
This document enhances the security of the IS-IS routing protocol.
Because a routing protocol contains information that need not be kept
secret, privacy is not a requirement. However, authentication of the
messages within the protocol is of interest, to reduce the risk of an
adversary compromising the routing system by deliberately injecting
false information into the routing system.
The technology in this document provides an authentication mechanism
for IS-IS. The mechanism described here is not perfect and does not
need to be perfect. Instead, this mechanism represents a significant
increase in the work function of an adversary attacking the IS-IS
protocol, while not causing undue implementation, deployment, or
operational complexity.
This mechanism does not prevent replay attacks, however, in most
cases, such attacks would trigger existing mechanisms in the IS-IS
protocol that would effectively reject old information. Denial of
service attacks are not generally preventable in a useful networking
protocol [<a href="#ref-4" title=""Security Mechanisms in High-level Networks"">4</a>].
Changes to the authentication mechanism described here (primarily:
to add a Key-ID field such as OSPFv2 and RIPv2 have) were considered
at some length, but ultimately were rejected. The mechanism here was
already widely implemented in 1999. As of this writing, this
mechanism is fairly widely deployed within the users interested in
cryptographic authentication of IS-IS. The improvement provided by
the proposed revised mechanism was not large enough to justify the
change, given the installed base and lack of operator interest in
deploying a revised mechanism.
If and when a key management protocol appears that is both widely
implemented and easily deployed to secure routing protocols such as
IS-IS, a different authentication mechanism that is designed for use
with that key management schema could be added if desired.
If a stronger authentication were believed to be required, then the
use of a full digital signature [<a href="#ref-5" title=""OSPF with Digital Signatures"">5</a>] would be an approach that should
be seriously considered. It was rejected for this purpose at this
time because the computational burden of full digital signatures is
believed to be much higher than is reasonable given the current
threat environment in operational commercial networks.
<span class="grey">Li & Atkinson Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3567">RFC 3567</a> IS-IS Cryptographic Authentication July 2003</span>
Acknowledgements
The authors would like to thank (in alphabetical order) Dave Katz,
Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their
comments and suggestions on this document.
Normative References
[<a id="ref-1">1</a>] ISO, "Intermediate System to Intermediate System Routing
Information Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)", ISO/IEC 10589:2002, Second Edition.
[<a id="ref-2">2</a>] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", <a href="./rfc2104">RFC 2104</a>, February 1997.
Informative References
[<a id="ref-3">3</a>] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
environments", <a href="./rfc1195">RFC 1195</a>, December 1990.
[<a id="ref-4">4</a>] Voydock, V. and S. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[<a id="ref-5">5</a>] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
Signatures", <a href="./rfc2154">RFC 2154</a>, June 1997.
Authors' Addresses
Tony Li
Procket Networks
1100 Cadillac Ct.
Milpitas, CA 95035 USA
Phone: +1 (408) 635-7903
EMail: tli@procket.net
Ran J. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051 USA
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
<span class="grey">Li & Atkinson Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3567">RFC 3567</a> IS-IS Cryptographic Authentication July 2003</span>
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Li & Atkinson Informational [Page 6]
</pre>
|
