« back to all changes in this revision
Viewing changes to doc/rfc/rfc2138.txt
- browse files at revision 11
- compare with another revision
- download diff
- download tarball
- view history from revision 11
- Committer: Bazaar Package Importer
- Author(s): Jeremie Corbier
- Date: 2006-07-08 19:41:05 UTC
- mfrom: (1.1.5 upstream)
- Revision ID: james.westby@ubuntu.com-20060708194105-2dabtaxd16o7p90g
Tags: 1.1.2-2ubuntu1
* Merge from debian unstable.
* Remove previous patches merged upstream:
- 14_freeradius-dictionary-fix.dpatch
* Remove previous patches merged upstream:
- 14_freeradius-dictionary-fix.dpatch
- files added:
- debian/README.rfc
- doc/examples
- src/modules/rlm_sqlippool
- files removed:
- debian/freeradius.undocumented
- doc/rfc
- files modified:
- LICENSE
- dialup_admin/bin/monthly_tot_stats *
- dialup_admin/bin/tot_stats *
- doc/load-balance.txt *
- man/man5/rlm_sql_log.5 *
- share/dictionary.airespace *
added
removed
doc/rfc/rfc2138.txt
1
2
3
4
5
6
7
Network Working Group C. Rigney
8
Request for Comments: 2138 Livingston
9
Obsoletes: 2058 A. Rubens
10
Category: Standards Track Merit
11
W. Simpson
12
Daydreamer
13
S. Willens
14
Livingston
15
April 1997
16
17
18
Remote Authentication Dial In User Service (RADIUS)
19
20
Status of this Memo
21
22
This document specifies an Internet standards track protocol for the
23
Internet community, and requests discussion and suggestions for
24
improvements. Please refer to the current edition of the "Internet
25
Official Protocol Standards" (STD 1) for the standardization state
26
and status of this protocol. Distribution of this memo is unlimited.
27
28
Abstract
29
30
This document describes a protocol for carrying authentication,
31
authorization, and configuration information between a Network Access
32
Server which desires to authenticate its links and a shared
33
Authentication Server.
34
35
Implementation Note
36
37
This memo documents the RADIUS protocol. There has been some
38
confusion in the assignment of port numbers for this protocol. The
39
early deployment of RADIUS was done using the erroneously chosen port
40
number 1645, which conflicts with the "datametrics" service. The
41
officially assigned port number for RADIUS is 1812.
42
43
Table of Contents
44
45
1. Introduction .......................................... 3
46
1.1 Specification of Requirements ................... 4
47
1.2 Terminology ..................................... 5
48
2. Operation ............................................. 5
49
2.1 Challenge/Response .............................. 7
50
2.2 Interoperation with PAP and CHAP ................ 7
51
2.3 Why UDP? ........................................ 8
52
3. Packet Format ......................................... 10
53
4. Packet Types .......................................... 13
54
4.1 Access-Request .................................. 13
55
56
57
58
Rigney, et. al. Standards Track [Page 1]
59
60
RFC 2138 RADIUS April 1997
61
62
63
4.2 Access-Accept ................................... 14
64
4.3 Access-Reject ................................... 15
65
4.4 Access-Challenge ................................ 17
66
5. Attributes ............................................ 18
67
5.1 User-Name ....................................... 21
68
5.2 User-Password ................................... 22
69
5.3 CHAP-Password ................................... 23
70
5.4 NAS-IP-Address .................................. 24
71
5.5 NAS-Port ........................................ 25
72
5.6 Service-Type .................................... 26
73
5.7 Framed-Protocol ................................. 28
74
5.8 Framed-IP-Address ............................... 29
75
5.9 Framed-IP-Netmask ............................... 29
76
5.10 Framed-Routing .................................. 30
77
5.11 Filter-Id ....................................... 31
78
5.12 Framed-MTU ...................................... 32
79
5.13 Framed-Compression .............................. 33
80
5.14 Login-IP-Host ................................... 33
81
5.15 Login-Service ................................... 34
82
5.16 Login-TCP-Port .................................. 35
83
5.17 (unassigned) .................................... 36
84
5.18 Reply-Message ................................... 36
85
5.19 Callback-Number ................................. 37
86
5.20 Callback-Id ..................................... 38
87
5.21 (unassigned) .................................... 38
88
5.22 Framed-Route .................................... 39
89
5.23 Framed-IPX-Network .............................. 40
90
5.24 State ........................................... 40
91
5.25 Class ........................................... 41
92
5.26 Vendor-Specific ................................. 42
93
5.27 Session-Timeout ................................. 44
94
5.28 Idle-Timeout .................................... 44
95
5.29 Termination-Action .............................. 45
96
5.30 Called-Station-Id ............................... 46
97
5.31 Calling-Station-Id .............................. 47
98
5.32 NAS-Identifier .................................. 48
99
5.33 Proxy-State ..................................... 48
100
5.34 Login-LAT-Service ............................... 49
101
5.35 Login-LAT-Node .................................. 50
102
5.36 Login-LAT-Group ................................. 51
103
5.37 Framed-AppleTalk-Link ........................... 52
104
5.38 Framed-AppleTalk-Network ........................ 53
105
5.39 Framed-AppleTalk-Zone ........................... 54
106
5.40 CHAP-Challenge .................................. 55
107
5.41 NAS-Port-Type ................................... 55
108
5.42 Port-Limit ...................................... 56
109
5.43 Login-LAT-Port .................................. 57
110
5.44 Table of Attributes ............................. 58
111
112
113
114
Rigney, et. al. Standards Track [Page 2]
115
116
RFC 2138 RADIUS April 1997
117
118
119
6. Examples .............................................. 59
120
6.1 User Telnet to Specified Host ................... 60
121
6.2 Framed User Authenticating with CHAP ............ 60
122
6.3 User with Challenge-Response card ............... 61
123
Security Considerations ...................................... 63
124
References ................................................... 64
125
Acknowledgements ............................................. 64
126
Chair's Address .............................................. 65
127
Author's Addresses ........................................... 65
128
129
1. Introduction
130
131
Managing dispersed serial line and modem pools for large numbers of
132
users can create the need for significant administrative support.
133
Since modem pools are by definition a link to the outside world, they
134
require careful attention to security, authorization and accounting.
135
This can be best achieved by managing a single "database" of users,
136
which allows for authentication (verifying user name and password) as
137
well as configuration information detailing the type of service to
138
deliver to the user (for example, SLIP, PPP, telnet, rlogin).
139
140
Key features of RADIUS are:
141
142
Client/Server Model
143
144
A Network Access Server (NAS) operates as a client of RADIUS. The
145
client is responsible for passing user information to designated
146
RADIUS servers, and then acting on the response which is returned.
147
148
RADIUS servers are responsible for receiving user connection
149
requests, authenticating the user, and then returning all
150
configuration information necessary for the client to deliver
151
service to the user.
152
153
A RADIUS server can act as a proxy client to other RADIUS servers
154
or other kinds of authentication servers.
155
156
Network Security
157
158
Transactions between the client and RADIUS server are
159
authenticated through the use of a shared secret, which is never
160
sent over the network. In addition, any user passwords are sent
161
encrypted between the client and RADIUS server, to eliminate the
162
possibility that someone snooping on an unsecure network could
163
determine a user's password.
164
165
166
167
168
169
170
Rigney, et. al. Standards Track [Page 3]
171
172
RFC 2138 RADIUS April 1997
173
174
175
Flexible Authentication Mechanisms
176
177
The RADIUS server can support a variety of methods to authenticate
178
a user. When it is provided with the user name and original
179
password given by the user, it can support PPP PAP or CHAP, UNIX
180
login, and other authentication mechanisms.
181
182
Extensible Protocol
183
184
All transactions are comprised of variable length Attribute-
185
Length-Value 3-tuples. New attribute values can be added without
186
disturbing existing implementations of the protocol.
187
188
1.1. Specification of Requirements
189
190
In this document, several words are used to signify the requirements
191
of the specification. These words are often capitalized.
192
193
MUST This word, or the adjective "required", means that the
194
definition is an absolute requirement of the specification.
195
196
MUST NOT This phrase means that the definition is an absolute
197
prohibition of the specification.
198
199
SHOULD This word, or the adjective "recommended", means that there
200
may exist valid reasons in particular circumstances to
201
ignore this item, but the full implications must be
202
understood and carefully weighed before choosing a
203
different course.
204
205
MAY This word, or the adjective "optional", means that this
206
item is one of an allowed set of alternatives. An
207
implementation which does not include this option MUST be
208
prepared to interoperate with another implementation which
209
does include the option.
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
Rigney, et. al. Standards Track [Page 4]
227
228
RFC 2138 RADIUS April 1997
229
230
231
1.2. Terminology
232
233
This document frequently uses the following terms:
234
235
service The NAS provides a service to the dial-in user, such as PPP
236
or Telnet.
237
238
session Each service provided by the NAS to a dial-in user
239
constitutes a session, with the beginning of the session
240
defined as the point where service is first provided and
241
the end of the session defined as the point where service
242
is ended. A user may have multiple sessions in parallel or
243
series if the NAS supports that.
244
245
silently discard
246
This means the implementation discards the packet without
247
further processing. The implementation SHOULD provide the
248
capability of logging the error, including the contents of
249
the silently discarded packet, and SHOULD record the event
250
in a statistics counter.
251
252
2. Operation
253
254
When a client is configured to use RADIUS, any user of the client
255
presents authentication information to the client. This might be
256
with a customizable login prompt, where the user is expected to enter
257
their username and password. Alternatively, the user might use a
258
link framing protocol such as the Point-to-Point Protocol (PPP),
259
which has authentication packets which carry this information.
260
261
Once the client has obtained such information, it may choose to
262
authenticate using RADIUS. To do so, the client creates an "Access-
263
Request" containing such Attributes as the user's name, the user's
264
password, the ID of the client and the Port ID which the user is
265
accessing. When a password is present, it is hidden using a method
266
based on the RSA Message Digest Algorithm MD5 [1].
267
268
The Access-Request is submitted to the RADIUS server via the network.
269
If no response is returned within a length of time, the request is
270
re-sent a number of times. The client can also forward requests to
271
an alternate server or servers in the event that the primary server
272
is down or unreachable. An alternate server can be used either after
273
a number of tries to the primary server fail, or in a round-robin
274
fashion. Retry and fallback algorithms are the topic of current
275
research and are not specified in detail in this document.
276
277
278
279
280
281
282
Rigney, et. al. Standards Track [Page 5]
283
284
RFC 2138 RADIUS April 1997
285
286
287
Once the RADIUS server receives the request, it validates the sending
288
client. A request from a client for which the RADIUS server does not
289
have a shared secret should be silently discarded. If the client is
290
valid, the RADIUS server consults a database of users to find the
291
user whose name matches the request. The user entry in the database
292
contains a list of requirements which must be met to allow access for
293
the user. This always includes verification of the password, but can
294
also specify the client(s) or port(s) to which the user is allowed
295
access.
296
297
The RADIUS server MAY make requests of other servers in order to
298
satisfy the request, in which case it acts as a client.
299
300
If any condition is not met, the RADIUS server sends an "Access-
301
Reject" response indicating that this user request is invalid. If
302
desired, the server MAY include a text message in the Access-Reject
303
which MAY be displayed by the client to the user. No other
304
Attributes are permitted in an Access-Reject.
305
306
If all conditions are met and the RADIUS server wishes to issue a
307
challenge to which the user must respond, the RADIUS server sends an
308
"Access-Challenge" response. It MAY include a text message to be
309
displayed by the client to the user prompting for a response to the
310
challenge, and MAY include a State attribute. If the client receives
311
an Access-Challenge and supports challenge/response it MAY display
312
the text message, if any, to the user, and then prompt the user for a
313
response. The client then re-submits its original Access-Request
314
with a new request ID, with the User-Password Attribute replaced by
315
the response (encrypted), and including the State Attribute from the
316
Access-Challenge, if any. Only 0 or 1 instances of the State
317
Attributes should be present in a request. The server can respond to
318
this new Access-Request with either an Access-Accept, an Access-
319
Reject, or another Access-Challenge.
320
321
If all conditions are met, the list of configuration values for the
322
user are placed into an "Access-Accept" response. These values
323
include the type of service (for example: SLIP, PPP, Login User) and
324
all necessary values to deliver the desired service. For SLIP and
325
PPP, this may include values such as IP address, subnet mask, MTU,
326
desired compression, and desired packet filter identifiers. For
327
character mode users, this may include values such as desired
328
protocol and host.
329
330
331
332
333
334
335
336
337
338
Rigney, et. al. Standards Track [Page 6]
339
340
RFC 2138 RADIUS April 1997
341
342
343
2.1. Challenge/Response
344
345
In challenge/response authentication, the user is given an
346
unpredictable number and challenged to encrypt it and give back the
347
result. Authorized users are equipped with special devices such as
348
smart cards or software that facilitate calculation of the correct
349
response with ease. Unauthorized users, lacking the appropriate
350
device or software and lacking knowledge of the secret key necessary
351
to emulate such a device or software, can only guess at the response.
352
353
The Access-Challenge packet typically contains a Reply-Message
354
including a challenge to be displayed to the user, such as a numeric
355
value unlikely ever to be repeated. Typically this is obtained from
356
an external server that knows what type of authenticator should be in
357
the possession of the authorized user and can therefore choose a
358
random or non-repeating pseudorandom number of an appropriate radix
359
and length.
360
361
The user then enters the challenge into his device (or software) and
362
it calculates a response, which the user enters into the client which
363
forwards it to the RADIUS server via a second Access-Request. If the
364
response matches the expected response the RADIUS server replies with
365
an Access-Accept, otherwise an Access-Reject.
366
367
Example: The NAS sends an Access-Request packet to the RADIUS Server
368
with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
369
just be a fixed string like "challenge" or ignored). The server
370
sends back an Access-Challenge packet with State and a Reply-Message
371
along the lines of "Challenge 12345678, enter your response at the
372
prompt" which the NAS displays. The NAS prompts for the response and
373
sends a NEW Access-Request to the server (with a new ID) with NAS-
374
Identifier, NAS-Port, User-Name, User-Password (the response just
375
entered by the user, encrypted), and the same State Attribute that
376
came with the Access-Challenge. The server then sends back either an
377
Access-Accept or Access-Reject based on whether the response matches
378
what it should be, or it can even send another Access-Challenge.
379
380
2.2. Interoperation with PAP and CHAP
381
382
For PAP, the NAS takes the PAP ID and password and sends them in an
383
Access-Request packet as the User-Name and User-Password. The NAS MAY
384
include the Attributes Service-Type = Framed-User and Framed-Protocol
385
= PPP as a hint to the RADIUS server that PPP service is expected.
386
387
For CHAP, the NAS generates a random challenge (preferably 16 octets)
388
and sends it to the user, who returns a CHAP response along with a
389
CHAP ID and CHAP username. The NAS then sends an Access-Request
390
packet to the RADIUS server with the CHAP username as the User-Name
391
392
393
394
Rigney, et. al. Standards Track [Page 7]
395
396
RFC 2138 RADIUS April 1997
397
398
399
and with the CHAP ID and CHAP response as the CHAP-Password
400
(Attribute 3). The random challenge can either be included in the
401
CHAP-Challenge attribute or, if it is 16 octets long, it can be
402
placed in the Request Authenticator field of the Access-Request
403
packet. The NAS MAY include the Attributes Service-Type = Framed-
404
User and Framed-Protocol = PPP as a hint to the RADIUS server that
405
PPP service is expected.
406
407
The RADIUS server looks up a password based on the User-Name,
408
encrypts the challenge using MD5 on the CHAP ID octet, that password,
409
and the CHAP challenge (from the CHAP-Challenge attribute if present,
410
otherwise from the Request Authenticator), and compares that result
411
to the CHAP-Password. If they match, the server sends back an
412
Access-Accept, otherwise it sends back an Access-Reject.
413
414
If the RADIUS server is unable to perform the requested
415
authentication it should return an Access-Reject. For example, CHAP
416
requires that the user's password be available in cleartext to the
417
server so that it can encrypt the CHAP challenge and compare that to
418
the CHAP response. If the password is not available in cleartext to
419
the RADIUS server then the server MUST send an Access-Reject to the
420
client.
421
422
2.3. Why UDP?
423
424
A frequently asked question is why RADIUS uses UDP instead of TCP as
425
a transport protocol. UDP was chosen for strictly technical reasons.
426
427
There are a number of issues which must be understood. RADIUS is a
428
transaction based protocol which has several interesting
429
characteristics:
430
431
1. If the request to a primary Authentication server fails, a
432
secondary server must be queried.
433
434
To meet this requirement, a copy of the request must be kept
435
above the transport layer to allow for alternate transmission.
436
This means that retransmission timers are still required.
437
438
2. The timing requirements of this particular protocol are
439
significantly different than TCP provides.
440
441
At one extreme, RADIUS does not require a "responsive"
442
detection of lost data. The user is willing to wait several
443
seconds for the authentication to complete. The generally
444
aggressive TCP retransmission (based on average round trip
445
time) is not required, nor is the acknowledgement overhead of
446
TCP.
447
448
449
450
Rigney, et. al. Standards Track [Page 8]
451
452
RFC 2138 RADIUS April 1997
453
454
455
At the other extreme, the user is not willing to wait several
456
minutes for authentication. Therefore the reliable delivery of
457
TCP data two minutes later is not useful. The faster use of an
458
alternate server allows the user to gain access before giving
459
up.
460
461
3. The stateless nature of this protocol simplifies the use of UDP.
462
463
Clients and servers come and go. Systems are rebooted, or are
464
power cycled independently. Generally this does not cause a
465
problem and with creative timeouts and detection of lost TCP
466
connections, code can be written to handle anomalous events.
467
UDP however completely eliminates any of this special handling.
468
Each client and server can open their UDP transport just once
469
and leave it open through all types of failure events on the
470
network.
471
472
4. UDP simplifies the server implementation.
473
474
In the earliest implementations of RADIUS, the server was
475
single threaded. This means that a single request was
476
received, processed, and returned. This was found to be
477
unmanageable in environments where the back-end security
478
mechanism took real time (1 or more seconds). The server
479
request queue would fill and in environments where hundreds of
480
people were being authenticated every minute, the request
481
turn-around time increased to longer that users were willing to
482
wait (this was especially severe when a specific lookup in a
483
database or over DNS took 30 or more seconds). The obvious
484
solution was to make the server multi-threaded. Achieving this
485
was simple with UDP. Separate processes were spawned to serve
486
each request and these processes could respond directly to the
487
client NAS with a simple UDP packet to the original transport
488
of the client.
489
490
It's not all a panacea. As noted, using UDP requires one thing
491
which is built into TCP: with UDP we must artificially manage
492
retransmission timers to the same server, although they don't
493
require the same attention to timing provided by TCP. This one
494
penalty is a small price to pay for the advantages of UDP in
495
this protocol.
496
497
Without TCP we would still probably be using tin cans connected
498
by string. But for this particular protocol, UDP is a better
499
choice.
500
501
502
503
504
505
506
Rigney, et. al. Standards Track [Page 9]
507
508
RFC 2138 RADIUS April 1997
509
510
511
3. Packet Format
512
513
Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
514
where the UDP Destination Port field indicates 1812 (decimal).
515
516
When a reply is generated, the source and destination ports are
517
reversed.
518
519
This memo documents the RADIUS protocol. There has been some
520
confusion in the assignment of port numbers for this protocol. The
521
early deployment of RADIUS was done using the erroneously chosen port
522
number 1645, which conflicts with the "datametrics" service. The
523
officially assigned port number for RADIUS is 1812.
524
525
A summary of the RADIUS data format is shown below. The fields are
526
transmitted from left to right.
527
528
0 1 2 3
529
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
530
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531
| Code | Identifier | Length |
532
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533
| |
534
| Authenticator |
535
| |
536
| |
537
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538
| Attributes ...
539
+-+-+-+-+-+-+-+-+-+-+-+-+-
540
541
Code
542
543
The Code field is one octet, and identifies the type of RADIUS
544
packet. When a packet is received with an invalid Code field, it is
545
silently discarded.
546
547
RADIUS Codes (decimal) are assigned as follows:
548
549
1 Access-Request
550
2 Access-Accept
551
3 Access-Reject
552
4 Accounting-Request
553
5 Accounting-Response
554
11 Access-Challenge
555
12 Status-Server (experimental)
556
13 Status-Client (experimental)
557
255 Reserved
558
559
560
561
562
Rigney, et. al. Standards Track [Page 10]
563
564
RFC 2138 RADIUS April 1997
565
566
567
Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
568
are not further mentioned here. Codes 12 and 13 are reserved for
569
possible use, but are not further mentioned here.
570
571
Identifier
572
573
The Identifier field is one octet, and aids in matching requests and
574
replies.
575
576
Length
577
578
The Length field is two octets. It indicates the length of the
579
packet including the Code, Identifier, Length, Authenticator and
580
Attribute fields. Octets outside the range of the Length field
581
should be treated as padding and should be ignored on reception. If
582
the packet is shorter than the Length field indicates, it should be
583
silently discarded. The minimum length is 20 and maximum length is
584
4096.
585
586
Authenticator
587
588
The Authenticator field is sixteen (16) octets. The most significant
589
octet is transmitted first. This value is used to authenticate the
590
reply from the RADIUS server, and is used in the password hiding
591
algorithm.
592
593
Request Authenticator
594
595
In Access-Request Packets, the Authenticator value is a 16 octet
596
random number, called the Request Authenticator. The value SHOULD
597
be unpredictable and unique over the lifetime of a secret (the
598
password shared between the client and the RADIUS server), since
599
repetition of a request value in conjunction with the same secret
600
would permit an attacker to reply with a previously intercepted
601
response. Since it is expected that the same secret MAY be used
602
to authenticate with servers in disparate geographic regions, the
603
Request Authenticator field SHOULD exhibit global and temporal
604
uniqueness.
605
606
The Request Authenticator value in an Access-Request packet SHOULD
607
also be unpredictable, lest an attacker trick a server into
608
responding to a predicted future request, and then use the
609
response to masquerade as that server to a future Access-Request.
610
611
612
613
614
615
616
617
618
Rigney, et. al. Standards Track [Page 11]
619
620
RFC 2138 RADIUS April 1997
621
622
623
Although protocols such as RADIUS are incapable of protecting
624
against theft of an authenticated session via realtime active
625
wiretapping attacks, generation of unique unpredictable requests
626
can protect against a wide range of active attacks against
627
authentication.
628
629
The NAS and RADIUS server share a secret. That shared secret
630
followed by the Request Authenticator is put through a one-way MD5
631
hash to create a 16 octet digest value which is xored with the
632
password entered by the user, and the xored result placed in the
633
User-Password attribute in the Access-Request packet. See the
634
entry for User-Password in the section on Attributes for a more
635
detailed description.
636
637
Response Authenticator
638
639
The value of the Authenticator field in Access-Accept, Access-
640
Reject, and Access-Challenge packets is called the Response
641
Authenticator, and contains a one-way MD5 hash calculated over a
642
stream of octets consisting of: the RADIUS packet, beginning with
643
the Code field, including the Identifier, the Length, the Request
644
Authenticator field from the Access-Request packet, and the
645
response Attributes, followed by the shared secret. That is,
646
ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
647
where + denotes concatenation.
648
649
Administrative Note
650
651
The secret (password shared between the client and the RADIUS server)
652
SHOULD be at least as large and unguessable as a well-chosen
653
password. It is preferred that the secret be at least 16 octets.
654
This is to ensure a sufficiently large range for the secret to
655
provide protection against exhaustive search attacks. A RADIUS
656
server SHOULD use the source IP address of the RADIUS UDP packet to
657
decide which shared secret to use, so that RADIUS requests can be
658
proxied.
659
660
When using a forwarding proxy, the proxy must be able to alter the
661
packet as it passes through in each direction - when the proxy
662
forwards the request, the proxy can add a Proxy-State Attribute, and
663
when the proxy forwards a response, it removes the Proxy-State
664
Attribute. Since Access-Accept and Access-Reject replies are
665
authenticated on the entire packet contents, the stripping of the
666
Proxy-State attribute would invalidate the signature in the packet -
667
so the proxy has to re-sign it.
668
669
Further details of RADIUS proxy implementation are outside the scope
670
of this document.
671
672
673
674
Rigney, et. al. Standards Track [Page 12]
675
676
RFC 2138 RADIUS April 1997
677
678
679
Attributes
680
681
Many Attributes may have multiple instances, in such a case the order
682
of Attributes of the same Type SHOULD be preserved. The order of
683
Attributes of different Types is not required to be preserved.
684
685
In the section below on "Attributes" where the text refers to which
686
packets an attribute is allowed in, only packets with Codes 1, 2, 3
687
and 11 and attributes defined in this document are covered in this
688
document. A summary table is provided at the end of the "Attributes"
689
section. To determine which Attributes are allowed in packets with
690
codes 4 and 5 refer to the RADIUS Accounting document [9].
691
692
4. Packet Types
693
694
The RADIUS Packet type is determined by the Code field in the first
695
octet of the Packet.
696
697
4.1. Access-Request
698
699
Description
700
701
Access-Request packets are sent to a RADIUS server, and convey
702
information used to determine whether a user is allowed access to
703
a specific NAS, and any special services requested for that user.
704
An implementation wishing to authenticate a user MUST transmit a
705
RADIUS packet with the Code field set to 1 (Access-Request).
706
707
Upon receipt of an Access-Request from a valid client, an
708
appropriate reply MUST be transmitted.
709
710
An Access-Request MUST contain a User-Name attribute. It SHOULD
711
contain either a NAS-IP-Address attribute or NAS-Identifier
712
attribute (or both, although that is not recommended). It MUST
713
contain either a User-Password attribute or CHAP-Password
714
attribute. It SHOULD contain a NAS-Port or NAS-Port-Type
715
attribute or both unless the type of access being requested does
716
not involve a port or the NAS does not distinguish among its
717
ports.
718
719
An Access-Request MAY contain additional attributes as a hint to
720
the server, but the server is not required to honor the hint.
721
722
When a User-Password is present, it is hidden using a method based
723
on the RSA Message Digest Algorithm MD5 [1].
724
725
A summary of the Access-Request packet format is shown below. The
726
fields are transmitted from left to right.
727
728
729
730
Rigney, et. al. Standards Track [Page 13]
731
732
RFC 2138 RADIUS April 1997
733
734
735
0 1 2 3
736
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
737
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738
| Code | Identifier | Length |
739
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740
| |
741
| Request Authenticator |
742
| |
743
| |
744
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745
| Attributes ...
746
+-+-+-+-+-+-+-+-+-+-+-+-+-
747
748
Code
749
750
1 for Access-Request.
751
752
Identifier
753
754
The Identifier field MUST be changed whenever the content of the
755
Attributes field changes, and whenever a valid reply has been
756
received for a previous request. For retransmissions, the
757
Identifier MUST remain unchanged.
758
759
Request Authenticator
760
761
The Request Authenticator value MUST be changed each time a new
762
Identifier is used.
763
764
Attributes
765
766
The Attribute field is variable in length, and contains the list
767
of Attributes that are required for the type of service, as well
768
as any desired optional Attributes.
769
770
4.2. Access-Accept
771
772
Description
773
774
Access-Accept packets are sent by the RADIUS server, and provide
775
specific configuration information necessary to begin delivery of
776
service to the user. If all Attribute values received in an
777
Access-Request are acceptable then the RADIUS implementation MUST
778
transmit a packet with the Code field set to 2 (Access-Accept).
779
780
781
782
783
784
785
786
Rigney, et. al. Standards Track [Page 14]
787
788
RFC 2138 RADIUS April 1997
789
790
791
On reception of an Access-Accept, the Identifier field is matched
792
with a pending Access-Request. Additionally, the Response
793
Authenticator field MUST contain the correct response for the
794
pending Access-Request. Invalid packets are silently discarded.
795
796
A summary of the Access-Accept packet format is shown below. The
797
fields are transmitted from left to right.
798
799
0 1 2 3
800
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
801
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802
| Code | Identifier | Length |
803
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804
| |
805
| Response Authenticator |
806
| |
807
| |
808
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
809
| Attributes ...
810
+-+-+-+-+-+-+-+-+-+-+-+-+-
811
812
Code
813
814
2 for Access-Accept.
815
816
Identifier
817
818
The Identifier field is a copy of the Identifier field of the
819
Access-Request which caused this Access-Accept.
820
821
Response Authenticator
822
823
The Response Authenticator value is calculated from the Access-
824
Request value, as described earlier.
825
826
Attributes
827
828
The Attribute field is variable in length, and contains a list of
829
zero or more Attributes.
830
831
832
833
834
835
836
837
838
839
840
841
842
Rigney, et. al. Standards Track [Page 15]
843
844
RFC 2138 RADIUS April 1997
845
846
847
4.3. Access-Reject
848
849
Description
850
851
If any value of the received Attributes is not acceptable, then
852
the RADIUS server MUST transmit a packet with the Code field set
853
to 3 (Access-Reject). It MAY include one or more Reply-Message
854
Attributes with a text message which the NAS MAY display to the
855
user.
856
857
A summary of the Access-Reject packet format is shown below. The
858
fields are transmitted from left to right.
859
860
0 1 2 3
861
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
862
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
863
| Code | Identifier | Length |
864
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
865
| |
866
| Response Authenticator |
867
| |
868
| |
869
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
870
| Attributes ...
871
+-+-+-+-+-+-+-+-+-+-+-+-+-
872
873
Code
874
875
3 for Access-Reject.
876
877
Identifier
878
879
The Identifier field is a copy of the Identifier field of the
880
Access-Request which caused this Access-Reject.
881
882
Response Authenticator
883
884
The Response Authenticator value is calculated from the Access-
885
Request value, as described earlier.
886
887
Attributes
888
889
The Attribute field is variable in length, and contains a list of
890
zero or more Attributes.
891
892
893
894
895
896
897
898
Rigney, et. al. Standards Track [Page 16]
899
900
RFC 2138 RADIUS April 1997
901
902
903
4.4. Access-Challenge
904
905
Description
906
907
If the RADIUS server desires to send the user a challenge
908
requiring a response, then the RADIUS server MUST respond to the
909
Access-Request by transmitting a packet with the Code field set to
910
11 (Access-Challenge).
911
912
The Attributes field MAY have one or more Reply-Message
913
Attributes, and MAY have a single State Attribute, or none. No
914
other Attributes are permitted in an Access-Challenge.
915
916
On receipt of an Access-Challenge, the Identifier field is matched
917
with a pending Access-Request. Additionally, the Response
918
Authenticator field MUST contain the correct response for the
919
pending Access-Request. Invalid packets are silently discarded.
920
921
If the NAS does not support challenge/response, it MUST treat an
922
Access-Challenge as though it had received an Access-Reject
923
instead.
924
925
If the NAS supports challenge/response, receipt of a valid
926
Access-Challenge indicates that a new Access-Request SHOULD be
927
sent. The NAS MAY display the text message, if any, to the user,
928
and then prompt the user for a response. It then sends its
929
original Access-Request with a new request ID and Request
930
Authenticator, with the User-Password Attribute replaced by the
931
user's response (encrypted), and including the State Attribute
932
from the Access-Challenge, if any. Only 0 or 1 instances of the
933
State Attribute can be present in an Access-Request.
934
935
A NAS which supports PAP MAY forward the Reply-Message to the
936
dialin client and accept a PAP response which it can use as though
937
the user had entered the response. If the NAS cannot do so, it
938
should treat the Access-Challenge as though it had received an
939
Access-Reject instead.
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
Rigney, et. al. Standards Track [Page 17]
955
956
RFC 2138 RADIUS April 1997
957
958
959
A summary of the Access-Challenge packet format is shown below. The
960
fields are transmitted from left to right.
961
962
0 1 2 3
963
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
964
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
965
| Code | Identifier | Length |
966
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
967
| |
968
| Response Authenticator |
969
| |
970
| |
971
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
972
| Attributes ...
973
+-+-+-+-+-+-+-+-+-+-+-+-+-
974
975
Code
976
977
11 for Access-Challenge.
978
979
Identifier
980
981
The Identifier field is a copy of the Identifier field of the
982
Access-Request which caused this Access-Challenge.
983
984
Response Authenticator
985
986
The Response Authenticator value is calculated from the Access-
987
Request value, as described earlier.
988
989
Attributes
990
991
The Attributes field is variable in length, and contains a list of
992
zero or more Attributes.
993
994
5. Attributes
995
996
RADIUS Attributes carry the specific authentication, authorization,
997
information and configuration details for the request and reply.
998
999
Some Attributes MAY be included more than once. The effect of this
1000
is Attribute specific, and is specified in each Attribute
1001
description.
1002
1003
The end of the list of Attributes is indicated by the Length of the
1004
RADIUS packet.
1005
1006
1007
1008
1009
1010
Rigney, et. al. Standards Track [Page 18]
1011
1012
RFC 2138 RADIUS April 1997
1013
1014
1015
A summary of the Attribute format is shown below. The fields are
1016
transmitted from left to right.
1017
1018
0 1 2
1019
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1020
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1021
| Type | Length | Value ...
1022
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1023
1024
Type
1025
1026
The Type field is one octet. Up-to-date values of the RADIUS Type
1027
field are specified in the most recent "Assigned Numbers" RFC [3].
1028
Values 192-223 are reserved for experimental use, values 224-240
1029
are reserved for implementation-specific use, and values 241-255
1030
are reserved and should not be used. This specification concerns
1031
the following values:
1032
1033
A RADIUS server MAY ignore Attributes with an unknown Type.
1034
1035
A RADIUS client MAY ignore Attributes with an unknown Type.
1036
1037
1 User-Name
1038
2 User-Password
1039
3 CHAP-Password
1040
4 NAS-IP-Address
1041
5 NAS-Port
1042
6 Service-Type
1043
7 Framed-Protocol
1044
8 Framed-IP-Address
1045
9 Framed-IP-Netmask
1046
10 Framed-Routing
1047
11 Filter-Id
1048
12 Framed-MTU
1049
13 Framed-Compression
1050
14 Login-IP-Host
1051
15 Login-Service
1052
16 Login-TCP-Port
1053
17 (unassigned)
1054
18 Reply-Message
1055
19 Callback-Number
1056
20 Callback-Id
1057
21 (unassigned)
1058
22 Framed-Route
1059
23 Framed-IPX-Network
1060
24 State
1061
25 Class
1062
26 Vendor-Specific
1063
1064
1065
1066
Rigney, et. al. Standards Track [Page 19]
1067
1068
RFC 2138 RADIUS April 1997
1069
1070
1071
27 Session-Timeout
1072
28 Idle-Timeout
1073
29 Termination-Action
1074
30 Called-Station-Id
1075
31 Calling-Station-Id
1076
32 NAS-Identifier
1077
33 Proxy-State
1078
34 Login-LAT-Service
1079
35 Login-LAT-Node
1080
36 Login-LAT-Group
1081
37 Framed-AppleTalk-Link
1082
38 Framed-AppleTalk-Network
1083
39 Framed-AppleTalk-Zone
1084
40-59 (reserved for accounting)
1085
60 CHAP-Challenge
1086
61 NAS-Port-Type
1087
62 Port-Limit
1088
63 Login-LAT-Port
1089
1090
Length
1091
1092
The Length field is one octet, and indicates the length of this
1093
Attribute including the Type, Length and Value fields. If an
1094
Attribute is received in an Access-Request but with an invalid
1095
Length, an Access-Reject SHOULD be transmitted. If an Attribute
1096
is received in an Access-Accept, Access-Reject or Access-Challenge
1097
packet with an invalid length, the packet MUST either be treated
1098
an Access-Reject or else silently discarded.
1099
1100
Value
1101
1102
The Value field is zero or more octets and contains information
1103
specific to the Attribute. The format and length of the Value
1104
field is determined by the Type and Length fields.
1105
1106
Note that a "string" in RADIUS does not require termination by an
1107
ASCII NUL because the Attribute already has a length field.
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
Rigney, et. al. Standards Track [Page 20]
1123
1124
RFC 2138 RADIUS April 1997
1125
1126
1127
The format of the value field is one of four data types.
1128
1129
string 0-253 octets
1130
1131
address 32 bit value, most significant octet first.
1132
1133
integer 32 bit value, most significant octet first.
1134
1135
time 32 bit value, most significant octet first -- seconds
1136
since 00:00:00 GMT, January 1, 1970. The standard
1137
Attributes do not use this data type but it is presented
1138
here for possible use within Vendor-Specific attributes.
1139
1140
1141
5.1. User-Name
1142
1143
Description
1144
1145
This Attribute indicates the name of the user to be authenticated.
1146
It is only used in Access-Request packets.
1147
1148
A summary of the User-Name Attribute format is shown below. The
1149
fields are transmitted from left to right.
1150
1151
0 1 2
1152
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1153
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1154
| Type | Length | String ...
1155
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1156
1157
Type
1158
1159
1 for User-Name.
1160
1161
Length
1162
1163
>= 3
1164
1165
String
1166
1167
The String field is one or more octets. The NAS may limit the
1168
maximum length of the User-Name but the ability to handle at least
1169
63 octets is recommended.
1170
1171
1172
1173
1174
1175
1176
1177
1178
Rigney, et. al. Standards Track [Page 21]
1179
1180
RFC 2138 RADIUS April 1997
1181
1182
1183
The format of the username MAY be one of several forms:
1184
1185
monolithic Consisting only of alphanumeric characters. This
1186
simple form might be used to locally manage a NAS.
1187
1188
simple Consisting only of printable ASCII characters.
1189
1190
name@fqdn SMTP address. The Fully Qualified Domain Name (with or
1191
without trailing dot) indicates the realm in which the
1192
name part applies.
1193
1194
distinguished name
1195
A name in ASN.1 form used in Public Key authentication
1196
systems.
1197
1198
5.2. User-Password
1199
1200
Description
1201
1202
This Attribute indicates the password of the user to be
1203
authenticated, or the user's input following an Access-Challenge.
1204
It is only used in Access-Request packets.
1205
1206
On transmission, the password is hidden. The password is first
1207
padded at the end with nulls to a multiple of 16 octets. A one-
1208
way MD5 hash is calculated over a stream of octets consisting of
1209
the shared secret followed by the Request Authenticator. This
1210
value is XORed with the first 16 octet segment of the password and
1211
placed in the first 16 octets of the String field of the User-
1212
Password Attribute.
1213
1214
If the password is longer than 16 characters, a second one-way MD5
1215
hash is calculated over a stream of octets consisting of the
1216
shared secret followed by the result of the first xor. That hash
1217
is XORed with the second 16 octet segment of the password and
1218
placed in the second 16 octets of the String field of the User-
1219
Password Attribute.
1220
1221
If necessary, this operation is repeated, with each xor result
1222
being used along with the shared secret to generate the next hash
1223
to xor the next segment of the password, to no more than 128
1224
characters.
1225
1226
The method is taken from the book "Network Security" by Kaufman,
1227
Perlman and Speciner [4] pages 109-110. A more precise
1228
explanation of the method follows:
1229
1230
1231
1232
1233
1234
Rigney, et. al. Standards Track [Page 22]
1235
1236
RFC 2138 RADIUS April 1997
1237
1238
1239
Call the shared secret S and the pseudo-random 128-bit Request
1240
Authenticator RA. Break the password into 16-octet chunks p1, p2,
1241
etc. with the last one padded at the end with nulls to a 16-octet
1242
boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
1243
intermediate values b1, b2, etc.
1244
1245
b1 = MD5(S + RA) c(1) = p1 xor b1
1246
b2 = MD5(S + c(1)) c(2) = p2 xor b2
1247
. .
1248
. .
1249
. .
1250
bi = MD5(S + c(i-1)) c(i) = pi xor bi
1251
1252
The String will contain c(1)+c(2)+...+c(i) where + denotes
1253
concatenation.
1254
1255
On receipt, the process is reversed to yield the original
1256
password.
1257
1258
A summary of the User-Password Attribute format is shown below. The
1259
fields are transmitted from left to right.
1260
1261
0 1 2
1262
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1263
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1264
| Type | Length | String ...
1265
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1266
1267
Type
1268
1269
2 for User-Password.
1270
1271
Length
1272
1273
At least 18 and no larger than 130.
1274
1275
String
1276
1277
The String field is between 16 and 128 octets long, inclusive.
1278
1279
5.3. CHAP-Password
1280
1281
Description
1282
1283
This Attribute indicates the response value provided by a PPP
1284
Challenge-Handshake Authentication Protocol (CHAP) user in
1285
response to the challenge. It is only used in Access-Request
1286
packets.
1287
1288
1289
1290
Rigney, et. al. Standards Track [Page 23]
1291
1292
RFC 2138 RADIUS April 1997
1293
1294
1295
The CHAP challenge value is found in the CHAP-Challenge Attribute
1296
(60) if present in the packet, otherwise in the Request
1297
Authenticator field.
1298
1299
A summary of the CHAP-Password Attribute format is shown below. The
1300
fields are transmitted from left to right.
1301
1302
0 1 2
1303
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
1304
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1305
| Type | Length | CHAP Ident | String ...
1306
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1307
1308
Type
1309
1310
3 for CHAP-Password.
1311
1312
Length
1313
1314
19
1315
1316
CHAP Ident
1317
1318
This field is one octet, and contains the CHAP Identifier from the
1319
user's CHAP Response.
1320
1321
String
1322
1323
The String field is 16 octets, and contains the CHAP Response from
1324
the user.
1325
1326
5.4. NAS-IP-Address
1327
1328
Description
1329
1330
This Attribute indicates the identifying IP Address of the NAS
1331
which is requesting authentication of the user. It is only used
1332
in Access-Request packets. Either NAS-IP-Address or NAS-
1333
Identifier SHOULD be present in an Access-Request packet.
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
Rigney, et. al. Standards Track [Page 24]
1347
1348
RFC 2138 RADIUS April 1997
1349
1350
1351
A summary of the NAS-IP-Address Attribute format is shown below. The
1352
fields are transmitted from left to right.
1353
1354
0 1 2 3
1355
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
1356
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1357
| Type | Length | Address
1358
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1359
Address (cont) |
1360
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1361
1362
Type
1363
1364
4 for NAS-IP-Address.
1365
1366
Length
1367
1368
6
1369
1370
Address
1371
1372
The Address field is four octets.
1373
1374
5.5. NAS-Port
1375
1376
Description
1377
1378
This Attribute indicates the physical port number of the NAS which
1379
is authenticating the user. It is only used in Access-Request
1380
packets. Note that this is using "port" in its sense of a
1381
physical connection on the NAS, not in the sense of a TCP or UDP
1382
port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
1383
be present in an Access-Request packet, if the NAS differentiates
1384
among its ports.
1385
1386
A summary of the NAS-Port Attribute format is shown below. The
1387
fields are transmitted from left to right.
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
Rigney, et. al. Standards Track [Page 25]
1403
1404
RFC 2138 RADIUS April 1997
1405
1406
1407
0 1 2 3
1408
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
1409
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1410
| Type | Length | Value
1411
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1412
Value (cont) |
1413
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1414
1415
Type
1416
1417
5 for NAS-Port.
1418
1419
Length
1420
1421
6
1422
1423
Value
1424
1425
The Value field is four octets. Despite the size of the field,
1426
values range from 0 to 65535.
1427
1428
5.6. Service-Type
1429
1430
Description
1431
1432
This Attribute indicates the type of service the user has
1433
requested, or the type of service to be provided. It MAY be used
1434
in both Access-Request and Access-Accept packets. A NAS is not
1435
required to implement all of these service types, and MUST treat
1436
unknown or unsupported Service-Types as though an Access-Reject
1437
had been received instead.
1438
1439
A summary of the Service-Type Attribute format is shown below. The
1440
fields are transmitted from left to right.
1441
1442
0 1 2 3
1443
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
1444
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1445
| Type | Length | Value
1446
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1447
Value (cont) |
1448
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1449
1450
Type
1451
1452
6 for Service-Type.
1453
1454
1455
1456
1457
1458
Rigney, et. al. Standards Track [Page 26]
1459
1460
RFC 2138 RADIUS April 1997
1461
1462
1463
Length
1464
1465
6
1466
1467
Value
1468
1469
The Value field is four octets.
1470
1471
1 Login
1472
2 Framed
1473
3 Callback Login
1474
4 Callback Framed
1475
5 Outbound
1476
6 Administrative
1477
7 NAS Prompt
1478
8 Authenticate Only
1479
9 Callback NAS Prompt
1480
1481
1482
The service types are defined as follows when used in an Access-
1483
Accept. When used in an Access-Request, they should be considered
1484
to be a hint to the RADIUS server that the NAS has reason to
1485
believe the user would prefer the kind of service indicated, but
1486
the server is not required to honor the hint.
1487
1488
Login The user should be connected to a host.
1489
1490
Framed A Framed Protocol should be started for the
1491
User, such as PPP or SLIP.
1492
1493
Callback Login The user should be disconnected and called
1494
back, then connected to a host.
1495
1496
Callback Framed The user should be disconnected and called
1497
back, then a Framed Protocol should be started
1498
for the User, such as PPP or SLIP.
1499
1500
Outbound The user should be granted access to outgoing
1501
devices.
1502
1503
Administrative The user should be granted access to the
1504
administrative interface to the NAS from which
1505
privileged commands can be executed.
1506
1507
NAS Prompt The user should be provided a command prompt
1508
on the NAS from which non-privileged commands
1509
can be executed.
1510
1511
1512
1513
1514
Rigney, et. al. Standards Track [Page 27]
1515
1516
RFC 2138 RADIUS April 1997
1517
1518
1519
Authenticate Only Only Authentication is requested, and no
1520
authorization information needs to be returned
1521
in the Access-Accept (typically used by proxy
1522
servers rather than the NAS itself).
1523
1524
Callback NAS Prompt The user should be disconnected and called
1525
back, then provided a command prompt on the
1526
NAS from which non-privileged commands can be
1527
executed.
1528
1529
5.7. Framed-Protocol
1530
1531
Description
1532
1533
This Attribute indicates the framing to be used for framed access.
1534
It MAY be used in both Access-Request and Access-Accept packets.
1535
1536
A summary of the Framed-Protocol Attribute format is shown below.
1537
The fields are transmitted from left to right.
1538
1539
0 1 2 3
1540
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
1541
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1542
| Type | Length | Value
1543
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1544
Value (cont) |
1545
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1546
1547
Type
1548
1549
7 for Framed-Protocol.
1550
1551
Length
1552
1553
6
1554
1555
Value
1556
1557
The Value field is four octets.
1558
1559
1 PPP
1560
2 SLIP
1561
3 AppleTalk Remote Access Protocol (ARAP)
1562
4 Gandalf proprietary SingleLink/MultiLink protocol
1563
5 Xylogics proprietary IPX/SLIP
1564
1565
1566
1567
1568
1569
1570
Rigney, et. al. Standards Track [Page 28]
1571
1572
RFC 2138 RADIUS April 1997
1573
1574
1575
5.8. Framed-IP-Address
1576
1577
Description
1578
1579
This Attribute indicates the address to be configured for the
1580
user. It MAY be used in Access-Accept packets. It MAY be used in
1581
an Access-Request packet as a hint by the NAS to the server that
1582
it would prefer that address, but the server is not required to
1583
honor the hint.
1584
1585
A summary of the Framed-IP-Address Attribute format is shown below.
1586
The fields are transmitted from left to right.
1587
1588
0 1 2 3
1589
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
1590
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1591
| Type | Length | Address
1592
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1593
Address (cont) |
1594
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1595
1596
Type
1597
1598
8 for Framed-IP-Address.
1599
1600
Length
1601
1602
6
1603
1604
Address
1605
1606
The Address field is four octets. The value 0xFFFFFFFF indicates
1607
that the NAS should allow the user to select an address (e.g.
1608
Negotiated). The value 0xFFFFFFFE indicates that the NAS should
1609
select an address for the user (e.g. Assigned from a pool of
1610
addresses kept by the NAS). Other valid values indicate that the
1611
NAS should use that value as the user's IP address.
1612
1613
5.9. Framed-IP-Netmask
1614
1615
Description
1616
1617
This Attribute indicates the IP netmask to be configured for the
1618
user when the user is a router to a network. It MAY be used in
1619
Access-Accept packets. It MAY be used in an Access-Request packet
1620
as a hint by the NAS to the server that it would prefer that
1621
netmask, but the server is not required to honor the hint.
1622
1623
1624
1625
1626
Rigney, et. al. Standards Track [Page 29]
1627
1628
RFC 2138 RADIUS April 1997
1629
1630
1631
A summary of the Framed-IP-Netmask Attribute format is shown below.
1632
The fields are transmitted from left to right.
1633
1634
0 1 2 3
1635
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
1636
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1637
| Type | Length | Address
1638
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1639
Address (cont) |
1640
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1641
1642
Type
1643
1644
9 for Framed-IP-Netmask.
1645
1646
Length
1647
1648
6
1649
1650
Address
1651
1652
The Address field is four octets specifying the IP netmask of the
1653
user.
1654
1655
5.10. Framed-Routing
1656
1657
Description
1658
1659
This Attribute indicates the routing method for the user, when the
1660
user is a router to a network. It is only used in Access-Accept
1661
packets.
1662
1663
A summary of the Framed-Routing Attribute format is shown below. The
1664
fields are transmitted from left to right.
1665
1666
0 1 2 3
1667
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
1668
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1669
| Type | Length | Value
1670
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1671
Value (cont) |
1672
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1673
1674
Type
1675
1676
10 for Framed-Routing.
1677
1678
1679
1680
1681
1682
Rigney, et. al. Standards Track [Page 30]
1683
1684
RFC 2138 RADIUS April 1997
1685
1686
1687
Length
1688
1689
6
1690
1691
Value
1692
1693
The Value field is four octets.
1694
1695
0 None
1696
1 Send routing packets
1697
2 Listen for routing packets
1698
3 Send and Listen
1699
1700
5.11. Filter-Id
1701
1702
Description
1703
1704
This Attribute indicates the name of the filter list for this
1705
user. Zero or more Filter-Id attributes MAY be sent in an
1706
Access-Accept packet.
1707
1708
Identifying a filter list by name allows the filter to be used on
1709
different NASes without regard to filter-list implementation
1710
details.
1711
1712
A summary of the Filter-Id Attribute format is shown below. The
1713
fields are transmitted from left to right.
1714
1715
0 1 2
1716
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1717
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1718
| Type | Length | String ...
1719
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1720
1721
Type
1722
1723
11 for Filter-Id.
1724
1725
Length
1726
1727
>= 3
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
Rigney, et. al. Standards Track [Page 31]
1739
1740
RFC 2138 RADIUS April 1997
1741
1742
1743
String
1744
1745
The String field is one or more octets, and its contents are
1746
implementation dependent. It is intended to be human readable and
1747
MUST NOT affect operation of the protocol. It is recommended that
1748
the message contain displayable ASCII characters from the range 32
1749
through 126 decimal.
1750
1751
5.12. Framed-MTU
1752
1753
Description
1754
1755
This Attribute indicates the Maximum Transmission Unit to be
1756
configured for the user, when it is not negotiated by some other
1757
means (such as PPP). It is only used in Access-Accept packets.
1758
1759
A summary of the Framed-MTU Attribute format is shown below. The
1760
fields are transmitted from left to right.
1761
1762
0 1 2 3
1763
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
1764
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1765
| Type | Length | Value
1766
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1767
Value (cont) |
1768
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1769
1770
Type
1771
1772
12 for Framed-MTU.
1773
1774
Length
1775
1776
6
1777
1778
Value
1779
1780
The Value field is four octets. Despite the size of the field,
1781
values range from 64 to 65535.
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
Rigney, et. al. Standards Track [Page 32]
1795
1796
RFC 2138 RADIUS April 1997
1797
1798
1799
5.13. Framed-Compression
1800
1801
Description
1802
1803
This Attribute indicates a compression protocol to be used for the
1804
link. It MAY be used in Access-Accept packets. It MAY be used in
1805
an Access-Request packet as a hint to the server that the NAS
1806
would prefer to use that compression, but the server is not
1807
required to honor the hint.
1808
1809
More than one compression protocol Attribute MAY be sent. It is
1810
the responsibility of the NAS to apply the proper compression
1811
protocol to appropriate link traffic.
1812
1813
A summary of the Framed-Compression Attribute format is shown below.
1814
The fields are transmitted from left to right.
1815
1816
0 1 2 3
1817
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
1818
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1819
| Type | Length | Value
1820
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1821
Value (cont) |
1822
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1823
1824
Type
1825
1826
13 for Framed-Compression.
1827
1828
Length
1829
1830
6
1831
1832
Value
1833
1834
The Value field is four octets.
1835
1836
0 None
1837
1 VJ TCP/IP header compression [5]
1838
2 IPX header compression
1839
1840
5.14. Login-IP-Host
1841
1842
Description
1843
1844
This Attribute indicates the system with which to connect the
1845
user, when the Login-Service Attribute is included. It MAY be
1846
used in Access-Accept packets. It MAY be used in an Access-
1847
1848
1849
1850
Rigney, et. al. Standards Track [Page 33]
1851
1852
RFC 2138 RADIUS April 1997
1853
1854
1855
Request packet as a hint to the server that the NAS would prefer
1856
to use that host, but the server is not required to honor the
1857
hint.
1858
1859
A summary of the Login-IP-Host Attribute format is shown below. The
1860
fields are transmitted from left to right.
1861
1862
0 1 2 3
1863
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
1864
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1865
| Type | Length | Address
1866
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1867
Address (cont) |
1868
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1869
1870
Type
1871
1872
14 for Login-IP-Host.
1873
1874
Length
1875
1876
6
1877
1878
Address
1879
1880
The Address field is four octets. The value 0xFFFFFFFF indicates
1881
that the NAS SHOULD allow the user to select an address. The
1882
value 0 indicates that the NAS SHOULD select a host to connect the
1883
user to. Other values indicate the address the NAS SHOULD connect
1884
the user to.
1885
1886
5.15. Login-Service
1887
1888
Description
1889
1890
This Attribute indicates the service which should be used to
1891
connect the user to the login host. It is only used in Access-
1892
Accept packets.
1893
1894
A summary of the Login-Service Attribute format is shown below. The
1895
fields are transmitted from left to right.
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
Rigney, et. al. Standards Track [Page 34]
1907
1908
RFC 2138 RADIUS April 1997
1909
1910
1911
0 1 2 3
1912
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
1913
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1914
| Type | Length | Value
1915
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1916
Value (cont) |
1917
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1918
1919
Type
1920
1921
15 for Login-Service.
1922
1923
Length
1924
1925
6
1926
1927
Value
1928
1929
The Value field is four octets.
1930
1931
0 Telnet
1932
1 Rlogin
1933
2 TCP Clear
1934
3 PortMaster (proprietary)
1935
4 LAT
1936
1937
5.16. Login-TCP-Port
1938
1939
Description
1940
1941
This Attribute indicates the TCP port with which the user is to be
1942
connected, when the Login-Service Attribute is also present. It
1943
is only used in Access-Accept packets.
1944
1945
A summary of the Login-TCP-Port Attribute format is shown below. The
1946
fields are transmitted from left to right.
1947
1948
0 1 2 3
1949
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
1950
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1951
| Type | Length | Value
1952
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1953
Value (cont) |
1954
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1955
1956
Type
1957
1958
16 for Login-TCP-Port.
1959
1960
1961
1962
Rigney, et. al. Standards Track [Page 35]
1963
1964
RFC 2138 RADIUS April 1997
1965
1966
1967
Length
1968
1969
6
1970
1971
Value
1972
1973
The Value field is four octets. Despite the size of the field,
1974
values range from 0 to 65535.
1975
1976
5.17. (unassigned)
1977
1978
Description
1979
1980
ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
1981
1982
5.18. Reply-Message
1983
1984
Description
1985
1986
This Attribute indicates text which MAY be displayed to the user.
1987
1988
When used in an Access-Accept, it is the success message.
1989
1990
When used in an Access-Reject, it is the failure message. It MAY
1991
indicate a dialog message to prompt the user before another
1992
Access-Request attempt.
1993
1994
When used in an Access-Challenge, it MAY indicate a dialog message
1995
to prompt the user for a response.
1996
1997
Multiple Reply-Message's MAY be included and if any are displayed,
1998
they MUST be displayed in the same order as they appear in the
1999
packet.
2000
2001
A summary of the Reply-Message Attribute format is shown below. The
2002
fields are transmitted from left to right.
2003
2004
0 1 2
2005
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2007
| Type | Length | String ...
2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2009
2010
2011
Type
2012
2013
18 for Reply-Message.
2014
2015
2016
2017
2018
Rigney, et. al. Standards Track [Page 36]
2019
2020
RFC 2138 RADIUS April 1997
2021
2022
2023
Length
2024
2025
>= 3
2026
2027
String
2028
2029
The String field is one or more octets, and its contents are
2030
implementation dependent. It is intended to be human readable,
2031
and MUST NOT affect operation of the protocol. It is recommended
2032
that the message contain displayable ASCII characters from the
2033
range 10, 13, and 32 through 126 decimal. Mechanisms for
2034
extension to other character sets are beyond the scope of this
2035
specification.
2036
2037
5.19. Callback-Number
2038
2039
Description
2040
2041
This Attribute indicates a dialing string to be used for callback.
2042
It MAY be used in Access-Accept packets. It MAY be used in an
2043
Access-Request packet as a hint to the server that a Callback
2044
service is desired, but the server is not required to honor the
2045
hint.
2046
2047
A summary of the Callback-Number Attribute format is shown below.
2048
The fields are transmitted from left to right.
2049
2050
0 1 2
2051
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2052
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2053
| Type | Length | String ...
2054
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2055
2056
Type
2057
2058
19 for Callback-Number.
2059
2060
Length
2061
2062
>= 3
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
Rigney, et. al. Standards Track [Page 37]
2075
2076
RFC 2138 RADIUS April 1997
2077
2078
2079
String
2080
2081
The String field is one or more octets. The actual format of the
2082
information is site or application specific, and a robust
2083
implementation SHOULD support the field as undistinguished octets.
2084
2085
The codification of the range of allowed usage of this field is
2086
outside the scope of this specification.
2087
2088
5.20. Callback-Id
2089
2090
Description
2091
2092
This Attribute indicates the name of a place to be called, to be
2093
interpreted by the NAS. It MAY be used in Access-Accept packets.
2094
2095
A summary of the Callback-Id Attribute format is shown below. The
2096
fields are transmitted from left to right.
2097
2098
0 1 2
2099
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2100
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2101
| Type | Length | String ...
2102
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2103
2104
Type
2105
2106
20 for Callback-Id.
2107
2108
Length
2109
2110
>= 3
2111
2112
String
2113
2114
The String field is one or more octets. The actual format of the
2115
information is site or application specific, and a robust
2116
implementation SHOULD support the field as undistinguished octets.
2117
The codification of the range of allowed usage of this field is
2118
outside the scope of this specification.
2119
2120
5.21. (unassigned)
2121
2122
Description
2123
2124
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
2125
2126
2127
2128
2129
2130
Rigney, et. al. Standards Track [Page 38]
2131
2132
RFC 2138 RADIUS April 1997
2133
2134
2135
5.22. Framed-Route
2136
2137
Description
2138
2139
This Attribute provides routing information to be configured for
2140
the user on the NAS. It is used in the Access-Accept packet and
2141
can appear multiple times.
2142
2143
A summary of the Framed-Route Attribute format is shown below. The
2144
fields are transmitted from left to right.
2145
2146
0 1 2
2147
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
2148
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2149
| Type | Length | String...
2150
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2151
2152
Type
2153
2154
22 for Framed-Route.
2155
2156
Length
2157
2158
>= 3
2159
2160
String
2161
2162
The String field is one or more octets, and its contents are
2163
implementation dependent. It is intended to be human readable and
2164
MUST NOT affect operation of the protocol. It is recommended that
2165
the message contain displayable ASCII characters from the range 32
2166
through 126 decimal.
2167
2168
For IP routes, it SHOULD contain a destination prefix in dotted
2169
quad form optionally followed by a slash and a decimal length
2170
specifier stating how many high order bits of the prefix should be
2171
used. That is followed by a space, a gateway address in dotted
2172
quad form, a space, and one or more metrics separated by spaces.
2173
For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
2174
specifier may be omitted in which case it should default to 8 bits
2175
for class A prefixes, 16 bits for class B prefixes, and 24 bits
2176
for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
2177
2178
Whenever the gateway address is specified as "0.0.0.0" the IP
2179
address of the user SHOULD be used as the gateway address.
2180
2181
2182
2183
2184
2185
2186
Rigney, et. al. Standards Track [Page 39]
2187
2188
RFC 2138 RADIUS April 1997
2189
2190
2191
5.23. Framed-IPX-Network
2192
2193
Description
2194
2195
This Attribute indicates the IPX Network number to be configured
2196
for the user. It is used in Access-Accept packets.
2197
2198
A summary of the Framed-IPX-Network Attribute format is shown below.
2199
The fields are transmitted from left to right.
2200
2201
0 1 2 3
2202
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
2203
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2204
| Type | Length | Value
2205
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2206
Value (cont) |
2207
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2208
2209
Type
2210
2211
23 for Framed-IPX-Network.
2212
2213
Length
2214
2215
6
2216
2217
Value
2218
2219
The Value field is four octets. The value 0xFFFFFFFE indicates
2220
that the NAS should select an IPX network for the user (e.g.
2221
assigned from a pool of one or more IPX networks kept by the NAS).
2222
Other values should be used as the IPX network for the link to the
2223
user.
2224
2225
5.24. State
2226
2227
Description
2228
2229
This Attribute is available to be sent by the server to the client
2230
in an Access-Challenge and MUST be sent unmodified from the client
2231
to the server in the new Access-Request reply to that challenge,
2232
if any.
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
Rigney, et. al. Standards Track [Page 40]
2243
2244
RFC 2138 RADIUS April 1997
2245
2246
2247
This Attribute is available to be sent by the server to the client
2248
in an Access-Accept that also includes a Termination-Action
2249
Attribute with the value of RADIUS-Request. If the NAS performs
2250
the Termination-Action by sending a new Access-Request upon
2251
termination of the current session, it MUST include the State
2252
attribute unchanged in that Access-Request.
2253
2254
In either usage, no interpretation by the client should be made.
2255
A packet may have only one State Attribute. Usage of the State
2256
Attribute is implementation dependent.
2257
2258
A summary of the State Attribute format is shown below. The fields
2259
are transmitted from left to right.
2260
2261
0 1 2
2262
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2263
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2264
| Type | Length | String ...
2265
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2266
2267
Type
2268
2269
24 for State.
2270
2271
Length
2272
2273
>= 3
2274
2275
String
2276
2277
The String field is one or more octets. The actual format of the
2278
information is site or application specific, and a robust
2279
implementation SHOULD support the field as undistinguished octets.
2280
2281
The codification of the range of allowed usage of this field is
2282
outside the scope of this specification.
2283
2284
5.25. Class
2285
2286
Description
2287
2288
This Attribute is available to be sent by the server to the client
2289
in an Access-Accept and should be sent unmodified by the client to
2290
the accounting server as part of the Accounting-Request packet if
2291
accounting is supported. No interpretation by the client should
2292
be made.
2293
2294
2295
2296
2297
2298
Rigney, et. al. Standards Track [Page 41]
2299
2300
RFC 2138 RADIUS April 1997
2301
2302
2303
A summary of the Class Attribute format is shown below. The fields
2304
are transmitted from left to right.
2305
2306
0 1 2
2307
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2308
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2309
| Type | Length | String ...
2310
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2311
2312
Type
2313
2314
25 for Class.
2315
2316
Length
2317
2318
>= 3
2319
2320
String
2321
2322
The String field is one or more octets. The actual format of the
2323
information is site or application specific, and a robust
2324
implementation SHOULD support the field as undistinguished octets.
2325
2326
The codification of the range of allowed usage of this field is
2327
outside the scope of this specification.
2328
2329
5.26. Vendor-Specific
2330
2331
Description
2332
2333
This Attribute is available to allow vendors to support their own
2334
extended Attributes not suitable for general usage. It MUST not
2335
affect the operation of the RADIUS protocol.
2336
2337
Servers not equipped to interpret the vendor-specific information
2338
sent by a client MUST ignore it (although it may be reported).
2339
Clients which do not receive desired vendor-specific information
2340
SHOULD make an attempt to operate without it, although they may do
2341
so (and report they are doing so) in a degraded mode.
2342
2343
A summary of the Vendor-Specific Attribute format is shown below.
2344
The fields are transmitted from left to right.
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
Rigney, et. al. Standards Track [Page 42]
2355
2356
RFC 2138 RADIUS April 1997
2357
2358
2359
0 1 2 3
2360
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
2361
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2362
| Type | Length | Vendor-Id
2363
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2364
Vendor-Id (cont) | String...
2365
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2366
2367
Type
2368
2369
26 for Vendor-Specific.
2370
2371
Length
2372
2373
>= 7
2374
2375
Vendor-Id
2376
2377
The high-order octet is 0 and the low-order 3 octets are the SMI
2378
Network Management Private Enterprise Code of the Vendor in
2379
network byte order, as defined in the Assigned Numbers RFC [3].
2380
2381
String
2382
2383
The String field is one or more octets. The actual format of the
2384
information is site or application specific, and a robust
2385
implementation SHOULD support the field as undistinguished octets.
2386
2387
The codification of the range of allowed usage of this field is
2388
outside the scope of this specification.
2389
2390
It SHOULD be encoded as a sequence of vendor type / vendor length
2391
/ value fields, as follows. The Attribute-Specific field is
2392
dependent on the vendor's definition of that attribute. An
2393
example encoding of the Vendor-Specific attribute using this
2394
method follows:
2395
2396
0 1 2 3
2397
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
2398
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2399
| Type | Length | Vendor-Id
2400
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2401
Vendor-Id (cont) | Vendor type | Vendor length |
2402
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2403
| Attribute-Specific...
2404
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2405
2406
2407
2408
2409
2410
Rigney, et. al. Standards Track [Page 43]
2411
2412
RFC 2138 RADIUS April 1997
2413
2414
2415
5.27. Session-Timeout
2416
2417
Description
2418
2419
This Attribute sets the maximum number of seconds of service to be
2420
provided to the user before termination of the session or prompt.
2421
This Attribute is available to be sent by the server to the client
2422
in an Access-Accept or Access-Challenge.
2423
2424
A summary of the Session-Timeout Attribute format is shown below.
2425
The fields are transmitted from left to right.
2426
2427
0 1 2 3
2428
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
2429
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2430
| Type | Length | Value
2431
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2432
Value (cont) |
2433
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2434
2435
Type
2436
2437
27 for Session-Timeout.
2438
2439
Length
2440
2441
6
2442
2443
Value
2444
2445
The field is 4 octets, containing a 32-bit unsigned integer with
2446
the maximum number of seconds this user should be allowed to
2447
remain connected by the NAS.
2448
2449
5.28. Idle-Timeout
2450
2451
Description
2452
2453
This Attribute sets the maximum number of consecutive seconds of
2454
idle connection allowed to the user before termination of the
2455
session or prompt. This Attribute is available to be sent by the
2456
server to the client in an Access-Accept or Access-Challenge.
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
Rigney, et. al. Standards Track [Page 44]
2467
2468
RFC 2138 RADIUS April 1997
2469
2470
2471
A summary of the Idle-Timeout Attribute format is shown below. The
2472
fields are transmitted from left to right.
2473
2474
0 1 2 3
2475
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
2476
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2477
| Type | Length | Value
2478
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2479
Value (cont) |
2480
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2481
2482
Type
2483
2484
28 for Idle-Timeout.
2485
2486
Length
2487
2488
6
2489
2490
Value
2491
2492
The field is 4 octets, containing a 32-bit unsigned integer with
2493
the maximum number of consecutive seconds of idle time this user
2494
should be permitted before being disconnected by the NAS.
2495
2496
5.29. Termination-Action
2497
2498
Description
2499
2500
This Attribute indicates what action the NAS should take when the
2501
specified service is completed. It is only used in Access-Accept
2502
packets.
2503
2504
A summary of the Termination-Action Attribute format is shown below.
2505
The fields are transmitted from left to right.
2506
2507
0 1 2 3
2508
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
2509
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2510
| Type | Length | Value
2511
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2512
Value (cont) |
2513
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2514
2515
Type
2516
2517
29 for Termination-Action.
2518
2519
2520
2521
2522
Rigney, et. al. Standards Track [Page 45]
2523
2524
RFC 2138 RADIUS April 1997
2525
2526
2527
Length
2528
2529
6
2530
2531
Value
2532
2533
The Value field is four octets.
2534
2535
0 Default
2536
1 RADIUS-Request
2537
2538
If the Value is set to RADIUS-Request, upon termination of the
2539
specified service the NAS MAY send a new Access-Request to the
2540
RADIUS server, including the State attribute if any.
2541
2542
5.30. Called-Station-Id
2543
2544
Description
2545
2546
This Attribute allows the NAS to send in the Access-Request packet
2547
the phone number that the user called, using Dialed Number
2548
Identification (DNIS) or similar technology. Note that this may be
2549
different from the phone number the call comes in on. It is only
2550
used in Access-Request packets.
2551
2552
A summary of the Called-Station-Id Attribute format is shown below.
2553
The fields are transmitted from left to right.
2554
2555
0 1 2
2556
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2557
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2558
| Type | Length | String ...
2559
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2560
2561
2562
Type
2563
2564
30 for Called-Station-Id.
2565
2566
Length
2567
2568
>= 3
2569
2570
String
2571
2572
The String field is one or more octets, containing the phone
2573
number that the user's call came in on.
2574
2575
2576
2577
2578
Rigney, et. al. Standards Track [Page 46]
2579
2580
RFC 2138 RADIUS April 1997
2581
2582
2583
The actual format of the information is site or application
2584
specific. Printable ASCII is recommended, but a robust
2585
implementation SHOULD support the field as undistinguished octets.
2586
2587
The codification of the range of allowed usage of this field is
2588
outside the scope of this specification.
2589
2590
5.31. Calling-Station-Id
2591
2592
Description
2593
2594
This Attribute allows the NAS to send in the Access-Request packet
2595
the phone number that the call came from, using Automatic Number
2596
Identification (ANI) or similar technology. It is only used in
2597
Access-Request packets.
2598
2599
A summary of the Calling-Station-Id Attribute format is shown below.
2600
The fields are transmitted from left to right.
2601
2602
0 1 2
2603
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2604
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2605
| Type | Length | String ...
2606
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2607
2608
Type
2609
2610
31 for Calling-Station-Id.
2611
2612
Length
2613
2614
>= 3
2615
2616
String
2617
2618
The String field is one or more octets, containing the phone
2619
number that the user placed the call from.
2620
2621
The actual format of the information is site or application
2622
specific. Printable ASCII is recommended, but a robust
2623
implementation SHOULD support the field as undistinguished octets.
2624
2625
The codification of the range of allowed usage of this field is
2626
outside the scope of this specification.
2627
2628
2629
2630
2631
2632
2633
2634
Rigney, et. al. Standards Track [Page 47]
2635
2636
RFC 2138 RADIUS April 1997
2637
2638
2639
5.32. NAS-Identifier
2640
2641
Description
2642
2643
This Attribute contains a string identifying the NAS originating
2644
the Access-Request. It is only used in Access-Request packets.
2645
Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
2646
Access-Request packet.
2647
2648
A summary of the NAS-Identifier Attribute format is shown below. The
2649
fields are transmitted from left to right.
2650
2651
0 1 2
2652
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2653
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2654
| Type | Length | String ...
2655
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2656
2657
Type
2658
2659
32 for NAS-Identifier.
2660
2661
Length
2662
2663
>= 3
2664
2665
String
2666
2667
The String field is one or more octets, and should be unique to
2668
the NAS within the scope of the RADIUS server. For example, a
2669
fully qualified domain name would be suitable as a NAS-Identifier.
2670
2671
The actual format of the information is site or application
2672
specific, and a robust implementation SHOULD support the field as
2673
undistinguished octets.
2674
2675
The codification of the range of allowed usage of this field is
2676
outside the scope of this specification.
2677
2678
5.33. Proxy-State
2679
2680
Description
2681
2682
This Attribute is available to be sent by a proxy server to
2683
another server when forwarding an Access-Request and MUST be
2684
returned unmodified in the Access-Accept, Access-Reject or
2685
Access-Challenge. This attribute should be removed by the proxy
2686
server before the response is forwarded to the NAS.
2687
2688
2689
2690
Rigney, et. al. Standards Track [Page 48]
2691
2692
RFC 2138 RADIUS April 1997
2693
2694
2695
Usage of the Proxy-State Attribute is implementation dependent. A
2696
description of its function is outside the scope of this
2697
specification.
2698
2699
A summary of the Proxy-State Attribute format is shown below. The
2700
fields are transmitted from left to right.
2701
2702
0 1 2
2703
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2704
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2705
| Type | Length | String ...
2706
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2707
2708
Type
2709
2710
33 for Proxy-State.
2711
2712
Length
2713
2714
>= 3
2715
2716
String
2717
2718
The String field is one or more octets. The actual format of the
2719
information is site or application specific, and a robust
2720
implementation SHOULD support the field as undistinguished octets.
2721
2722
The codification of the range of allowed usage of this field is
2723
outside the scope of this specification.
2724
2725
5.34. Login-LAT-Service
2726
2727
Description
2728
2729
This Attribute indicates the system with which the user is to be
2730
connected by LAT. It MAY be used in Access-Accept packets, but
2731
only when LAT is specified as the Login-Service. It MAY be used
2732
in an Access-Request packet as a hint to the server, but the
2733
server is not required to honor the hint.
2734
2735
Administrators use the service attribute when dealing with
2736
clustered systems, such as a VAX or Alpha cluster. In such an
2737
environment several different time sharing hosts share the same
2738
resources (disks, printers, etc.), and administrators often
2739
configure each to offer access (service) to each of the shared
2740
resources. In this case, each host in the cluster advertises its
2741
services through LAT broadcasts.
2742
2743
2744
2745
2746
Rigney, et. al. Standards Track [Page 49]
2747
2748
RFC 2138 RADIUS April 1997
2749
2750
2751
Sophisticated users often know which service providers (machines)
2752
are faster and tend to use a node name when initiating a LAT
2753
connection. Alternately, some administrators want particular
2754
users to use certain machines as a primitive form of load
2755
balancing (although LAT knows how to do load balancing itself).
2756
2757
A summary of the Login-LAT-Service Attribute format is shown below.
2758
The fields are transmitted from left to right.
2759
2760
0 1 2
2761
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2762
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2763
| Type | Length | String ...
2764
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2765
2766
2767
Type
2768
2769
34 for Login-LAT-Service.
2770
2771
Length
2772
2773
>= 3
2774
2775
String
2776
2777
The String field is one or more octets, and contains the identity
2778
of the LAT service to use. The LAT Architecture allows this
2779
string to contain $ (dollar), - (hyphen), . (period), _
2780
(underscore), numerics, upper and lower case alphabetics, and the
2781
ISO Latin-1 character set extension [6]. All LAT string
2782
comparisons are case insensitive.
2783
2784
5.35. Login-LAT-Node
2785
2786
Description
2787
2788
This Attribute indicates the Node with which the user is to be
2789
automatically connected by LAT. It MAY be used in Access-Accept
2790
packets, but only when LAT is specified as the Login-Service. It
2791
MAY be used in an Access-Request packet as a hint to the server,
2792
but the server is not required to honor the hint.
2793
2794
A summary of the Login-LAT-Node Attribute format is shown below. The
2795
fields are transmitted from left to right.
2796
2797
2798
2799
2800
2801
2802
Rigney, et. al. Standards Track [Page 50]
2803
2804
RFC 2138 RADIUS April 1997
2805
2806
2807
0 1 2
2808
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2809
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2810
| Type | Length | String ...
2811
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2812
2813
Type
2814
2815
35 for Login-LAT-Node.
2816
2817
Length
2818
2819
>= 3
2820
2821
String
2822
2823
The String field is one or more octets, and contains the identity
2824
of the LAT Node to connect the user to. The LAT Architecture
2825
allows this string to contain $ (dollar), - (hyphen), . (period),
2826
_ (underscore), numerics, upper and lower case alphabetics, and
2827
the ISO Latin-1 character set extension. All LAT string
2828
comparisons are case insensitive.
2829
2830
5.36. Login-LAT-Group
2831
2832
Description
2833
2834
This Attribute contains a string identifying the LAT group codes
2835
which this user is authorized to use. It MAY be used in Access-
2836
Accept packets, but only when LAT is specified as the Login-
2837
Service. It MAY be used in an Access-Request packet as a hint to
2838
the server, but the server is not required to honor the hint.
2839
2840
LAT supports 256 different group codes, which LAT uses as a form
2841
of access rights. LAT encodes the group codes as a 256 bit
2842
bitmap.
2843
2844
Administrators can assign one or more of the group code bits at
2845
the LAT service provider; it will only accept LAT connections that
2846
have these group codes set in the bit map. The administrators
2847
assign a bitmap of authorized group codes to each user; LAT gets
2848
these from the operating system, and uses these in its requests to
2849
the service providers.
2850
2851
2852
2853
2854
2855
2856
2857
2858
Rigney, et. al. Standards Track [Page 51]
2859
2860
RFC 2138 RADIUS April 1997
2861
2862
2863
A summary of the Login-LAT-Group Attribute format is shown below.
2864
The fields are transmitted from left to right.
2865
2866
0 1 2
2867
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2868
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2869
| Type | Length | String ...
2870
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2871
2872
Type
2873
2874
36 for Login-LAT-Group.
2875
2876
Length
2877
2878
34
2879
2880
String
2881
2882
The String field is a 32 octet bit map, most significant octet
2883
first. A robust implementation SHOULD support the field as
2884
undistinguished octets.
2885
2886
The codification of the range of allowed usage of this field is
2887
outside the scope of this specification.
2888
2889
5.37. Framed-AppleTalk-Link
2890
2891
Description
2892
2893
This Attribute indicates the AppleTalk network number which should
2894
be used for the serial link to the user, which is another
2895
AppleTalk router. It is only used in Access-Accept packets. It
2896
is never used when the user is not another router.
2897
2898
A summary of the Framed-AppleTalk-Link Attribute format is shown
2899
below. The fields are transmitted from left to right.
2900
2901
0 1 2 3
2902
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
2903
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2904
| Type | Length | Value
2905
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2906
Value (cont) |
2907
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2908
2909
2910
2911
2912
2913
2914
Rigney, et. al. Standards Track [Page 52]
2915
2916
RFC 2138 RADIUS April 1997
2917
2918
2919
Type
2920
2921
37 for Framed-AppleTalk-Link.
2922
2923
Length
2924
2925
6
2926
2927
Value
2928
2929
The Value field is four octets. Despite the size of the field,
2930
values range from 0 to 65535. The special value of 0 indicates
2931
that this is an unnumbered serial link. A value of 1-65535 means
2932
that the serial line between the NAS and the user should be
2933
assigned that value as an AppleTalk network number.
2934
2935
5.38. Framed-AppleTalk-Network
2936
2937
Description
2938
2939
This Attribute indicates the AppleTalk Network number which the
2940
NAS should probe to allocate an AppleTalk node for the user. It
2941
is only used in Access-Accept packets. It is never used when the
2942
user is another router. Multiple instances of this Attribute
2943
indicate that the NAS may probe using any of the network numbers
2944
specified.
2945
2946
A summary of the Framed-AppleTalk-Network Attribute format is shown
2947
below. The fields are transmitted from left to right.
2948
2949
0 1 2 3
2950
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
2951
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2952
| Type | Length | Value
2953
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2954
Value (cont) |
2955
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2956
2957
Type
2958
2959
38 for Framed-AppleTalk-Network.
2960
2961
Length
2962
2963
6
2964
2965
2966
2967
2968
2969
2970
Rigney, et. al. Standards Track [Page 53]
2971
2972
RFC 2138 RADIUS April 1997
2973
2974
2975
Value
2976
2977
The Value field is four octets. Despite the size of the field,
2978
values range from 0 to 65535. The special value 0 indicates that
2979
the NAS should assign a network for the user, using its default
2980
cable range. A value between 1 and 65535 (inclusive) indicates
2981
the AppleTalk Network the NAS should probe to find an address for
2982
the user.
2983
2984
5.39. Framed-AppleTalk-Zone
2985
2986
Description
2987
2988
This Attribute indicates the AppleTalk Default Zone to be used for
2989
this user. It is only used in Access-Accept packets. Multiple
2990
instances of this attribute in the same packet are not allowed.
2991
2992
A summary of the Framed-AppleTalk-Zone Attribute format is shown
2993
below. The fields are transmitted from left to right.
2994
2995
0 1 2
2996
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
2997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2998
| Type | Length | String ...
2999
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3000
3001
Type
3002
3003
39 for Framed-AppleTalk-Zone.
3004
3005
Length
3006
3007
>= 3
3008
3009
String
3010
3011
The name of the Default AppleTalk Zone to be used for this user.
3012
A robust implementation SHOULD support the field as
3013
undistinguished octets.
3014
3015
The codification of the range of allowed usage of this field is
3016
outside the scope of this specification.
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
Rigney, et. al. Standards Track [Page 54]
3027
3028
RFC 2138 RADIUS April 1997
3029
3030
3031
5.40. CHAP-Challenge
3032
3033
Description
3034
3035
This Attribute contains the CHAP Challenge sent by the NAS to a
3036
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
3037
is only used in Access-Request packets.
3038
3039
If the CHAP challenge value is 16 octets long it MAY be placed in
3040
the Request Authenticator field instead of using this attribute.
3041
3042
A summary of the CHAP-Challenge Attribute format is shown below. The
3043
fields are transmitted from left to right.
3044
3045
0 1 2
3046
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
3047
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3048
| Type | Length | String...
3049
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3050
3051
Type
3052
3053
60 for CHAP-Challenge.
3054
3055
Length
3056
3057
>= 7
3058
3059
String
3060
3061
The String field contains the CHAP Challenge.
3062
3063
5.41. NAS-Port-Type
3064
3065
Description
3066
3067
This Attribute indicates the type of the physical port of the NAS
3068
which is authenticating the user. It can be used instead of or in
3069
addition to the NAS-Port (5) attribute. It is only used in
3070
Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
3071
both SHOULD be present in an Access-Request packet, if the NAS
3072
differentiates among its ports.
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
Rigney, et. al. Standards Track [Page 55]
3083
3084
RFC 2138 RADIUS April 1997
3085
3086
3087
A summary of the NAS-Port-Type Attribute format is shown below. The
3088
fields are transmitted from left to right.
3089
3090
0 1 2 3
3091
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
3092
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3093
| Type | Length | Value
3094
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3095
Value (cont) |
3096
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3097
3098
Type
3099
3100
61 for NAS-Port-Type.
3101
3102
Length
3103
3104
6
3105
3106
Value
3107
3108
The Value field is four octets. "Virtual" refers to a connection
3109
to the NAS via some transport protocol, instead of through a
3110
physical port. For example, if a user telnetted into a NAS to
3111
authenticate himself as an Outbound-User, the Access-Request might
3112
include NAS-Port-Type = Virtual as a hint to the RADIUS server
3113
that the user was not on a physical port.
3114
3115
0 Async
3116
1 Sync
3117
2 ISDN Sync
3118
3 ISDN Async V.120
3119
4 ISDN Async V.110
3120
5 Virtual
3121
3122
5.42. Port-Limit
3123
3124
Description
3125
3126
This Attribute sets the maximum number of ports to be provided to
3127
the user by the NAS. This Attribute MAY be sent by the server to
3128
the client in an Access-Accept packet. It is intended for use in
3129
conjunction with Multilink PPP [7] or similar uses. It MAY also
3130
be sent by the NAS to the server as a hint that that many ports
3131
are desired for use, but the server is not required to honor the
3132
hint.
3133
3134
3135
3136
3137
3138
Rigney, et. al. Standards Track [Page 56]
3139
3140
RFC 2138 RADIUS April 1997
3141
3142
3143
A summary of the Port-Limit Attribute format is shown below. The
3144
fields are transmitted from left to right.
3145
3146
0 1 2 3
3147
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
3148
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3149
| Type | Length | Value
3150
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3151
Value (cont) |
3152
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3153
3154
Type
3155
3156
62 for Port-Limit.
3157
3158
Length
3159
3160
6
3161
3162
Value
3163
3164
The field is 4 octets, containing a 32-bit unsigned integer with
3165
the maximum number of ports this user should be allowed to connect
3166
to on the NAS.
3167
3168
5.43. Login-LAT-Port
3169
3170
Description
3171
3172
This Attribute indicates the Port with which the user is to be
3173
connected by LAT. It MAY be used in Access-Accept packets, but
3174
only when LAT is specified as the Login-Service. It MAY be used
3175
in an Access-Request packet as a hint to the server, but the
3176
server is not required to honor the hint.
3177
3178
A summary of the Login-LAT-Port Attribute format is shown below. The
3179
fields are transmitted from left to right.
3180
3181
0 1 2
3182
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3183
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3184
| Type | Length | String ...
3185
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3186
3187
Type
3188
3189
63 for Login-LAT-Port.
3190
3191
3192
3193
3194
Rigney, et. al. Standards Track [Page 57]
3195
3196
RFC 2138 RADIUS April 1997
3197
3198
3199
Length
3200
3201
>= 3
3202
3203
String
3204
3205
The String field is one or more octets, and contains the identity
3206
of the LAT port to use. The LAT Architecture allows this string
3207
to contain $ (dollar), - (hyphen), . (period), _ (underscore),
3208
numerics, upper and lower case alphabetics, and the ISO Latin-1
3209
character set extension. All LAT string comparisons are case
3210
insensitive.
3211
3212
5.44. Table of Attributes
3213
3214
The following table provides a guide to which attributes may be found
3215
in which kinds of packets, and in what quantity.
3216
3217
Request Accept Reject Challenge # Attribute
3218
1 0 0 0 1 User-Name
3219
0-1 0 0 0 2 User-Password [Note 1]
3220
0-1 0 0 0 3 CHAP-Password [Note 1]
3221
0-1 0 0 0 4 NAS-IP-Address
3222
0-1 0 0 0 5 NAS-Port
3223
0-1 0-1 0 0 6 Service-Type
3224
0-1 0-1 0 0 7 Framed-Protocol
3225
0-1 0-1 0 0 8 Framed-IP-Address
3226
0-1 0-1 0 0 9 Framed-IP-Netmask
3227
0 0-1 0 0 10 Framed-Routing
3228
0 0+ 0 0 11 Filter-Id
3229
0 0-1 0 0 12 Framed-MTU
3230
0+ 0+ 0 0 13 Framed-Compression
3231
0+ 0+ 0 0 14 Login-IP-Host
3232
0 0-1 0 0 15 Login-Service
3233
0 0-1 0 0 16 Login-TCP-Port
3234
0 0+ 0+ 0+ 18 Reply-Message
3235
0-1 0-1 0 0 19 Callback-Number
3236
0 0-1 0 0 20 Callback-Id
3237
0 0+ 0 0 22 Framed-Route
3238
0 0-1 0 0 23 Framed-IPX-Network
3239
0-1 0-1 0 0-1 24 State
3240
0 0+ 0 0 25 Class
3241
0+ 0+ 0 0+ 26 Vendor-Specific
3242
0 0-1 0 0-1 27 Session-Timeout
3243
0 0-1 0 0-1 28 Idle-Timeout
3244
0 0-1 0 0 29 Termination-Action
3245
0-1 0 0 0 30 Called-Station-Id
3246
0-1 0 0 0 31 Calling-Station-Id
3247
3248
3249
3250
Rigney, et. al. Standards Track [Page 58]
3251
3252
RFC 2138 RADIUS April 1997
3253
3254
3255
0-1 0 0 0 32 NAS-Identifier
3256
0+ 0+ 0+ 0+ 33 Proxy-State
3257
0-1 0-1 0 0 34 Login-LAT-Service
3258
0-1 0-1 0 0 35 Login-LAT-Node
3259
0-1 0-1 0 0 36 Login-LAT-Group
3260
0 0-1 0 0 37 Framed-AppleTalk-Link
3261
0 0+ 0 0 38 Framed-AppleTalk-Network
3262
0 0-1 0 0 39 Framed-AppleTalk-Zone
3263
0-1 0 0 0 60 CHAP-Challenge
3264
0-1 0 0 0 61 NAS-Port-Type
3265
0-1 0-1 0 0 62 Port-Limit
3266
0-1 0-1 0 0 63 Login-LAT-Port
3267
3268
3269
Request Accept Reject Challenge # Attribute
3270
3271
3272
[Note 1] An Access-Request MUST contain either a User-Password or a
3273
CHAP-Password, and MUST NOT contain both.
3274
3275
The following table defines the meaning of the above table entries.
3276
3277
0 This attribute MUST NOT be present in packet.
3278
0+ Zero or more instances of this attribute MAY be present in packet.
3279
0-1 Zero or one instance of this attribute MAY be present in packet.
3280
1 Exactly one instance of this attribute MUST be present in packet.
3281
3282
6. Examples
3283
3284
A few examples are presented to illustrate the flow of packets and
3285
use of typical attributes. These examples are not intended to be
3286
exhaustive, many others are possible.
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
Rigney, et. al. Standards Track [Page 59]
3307
3308
RFC 2138 RADIUS April 1997
3309
3310
3311
6.1. User Telnet to Specified Host
3312
3313
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3314
RADIUS Server for a user named nemo logging in on port 3.
3315
3316
Code = 1 (Access-Request)
3317
ID = 0
3318
Length = 56
3319
Request Authenticator = {16 octet random number}
3320
Attributes:
3321
User-Name = "nemo"
3322
User-Password = {16 octets of Password padded at end with nulls,
3323
XORed with MD5(shared secret|Request Authenticator)}
3324
NAS-IP-Address = 192.168.1.16
3325
NAS-Port = 3
3326
3327
The RADIUS server authenticates nemo, and sends an Access-Accept UDP
3328
packet to the NAS telling it to telnet nemo to host 192.168.1.3.
3329
3330
Code = 2 (Access-Accept)
3331
ID = 0 (same as in Access-Request)
3332
Length = 38
3333
Response Authenticator = {16-octet MD-5 checksum of the code (2),
3334
id (0), Length (38), the Request Authenticator from
3335
above, the attributes in this reply, and the shared
3336
secret}
3337
Attributes:
3338
Service-Type = Login-User
3339
Login-Service = Telnet
3340
Login-Host = 192.168.1.3
3341
3342
6.2. Framed User Authenticating with CHAP
3343
3344
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3345
RADIUS Server for a user named flopsy logging in on port 20 with PPP,
3346
authenticating using CHAP. The NAS sends along the Service-Type and
3347
Framed-Protocol attributes as a hint to the RADIUS server that this
3348
user is looking for PPP, although the NAS is not required to do so.
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
Rigney, et. al. Standards Track [Page 60]
3363
3364
RFC 2138 RADIUS April 1997
3365
3366
3367
Code = 1 (Access-Request)
3368
ID = 1
3369
Length = 71
3370
Request Authenticator = {16 octet random number also used as
3371
CHAP challenge}
3372
Attributes:
3373
User-Name = "flopsy"
3374
CHAP-Password = {1 octet CHAP ID followed by 16 octet
3375
CHAP response}
3376
NAS-IP-Address = 192.168.1.16
3377
NAS-Port = 20
3378
Service-Type = Framed-User
3379
Framed-Protocol = PPP
3380
3381
The RADIUS server authenticates flopsy, and sends an Access-Accept
3382
UDP packet to the NAS telling it to start PPP service and assign an
3383
address for the user out of its dynamic address pool.
3384
3385
Code = 2 (Access-Accept)
3386
ID = 1 (same as in Access-Request)
3387
Length = 56
3388
Response Authenticator = {16-octet MD-5 checksum of the code (2),
3389
id (1), Length (56), the Request Authenticator from
3390
above, the attributes in this reply, and the shared
3391
secret}
3392
Attributes:
3393
Service-Type = Framed-User
3394
Framed-Protocol = PPP
3395
Framed-IP-Address = 255.255.255.254
3396
Framed-Routing = None
3397
Framed-Compression = 1 (VJ TCP/IP Header Compression)
3398
Framed-MTU = 1500
3399
3400
6.3. User with Challenge-Response card
3401
3402
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3403
RADIUS Server for a user named mopsy logging in on port 7.
3404
3405
Code = 1 (Access-Request)
3406
ID = 2
3407
Length = 57
3408
Request Authenticator = {16 octet random number}
3409
Attributes:
3410
User-Name = "mopsy"
3411
User-Password = {16 octets of Password padded at end with nulls,
3412
XORed with MD5(shared secret|Request Authenticator)}
3413
NAS-IP-Address = 192.168.1.16
3414
NAS-Port = 7
3415
3416
3417
3418
Rigney, et. al. Standards Track [Page 61]
3419
3420
RFC 2138 RADIUS April 1997
3421
3422
3423
The RADIUS server decides to challenge mopsy, sending back a
3424
challenge string and looking for a response. The RADIUS server
3425
therefore and sends an Access-Challenge UDP packet to the NAS.
3426
3427
Code = 11 (Access-Challenge}
3428
ID = 2 (same as in Access-Request)
3429
Length = 78
3430
Response Authenticator = {16-octet MD-5 checksum of the code (11),
3431
id (2), length (78), the Request Authenticator from
3432
above, the attributes in this reply, and the shared
3433
secret}
3434
Attributes:
3435
Reply-Message = "Challenge 32769430. Enter response at prompt."
3436
State = {Magic Cookie to be returned along with user's response;
3437
in this example 8 octets of data}
3438
3439
The user enters his response, and the NAS send a new Access-Request
3440
with that response, and includes the State Attribute.
3441
3442
Code = 1 (Access-Request)
3443
ID = 3 (Note that this changes)
3444
Length = 67
3445
Request Authenticator = {NEW 16 octet random number}
3446
Attributes:
3447
User-Name = "mopsy"
3448
User-Password = {16 octets of Response padded at end with
3449
nulls, XORed with MD5 checksum of shared secret
3450
plus above Request Authenticator}
3451
NAS-IP-Address = 192.168.1.16
3452
NAS-Port = 7
3453
State = {Magic Cookie from Access-Challenge packet, unchanged}
3454
3455
The Response was incorrect, so the RADIUS server tells the NAS to
3456
reject the login attempt.
3457
3458
Code = 3 (Access-Reject)
3459
ID = 3 (same as in Access-Request)
3460
Length = 20
3461
Response Authenticator = {16-octet MD-5 checksum of the code (3),
3462
id (3), length(20), the Request Authenticator from
3463
above, the attributes in this reply if any, and the
3464
shared secret}
3465
Attributes:
3466
(none, although a Reply-Message could be sent)
3467
3468
3469
3470
3471
3472
3473
3474
Rigney, et. al. Standards Track [Page 62]
3475
3476
RFC 2138 RADIUS April 1997
3477
3478
3479
Security Considerations
3480
3481
Security issues are the primary topic of this document.
3482
3483
In practice, within or associated with each RADIUS server, there is a
3484
database which associates "user" names with authentication
3485
information ("secrets"). It is not anticipated that a particular
3486
named user would be authenticated by multiple methods. This would
3487
make the user vulnerable to attacks which negotiate the least secure
3488
method from among a set. Instead, for each named user there should
3489
be an indication of exactly one method used to authenticate that user
3490
name. If a user needs to make use of different authentication
3491
methods under different circumstances, then distinct user names
3492
SHOULD be employed, each of which identifies exactly one
3493
authentication method.
3494
3495
Passwords and other secrets should be stored at the respective ends
3496
such that access to them is as limited as possible. Ideally, the
3497
secrets should only be accessible to the process requiring access in
3498
order to perform the authentication.
3499
3500
The secrets should be distributed with a mechanism that limits the
3501
number of entities that handle (and thus gain knowledge of) the
3502
secret. Ideally, no unauthorized person should ever gain knowledge
3503
of the secrets. It is possible to achieve this with SNMP Security
3504
Protocols [8], but such a mechanism is outside the scope of this
3505
specification.
3506
3507
Other distribution methods are currently undergoing research and
3508
experimentation. The SNMP Security document [8] also has an
3509
excellent overview of threats to network protocols.
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
Rigney, et. al. Standards Track [Page 63]
3531
3532
RFC 2138 RADIUS April 1997
3533
3534
3535
References
3536
3537
[1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
3538
RFC 1321, MIT Laboratory for Computer Science, RSA Data
3539
Security Inc., April 1992.
3540
3541
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
3542
USC/Information Sciences Institute, August 1980.
3543
3544
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
3545
1700, USC/Information Sciences Institute, October 1994.
3546
3547
[4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
3548
Private Communications in a Public World", Prentice Hall, March
3549
1995, ISBN 0-13-061466-1.
3550
3551
[5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
3552
links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
3553
3554
[6] ISO 8859. International Standard -- Information Processing --
3555
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
3556
Alphabet No. 1, ISO 8859-1:1987.
3557
<URL:http://www.iso.ch/cate/d16338.html>
3558
3559
[7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
3560
Multilink Protocol (MP)", RFC 1717, University of California
3561
Berkeley, Lloyd Internetworking, Newbridge Networks
3562
Corporation, November 1994.
3563
3564
[8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
3565
Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
3566
LAN Systems, Inc., MIT Laboratory for Computer Science, July
3567
1992.
3568
3569
[9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
3570
3571
Acknowledgments
3572
3573
RADIUS was originally developed by Livingston Enterprises for their
3574
PortMaster series of Network Access Servers.
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
Rigney, et. al. Standards Track [Page 64]
3587
3588
RFC 2138 RADIUS April 1997
3589
3590
3591
Chair's Address
3592
3593
The working group can be contacted via the current chair:
3594
3595
Carl Rigney
3596
Livingston Enterprises
3597
4464 Willow Road
3598
Pleasanton, California 94588
3599
3600
Phone: +1 510 426 0770
3601
EMail: cdr@livingston.com
3602
3603
Authors' Addresses
3604
3605
Questions about this memo can also be directed to:
3606
3607
Carl Rigney
3608
Livingston Enterprises
3609
4464 Willow Road
3610
Pleasanton, California 94588
3611
3612
Phone: +1 510 426 0770
3613
EMail: cdr@livingston.com
3614
3615
Allan C. Rubens
3616
Merit Network, Inc.
3617
4251 Plymouth Road
3618
Ann Arbor, Michigan 48105-2785
3619
3620
EMail: acr@merit.edu
3621
3622
William Allen Simpson
3623
Daydreamer
3624
Computer Systems Consulting Services
3625
1384 Fontaine
3626
Madison Heights, Michigan 48071
3627
3628
EMail: wsimpson@greendragon.com
3629
3630
Steve Willens
3631
Livingston Enterprises
3632
4464 Willow Road
3633
Pleasanton, California 94588
3634
3635
EMail: steve@livingston.com
3636
3637
3638
3639
3640
3641
3642
Rigney, et. al. Standards Track [Page 65]
3643
Loggerhead is a web-based interface for Breezy
Version: 2.0.1