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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
|
<pre>Network Working Group S. Yadav
Request for Comments: 2752 R. Yavatkar
Category: Standards Track Intel
R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
IPHighway
January 2000
<span class="h1">Identity Representation for RSVP</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 (2000). All Rights Reserved.
Abstract
This document describes the representation of identity information in
POLICY_DATA object [<a href="#ref-POL-EXT" title=""RSVP Extensions for Policy Control"">POL-EXT</a>] for supporting policy based admission
control in RSVP. The goal of identity representation is to allow a
process on a system to securely identify the owner and the
application of the communicating process (e.g. user id) and convey
this information in RSVP messages (PATH or RESV) in a secure manner.
We describe the encoding of identities as RSVP policy element. We
describe the processing rules to generate identity policy elements
for multicast merged flows. Subsequently, we describe representations
of user identities for Kerberos and Public Key based user
authentication mechanisms. In summary we describe the use of this
identity information in an operational setting.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Conventions used in this document</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">RFC-2119</a>].
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introduction</span>
RSVP [<a href="./rfc2205">RFC 2205</a>] is a resource reservation setup protocol designed for
an integrated services Internet [<a href="./rfc1633">RFC 1633</a>]. RSVP is used by a host to
request specific quality of service (QoS) from the network for
particular application data streams or flows. RSVP is also used by
routers to deliver QoS requests to all nodes along the path(s) of the
flows and to establish and maintain state to provide the requested
service. RSVP requests will generally result in resources being
reserved in each node along the data path. RSVP allows particular
users to obtain preferential access to network resources, under the
control of an admission control mechanism. Permission to make a
reservation is based both upon the availability of the requested
resources along the path of the data and upon satisfaction of policy
rules. Providing policy based admission control mechanism based on
user identity or application is one of the prime requirements.
In order to solve these problems and implement identity based policy
control it is required to identify the user and/or application making
a RSVP request.
This document proposes a mechanism for sending identification
information in the RSVP messages and enables authorization decisions
based on policy and identity.
We describe the authentication policy element (AUTH_DATA) contained
in the POLICY_DATA object. User process can generate an AUTH_DATA
policy element and gives it to RSVP process (service) on the
originating host. RSVP service inserts AUTH_DATA into the RSVP
message to identify the owner (user and/or application) making the
request for network resources. Network elements, such as routers,
authenticate request using the credentials presented in the AUTH_DATA
and admit the RSVP message based on admission policy. After a request
has been authenticated, first hop router installs the RSVP state and
forwards the new policy element returned by the Policy Decision Point
(PDP) [<a href="#ref-POL-FRAME" title=""A Framework for Policy-based Admission Control RSVP"">POL-FRAME</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Policy Element for Authentication Data</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Policy Data Object Format</span>
POLICY_DATA objects contain policy information and are carried by
RSVP messages. A detail description of the format of POLICY_DATA
object can be found in "RSVP Extensions for Policy Control" [POL-
EXT].
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Authentication Data Policy Element</span>
In this section, we describe a policy element (PE) called
authentication data (AUTH_DATA). AUTH_DATA policy element contains a
list of authentication attributes.
+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+
Length
The length of the policy element (including the Length and P-
Type) is in number of octets (MUST be a multiple of 4) and
indicates the end of the authentication attribute list.
P-Type (Identity Type)
Type of identity information contained in this Policy Element
supplied as the Policy element type (P-type). The Internet
Assigned Numbers Authority (IANA) acts as a registry for policy
element types for identity as described in the [<a href="#ref-POL-EXT" title=""RSVP Extensions for Policy Control"">POL-EXT</a>].
Initially, the registry contains the following P-Types for
identity:
1 AUTH_USER Authentication scheme to identify users
2 AUTH_APP Authentication scheme to identify
applications
Authentication Attribute List
Authentication attributes contain information specific to
authentication method and type of AUTH_DATA. The policy element
provides the mechanism for grouping a collection of
authentication attributes.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Authentication Attributes</span>
Authentication attributes MUST be encoded as a multiple of 4 octets,
attributes that are not a multiple of 4 octets long MUST be padded to
a 4-octet boundary.
+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
Length
The length field is two octets and indicates the actual length of
the attribute (including the Length and A-Type fields) in number
of octets. The length does not include any bytes padding to the
value field to make the attribute multiple of 4 octets long.
A-Type
Authentication attribute type (A-Type) field is one octet. IANA
acts as a registry for A-Types as described in the <a href="#section-9">section 9</a>,
IANA Considerations. Initially, the registry contains the
following A-Types:
1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN
described in [<a href="./rfc1779">RFC 1779</a>]).
2 CREDENTIAL User credential such as Kerberos
ticket, or digital certificate.
Application credential such as
application ID.
3 DIGITAL_SIGNATURE Digital signature of the
authentication data policy element.
4 POLICY_ERROR_OBJECT Detailed information on policy
failures.
SubType
Authentication attribute sub-type field is one octet. Value of
SubType depends on A-type.
Value:
The value field contains the attribute specific information.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a> Policy Locator</span>
POLICY_LOCATOR is used to locate the admission policy for the user
or application. Distinguished Name (DN) is unique for each User or
application hence a DN is used as policy locator.
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
Length
Length of the attribute, which MUST be >= 4.
A-Type
POLICY_LOCATOR
SubType
Following sub types for POLICY_LOCATOR are defined. IANA acts as
a registry for POLICY_LOCATOR sub types as described in the
<a href="#section-9">section 9</a>, IANA Considerations. Initially, the registry contains
the following sub types for POLICY_LOCATOR:
1 ASCII_DN OctetString contains the X.500 DN as described
in the <a href="./rfc1779">RFC 1779</a> as an ASCII string.
2 UNICODE_DN OctetString contains the X.500 DN described in
the <a href="./rfc1779">RFC 1779</a> as an UNICODE string.
3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500
DN. The Kerberos session key or digital
certificate private key is used for encryption.
For Kerberos encryption the format is the same
as returned from gss_seal [<a href="./rfc1509">RFC 1509</a>].
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted
UNICODE X.500 DN. The Kerberos session key or
digital certificate private key is used for
encryption. For Kerberos encryption the format
is the same as returned from gss_seal [RFC
1509].
OctetString
The OctetString field contains the DN.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a> Credential</span>
CREDENTIAL indicates the credential of the user or application to be
authenticated. For Kerberos authentication method the CREDENTIAL
object contains the Kerberos session ticket. For public key based
authentication this field contains a digital certificate.
A summary of the CREDENTIAL attribute format is shown below. The
fields are transmitted from left to right.
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
A-Type
CREDENTIAL
SubType
IANA acts as a registry for CREDENTIAL sub types as described in
the <a href="#section-9">section 9</a>, IANA Considerations. Initially, the registry
contains the following sub types for CREDENTIAL:
1 ASCII_ID OctetString contains user or application
identification in plain ASCII text string.
2 UNICODE_ID OctetString contains user or application
identification in plain UNICODE text string.
3 KERBEROS_TKT OctetString contains Kerberos ticket.
4 X509_V3_CERT OctetString contains X.509 V3 digital
certificate [<a href="#ref-X.509" title=""Internet X.509 Public Key Infrastructure Certificate and CRL Profile"">X.509</a>].
5 PGP_CERT OctetString contains PGP digital certificate.
OctetString
The OctetString contains the user or application credential.
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a> Digital Signature</span>
The DIGITAL_SIGNATURE attribute MUST be the last attribute in the
attribute list and contains the digital signature of the AUTH_DATA
policy element. The digital signature signs all data in the
AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm
used to compute the digital signature depends on the authentication
method specified by the CREDENTIAL SubType field.
A summary of DIGITAL_SIGNATURE attribute format is described below.
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
ti3 A-Type
DIGITAL_SIGNATURE
SubType
No sub types for DIGITAL_SIGNATURE are currently defined. This
field MUST be set to 0.
OctetString
OctetString contains the digital signature of the AUTH_DATA.
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a> Policy Error Object</span>
This attribute is used to carry any specific policy control errors
generated by a node when processing/validating an Authentication Data
Policy Element. When a RSVP policy node (local policy decision point
or remote PDP) encounters a request that fails policy control due to
its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE
containing additional information about the reason the failure
occurred into the policy element. This will then cause an appropriate
PATH_ERROR or RESV_ERROR message to be generated with the policy
element and appropriate RSVP error code in the message, which is
returned to the request's source.
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not
contain the POLICY_ERROR_OBJECT attribute. These are only inserted
into PATH_ERROR and RESV_ERROR messages when generated by policy
aware intermediate nodes.
+----------+----------+----------+----------+
| Length | A-Type |SubType(0)|
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length
Length of the attribute, which MUST be >= 8.
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
A-Type
POLICY_ERROR_CODE
ErrorValue
A 32-bit bit code containing the reason that the policy decision
point failed to process the policy element. Following values have
been defined.
1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege.
4 EXPIRED_CREDENTIAL The credential has expired.
5 IDENTITY_CHANGED Identity has changed.
OctetString
The OctetString field contains information from the policy
decision point that MAY contain additional information about the
policy failure. For example, it may include a human-readable
message in the ASCII text.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Authentication Data Formats</span>
Authentication attributes are grouped in a policy element to
represent the identity credentials.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Simple User Authentication</span>
In simple user authentication method the user login ID (in plain
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary
of the simple user AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Kerberos User Authentication</span>
Kerberos [<a href="./rfc1510">RFC 1510</a>] authentication uses a trusted third party (the
Kerberos Distribution Center - KDC) to provide for authentication of
the user to a network server. It is assumed that a KDC is present and
both host and verifier of authentication information (router or PDP)
implement Kerberos authentication.
A summary of the Kerberos AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Operational Setting using Kerberos Identities</span>
An RSVP enabled host is configured to construct and insert AUTH_DATA
policy element into RSVP messages that designate use of the Kerberos
authentication method (KERBEROS_TKT). Upon RSVP session
initialization, the user application contacts the KDC to obtain a
Kerberos ticket for the next network node or its PDP. A router when
generating a RSVP message contacts the KDC to obtain a Kerberos
ticket for the next hop network node or its PDP. The identity of the
PDP or next network hop can be statically configured, learned via
DHCP or maintained in a directory service. The Kerberos ticket is
sent to the next network node (which may be a router or host) in a
RSVP message. The KDC is used to validate the ticket and
authentication the user sending RSVP message.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> Public Key based User Authentication</span>
In public key based user authentication method digital certificate is
encoded as user credentials. The digital signature is used for
authenticating the user. A summary of the public key user AUTH_DATA
policy element is shown below.
<span class="grey">Yadav, 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="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Operational Setting for public key based authentication</span>
Public key based authentication assumes following:
- RSVP service requestors have a pair of keys (private key and
public key).
- Private key is secured with the user.
- Public keys are stored in digital certificates and a trusted
party, certificate authority (CA) issues these digital
certificates.
- The verifier (PDP or router) has the ability to verify the
digital certificate.
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE.
User Authenticators (router, PDP) use the user's public key (stored
in the digital certificate) to verify the signature and authenticate
the user.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a> Simple Application Authentication</span>
The application authentication method encodes the application
identification such as an executable filename as plain ASCII or
UNICODE text.
<span class="grey">Yadav, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Operation</span>
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA PE
Network nodes (hosts/routers) generate AUTH_DATA policy elements,
contents of which are depend on the identity type used and the
authentication method used. These generally contain authentication
credentials (Kerberos ticket or digital certificate) and policy
locators (which can be the X.500 Distinguished Name of the user or
network node or application names). Network nodes generate AUTH_DATA
policy element containing the authentication identity when making the
RSVP request or forwarding a RSVP message.
Network nodes generate user AUTH_DATA policy element using the
following rules
1. For unicast sessions the user policy locator is copied from the
previous hop. The authentication credentials are for the current
network node identity.
2. For multicast messages the user policy locator is for the current
network node identity. The authentication credentials are for the
current network node.
<span class="grey">Yadav, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
Network nodes generate application AUTH_DATA policy element using the
following rules:
1. For unicast sessions the application AUTH_DATA is copied from the
previous hop.
2. For multicast messages the application AUTH_DATA is either the
first application AUTH_DATA in the message or chosen by the PDP.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Message Processing Rules</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a> Message Generation (RSVP Host)</span>
An RSVP message is created as specified in [<a href="./rfc2205">RFC2205</a>] with following
modifications.
1. RSVP message MAY contain multiple AUTH_DATA policy elements.
2. Authentication policy element (AUTH_DATA) is created and the
IdentityType field is set to indicate the identity type in the
policy element.
- DN is inserted as POLICY_LOCATOR attribute.
- Credentials such as Kerberos ticket or digital certificate are
inserted as the CREDENTIAL attribute.
3. POLICY_DATA object (containing the AUTH_DATA policy element) is
inserted in the RSVP message in appropriate place. If INTEGRITY
object is not computed for the RSVP message then an INTEGRITY
object SHOULD be computed for this POLICY_DATA object, as
described in the [POL_EXT], and SHOULD be inserted as a Policy
Data option.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a> Message Reception (Router)</span>
RSVP message is processed as specified in [<a href="./rfc2205">RFC2205</a>] with following
modifications.
1. If router is not policy aware then it SHOULD send the RSVP message
to the PDP and wait for response. If the router is policy unaware
then it ignores the policy data objects and continues processing
the RSVP message.
2. Reject the message if the response from the PDP is negative.
3. Continue processing the RSVP message.
<span class="grey">Yadav, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a> Authentication (Router/PDP)</span>
1. Retrieve the AUTH_DATA policy element. Check the PE type field and
return an error if the identity type is not supported.
2. Verify user credential
- Simple authentication: e.g. Get user ID and validate it, or get
executable name and validate it.
- Kerberos: Send the Kerberos ticket to the KDC to obtain the
session key. Using the session key authenticate the user.
- Public Key: Validate the certificate that it was issued by a
trusted Certificate Authority (CA) and authenticate the user or
application by verifying the digital signature.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Error Signaling</span>
If PDP fails to verify the AUTH_DATA policy element then it MUST
return policy control failure (Error Code = 02) to the PEP. The error
values are described in [<a href="./rfc2205">RFC 2205</a>] and [<a href="#ref-POL-EXT" title=""RSVP Extensions for Policy Control"">POL-EXT</a>]. Also PDP SHOULD
supply a policy data object containing an AUTH_DATA Policy Element
with A-Type=POLICY_ERROR_CODE containing more details on the Policy
Control failure (see <a href="#section-3.3.4">section 3.3.4</a>). The PEP will include this Policy
Data object in the outgoing RSVP Error message.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
Following the policies outlined in [<a href="#ref-IANA-CONSIDERATIONS" title="">IANA-CONSIDERATIONS</a>],
authentication attribute types (A-Type)in the range 0-127 are
allocated through an IETF Consensus action, A-Type values between
128-255 are reserved for Private Use and are not assigned by IANA.
Following the policies outlined in [<a href="#ref-IANA-CONSIDERATIONS" title="">IANA-CONSIDERATIONS</a>],
POLICY_LOCATOR SubType values in the range 0-127 are allocated
through an IETF Consensus action, POLICY_LOCATOR SubType values
between 128-255 are reserved for Private Use and are not assigned by
IANA.
Following the policies outlined in [<a href="#ref-IANA-CONSIDERATIONS" title="">IANA-CONSIDERATIONS</a>], CREDENTIAL
SubType values in the range 0-127 are allocated through an IETF
Consensus action, CREDENTIAL SubType values between 128-255 are
reserved for Private Use and are not assigned by IANA.
<span class="grey">Yadav, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The purpose of this memo is to describe a mechanism to authenticate
RSVP requests based on user identity in a secure manner. RSVP
INTEGRITY object is used to protect the policy object containing user
identity information from security (replay) attacks. Combining the
AUTH_DATA policy element and the INTEGRITY object results in a secure
access control that enforces authentication based on both the
identity of the user and the identity of the originating node.
Simple authentication does not contain credential that can be
securely authenticated and is inherently less secured.
The Kerberos authentication mechanism is reasonably well secured.
User authentication using a public key certificate is known to
provide the strongest security.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
We would like to thank Andrew Smith, Bob Lindell and many others for
their valuable comments on this memo.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
[<a id="ref-ASCII">ASCII</a>] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4-
1986.
[<a id="ref-IANA-CONSIDERATIONS">IANA-CONSIDERATIONS</a>] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
[<a id="ref-POL-EXT">POL-EXT</a>] Herzog, S., "RSVP Extensions for Policy
Control", <a href="./rfc2750">RFC 2750</a>, January 2000.
[<a id="ref-POL-FRAME">POL-FRAME</a>] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-based Admission Control
RSVP", <a href="./rfc2753">RFC 2753</a>, January 2000.
[<a id="ref-RFC 1510">RFC 1510</a>] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", <a href="./rfc1510">RFC 1510</a>,
September 1993.
[<a id="ref-RFC 1704">RFC 1704</a>] Haller, N. and R. Atkinson, "On Internet
Authentication", <a href="./rfc1704">RFC 1704</a>, October 1994.
<span class="grey">Yadav, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
[<a id="ref-RFC 1779">RFC 1779</a>] Killie, S., "A String Representation of
Distinguished Names", <a href="./rfc1779">RFC 1779</a>, March 1995.
[<a id="ref-RFC 2205">RFC 2205</a>] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification",
<a href="./rfc2205">RFC 2205</a>, September 1997.
[<a id="ref-RFC 2209">RFC 2209</a>] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing
Rules", <a href="./rfc2209">RFC 2209</a>, September 1997.
[<a id="ref-UNICODE">UNICODE</a>] The Unicode Consortium, "The Unicode Standard,
Version 2.0", Addison-Wesley, Reading, MA,
1996.
[<a id="ref-X.509">X.509</a>] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", <a href="./rfc2459">RFC 2459</a>, January
1999.
[<a id="ref-X.509-ITU">X.509-ITU</a>] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509
ISO/IEC 9594-8
<span class="grey">Yadav, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Author Information</span>
Satyendra Yadav
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124
EMail: Satyendra.Yadav@intel.com
Raj Yavatkar
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124
EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: rameshpa@microsoft.com
Peter Ford
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: peterf@microsoft.com
Tim Moore
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: timmoore@microsoft.com
Shai Herzog
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
EMail: herzog@iphighway.com
<span class="grey">Yadav, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2752">RFC 2752</a> Identity Representation for RSVP January 2000</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yadav, et al. Standards Track [Page 17]
</pre>
|
