📄 rfc3182.txt
字号:
RFC 3182 Identity Representation for RSVP October 2001
3.3.3 Digital Signature
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.
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
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.
3.3.4 Policy Error Object
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.
Yadav, et al. Standards Track [Page 7]
RFC 3182 Identity Representation for RSVP October 2001
+----------+----------+----------+----------+
| Length | A-Type | SubType |
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length
Length of the attribute, which MUST be >= 8.
A-Type
POLICY_ERROR_CODE
SubType
No sub types for POLICY_ERROR_CODE are currently defined. This
field MUST be set to 0.
ErrorValue
A 16-bit bit code containing the reason that the policy decision
point failed to process the policy element. IANA acts as a
registry for ErrorValues as described in section 8, IANA
Considerations. 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.
4. Authentication Data Formats
Authentication attributes are grouped in a policy element to
represent the identity credentials.
Yadav, et al. Standards Track [Page 8]
RFC 3182 Identity Representation for RSVP October 2001
4.1 Simple User Authentication
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) ...
+--------------+--------------+--------------+--------------+
4.2 Kerberos User Authentication
Kerberos [RFC 1510] 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) ...
+--------------+--------------+--------------+--------------+
4.2.1. Operational Setting using Kerberos Identities
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
Yadav, et al. Standards Track [Page 9]
RFC 3182 Identity Representation for RSVP October 2001
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.
4.3 Public Key based User Authentication
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.
+--------------+--------------+--------------+--------------+
| 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) ...
+--------------+--------------+--------------+--------------+
4.3.1. Operational Setting for public key based authentication
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.
Yadav, et al. Standards Track [Page 10]
RFC 3182 Identity Representation for RSVP October 2001
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.
4.4 Simple Application Authentication
The application authentication method encodes the application
identification such as an executable filename as plain ASCII or
UNICODE text.
+----------------+--------------+--------------+--------------+
| 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)
+----------------+--------------+--------------+--------------+
5. Operation
+-----+ +-----+
| 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.
Yadav, et al. Standards Track [Page 11]
RFC 3182 Identity Representation for RSVP October 2001
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.
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.
6. Message Processing Rules
6.1 Message Generation (RSVP Host)
An RSVP message is created as specified in [RFC 2205] 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.
Yadav, et al. Standards Track [Page 12]
RFC 3182 Identity Representation for RSVP October 2001
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -