1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Network Working Group F. Adrangi
Request for Comments: 4372 Intel
Category: Standards Track A. Lior
Bridgewater Systems
J. Korhonen
Teliasonera
J. Loughney
Nokia
January 2006
<span class="h1">Chargeable User Identity</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a new Remote Authentication Dial-In User
Service (RADIUS) attribute, Chargeable-User-Identity. This attribute
can be used by a home network to identify a user for the purpose of
roaming transactions that occur outside of the home network.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Motivation .................................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Operation .......................................................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Chargeable-User-Identity (CUI) Attribute ...................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. CUI Attribute ..............................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Attribute Table .................................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Diameter Consideration ..........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Acknowledgements ................................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-8">8</a>
<span class="grey">Adrangi, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM
and EAP-AKA, can hide the true identity of the user from RADIUS
servers outside of the user's home network. In these methods, the
User-Name(1) attribute contains an anonymous identity (e.g.,
@example.com) sufficient to route the RADIUS packets to the home
network but otherwise insufficient to identify the user. While this
mechanism is good practice in some circumstances, there are problems
if local and intermediate networks require a surrogate identity to
bind the current session.
This document introduces an attribute that serves as an alias or
handle (hereafter, it is called Chargeable-User-Identity) to the real
user's identity. Chargeable-User-Identity can be used outside the
home network in scenarios that traditionally relied on User-Name(1)
to correlate a session to a user.
For example, local or intermediate networks may limit the number of
simultaneous sessions for specific users; they may require a
Chargeable-User-Identity in order to demonstrate willingness to pay
or otherwise limit the potential for fraud.
This implies that a unique identity provided by the home network
should be able to be conveyed to all parties involved in the roaming
transaction for correlating the authentication and accounting
packets.
Providing a unique identity, Chargeable-User-Identity (CUI), to
intermediaries, is necessary to fulfill certain business needs. This
should not undermine the anonymity of the user. The mechanism
provided by this document allows the home operator to meet these
business requirements by providing a temporary identity representing
the user and at the same time protecting the anonymity of the user.
When the home network assigns a value to the CUI, it asserts that
this value represents a user in the home network. The assertion
should be temporary -- long enough to be useful for the external
applications and not too long such that it can be used to identify
the user.
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
and IRAP, have been studying mechanisms to provide roaming services,
using RADIUS. Missing elements include mechanisms for billing and
fraud prevention.
<span class="grey">Adrangi, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
The CUI attribute is intended to close operational loopholes in
RADIUS specifications that have impacted roaming solutions
negatively. Use of the CUI is geared toward EAP methods supporting
privacy (such as PEAP and EAP-TTLS), which are, for the most part,
recent deployments. A chargeable identity reflecting the user
profile by the home network is needed in such roaming scenarios.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Motivation</span>
Some other mechanisms have been proposed in place of the CUI
attribute. These mechanisms are insufficient or cause other
problems. It has been suggested that standard RADIUS Class(25) or
User-Name(1) attributes could be used to indicate the CUI. However,
in a complex global roaming environment where there could be one or
more intermediaries between the NAS [<a href="./rfc4282" title=""The Network Access Identifier"">RFC4282</a>] and the home RADIUS
server, the use of aforementioned attributes could lead to problems
as described below.
- On the use of RADIUS Class(25) attribute:
[<a id="ref-RFC2865">RFC2865</a>] states: "This Attribute is available to be sent by the
server to the client in an Access-Accept packet and SHOULD be sent
unmodified by the client to the accounting server as part of the
Accounting-Request packet if accounting is supported. The client
MUST NOT interpret the attribute locally." So RADIUS clients or
intermediaries MUST NOT interpret the Class(25) attribute, which
precludes determining whether it contains a CUI. Additionally,
there could be multiple class attributes in a RADIUS packet, and
since the contents of Class(25) attribute is not to be interpreted
by clients, this makes it hard for the entities outside the home
network to determine which one contains the CUI.
- On the use of RADIUS User-Name(1) attribute:
The User-Name(1) attribute included in the Access-Request packet
may be used for the purpose of routing the Access-Request packet,
and in the process may be rewritten by intermediaries. As a
result, a RADIUS server receiving an Access-Request packet relayed
by a proxy cannot assume that the User-Name(1) attribute remained
unmodified.
On the other hand, rewriting of a User-Name(1) attribute sent
within an Access-Accept packet occurs more rarely, since a
Proxy-State(33) attribute can be used to route the Access-Accept
packet without parsing the User-Name(1) attribute. As a result, a
RADIUS server cannot assume that a proxy stripping routing
information from a User-Name(1) attribute within an Access-Request
packet will add this information to a User-Name(1) attribute
<span class="grey">Adrangi, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
included within an Access-Accept packet. The result is that when
a User-Name(1) attribute is sent in an Access-Accept packet, it is
possible that the Access-Request packet and Accounting-Request
packets will follow different paths. Where this outcome is
undesirable, the RADIUS client should use the original
User-Name(1) in accounting packets. Therefore, another mechanism
is required to convey a CUI within an Access-Accept packet to the
RADIUS client, so that the CUI can be included in the accounting
packets.
The CUI attribute provides a solution to the above problems and
avoids overloading RADIUS User-Name(1) attribute or changing the
usage of existing RADIUS Class(25) attribute. The CUI therefore
provides a standard approach to billing and fraud prevention when EAP
methods supporting privacy are used. It does not solve all related
problems, but does provide for billing and fraud prevention.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The following acronyms are used:
3GPP - Third Generation Partnership Project
AAA - Authentication, Authorization, and Accounting
AKA - Authentication and Key Agreement
CUI - Chargeable-User-Identity
GSMA - GSM Association
IRAP - International Roaming Access Protocols Program
NAS - Network Access Server
PEAP - Protected Extensible Authentication Protocol
SIM - Subscriber Identity Modules
TTLS - Tunneled Transport Layer Security
WISPr - Wireless ISP Roaming
WPA - Wi-Fi Protected Access
<span class="grey">Adrangi, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Operation</span>
This document assumes that the RADIUS protocol operates as specified
in [<a href="./rfc2865" title=""Remote Authentication Dial In User Service (RADIUS)"">RFC2865</a>] and [<a href="./rfc2866" title=""RADIUS Accounting"">RFC2866</a>], dynamic authorization as specified in
[<a href="./rfc3576" title=""Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)"">RFC3576</a>], and the Diameter protocol as specified in [<a href="./rfc3588" title=""Diameter Base Protocol"">RFC3588</a>].
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Chargeable-User-Identity (CUI) Attribute</span>
The CUI attribute serves as an alias to the user's real identity,
representing a chargeable identity as defined and provided by the
home network as a supplemental or alternative information to
User-Name(1). Typically, the CUI represents the identity of the
actual user, but it may also indicate other chargeable identities
such as a group of users. RADIUS clients (proxy or NAS) outside the
home network MUST NOT modify the CUI attribute.
The RADIUS server (a RADIUS proxy, home RADIUS server) may include
the CUI attribute in the Access-Accept packet destined to a roaming
partner. The CUI support by RADIUS infrastructure is driven by the
business requirements between roaming entities. Therefore, a RADIUS
server supporting this specification may choose not to send the CUI
in response to an Access-Request packet from a given NAS, even if the
NAS has indicated that it supports CUI.
If an Access-Accept packet without the CUI attribute was received by
a RADIUS client that requested the CUI attribute, then the
Access-Accept packet MAY be treated as an Access-Reject.
If the CUI was included in an Access-Accept packet, RADIUS clients
supporting the CUI attribute MUST ensure that the CUI attribute
appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
This requirement applies regardless of whether the RADIUS client
requested the CUI attribute.
<a href="./rfc2865">RFC 2865</a> includes the following statements about behaviors of RADIUS
client and server with respect to unsupported attributes:
- "A RADIUS client MAY ignore Attributes with an unknown Type."
- "A RADIUS server MAY ignore Attributes with an unknown Type."
Therefore, RADIUS clients or servers that do not support the CUI may
ignore the attribute.
A RADIUS client requesting the CUI attribute in an Access-Accept
packet MUST include within the Access-Request packet a CUI attribute.
For the initial authentication, the CUI attribute will include a
single NUL character (referred to as a nul CUI). And, during
<span class="grey">Adrangi, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
re-authentication, the CUI attribute will include a previously
received CUI value (referred to as a non-nul CUI value) in the
Access-Accept.
Upon receiving a non-nul CUI value in an Access-Request, the home
RADIUS server MAY verify that the value of CUI matches the CUI from
the previous Access-Accept. If the verification fails, then the
RADIUS server SHOULD respond with an Access-Reject message.
If a home RADIUS server that supports the CUI attribute receives an
Access-Request packet containing a CUI (set to nul or otherwise), it
MUST include the CUI attribute in the Access-Accept packet.
Otherwise, if the Access-Request packet does not contain a CUI, the
home RADIUS server SHOULD NOT include the CUI attribute in the
Access-Accept packet. The Access-Request may be sent either in the
initial authentication or during re-authentication.
A NAS that requested the CUI during re-authentication by including
the CUI in the Access-Request will receive the CUI in the
Access-Accept. The NAS MUST include the value of that CUI in all
Accounting Messages.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. CUI Attribute</span>
A summary of the RADIUS CUI attribute is given below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 89 for Chargeable-User-Identity.
Length: >= 3
String:
The string identifies the CUI of the end-user. This string value
is a reference to a particular user. The format and content of
the string value are determined by the Home RADIUS server. The
binding lifetime of the reference to the user is determined based
on business agreements. For example, the lifetime can be set to
one billing period. RADIUS entities other than the Home RADIUS
server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI. In cases where the
<span class="grey">Adrangi, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
attribute is used to indicate the NAS support for the CUI, the
string value contains a nul character.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Attribute Table</span>
The following table provides a guide to which attribute(s) may be
found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute
Request
0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
Note: If the Access-Accept packet contains CUI, then the NAS MUST
include the CUI in Accounting Requests (Start, Interim, and Stop)
packets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Diameter Consideration</span>
Diameter needs to define an identical attribute with the same Type
value. The CUI should be available as part of the NASREQ application
[<a href="./rfc4005" title=""Diameter Network Access Server Application"">RFC4005</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document uses the RADIUS [<a href="./rfc2865" title=""Remote Authentication Dial In User Service (RADIUS)"">RFC2865</a>] namespace; see
<a href="http://www.iana.org/assignments/radius-types">http://www.iana.org/assignments/radius-types</a>. The IANA has assigned
a new RADIUS attribute number for the CUI attribute.
CUI 89
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
It is strongly recommended that the CUI format used is such that the
real user identity is not revealed. Furthermore, where a reference
is used to a real user identity, it is recommended that the binding
lifetime of that reference to the real user be kept as short as
possible.
The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
However, there is no way to detect or prevent this.
Attempting theft of service, a man-in-the-middle may try to insert,
modify, or remove the CUI in the Access-Accept packets and Accounting
packets. However, RADIUS Access-Accept and Accounting packets
already provide integrity protection.
<span class="grey">Adrangi, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
If the NAS includes CUI in an Access-Request packet, a
man-in-the-middle may remove it. This will cause the Access-Accept
packet to not include a CUI attribute, which may cause the NAS to
reject the session. To prevent such a denial of service (DoS)
attack, the NAS SHOULD include a Message-Authenticator(80) attribute
within Access-Request packets containing a CUI attribute.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors would like to thank Jari Arkko, Bernard Aboba, David
Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for
their feedback and guidance.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2865">RFC2865</a>] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
<a href="./rfc2865">RFC 2865</a>, June 2000.
[<a id="ref-RFC2866">RFC2866</a>] Rigney, C., "RADIUS Accounting", <a href="./rfc2866">RFC 2866</a>, June 2000.
[<a id="ref-RFC4005">RFC4005</a>] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", <a href="./rfc4005">RFC 4005</a>,
August 2005.
[<a id="ref-RFC4282">RFC4282</a>] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", <a href="./rfc4282">RFC 4282</a>, December 2005.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3576">RFC3576</a>] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", <a href="./rfc3576">RFC 3576</a>,
July 2003.
[<a id="ref-RFC3588">RFC3588</a>] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", <a href="./rfc3588">RFC 3588</a>, September 2003.
<span class="grey">Adrangi, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
Authors' Addresses
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 613-591-9104
EMail: avi@bridgewatersystems.com
Jouni Korhonen
Teliasonera Corporation
P.O.Box 970
FIN-00051, Sonera
Finland
Phone: +358405344455
EMail: jouni.korhonen@teliasonera.com
John Loughney
Nokia
Itamerenkatu 11-13
FIN-00180, Helsinki
Finland
Phone: +358504836342
EMail: john.loughney@nokia.com
<span class="grey">Adrangi, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4372">RFC 4372</a> Chargeable User Identity January 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Adrangi, et al. Standards Track [Page 10]
</pre>
|
