1-7The attribute types listed in Table 1-2 are defined by RFC 2865, RFC 2866, RFC 2867, and RFC 2568.Extended RADIUS AttributesThe RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific) defined by RFC2865 allows a vender to define extended attributes to implement functions that the standard RADIUSprotocol does not provide.A vendor can encapsulate multiple type-length-value (TLV) sub-attributes in RADIUS packets forextension in applications. As shown in Figure 1-5, a sub-attribute that can be encapsulated in Attribute26 consists of the following four parts:z Vendor-ID (four bytes): Indicates the ID of the vendor. Its most significant byte is 0 and the otherthree bytes contain a code complying with RFC 1700. The vendor ID of H3C is 2011.z Vendor-Type: Indicates the type of the sub-attribute.z Vendor-Length: Indicates the length of the sub-attribute.z Vendor-Data: Indicates the contents of the sub-attribute.Figure 1-5 Segment of a RADIUS packet containing an extended attributeIntroduction to HWTACACSHW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocolbased on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for informationexchange between NAS and HWTACACS server.HWTACACS is mainly used to provide AAA services for terminal users. In a typical HWTACACSapplication, a terminal user needs to log into the device for operations, and HWTACACS authenticates,authorizes and keeps accounting for the user. Working as the HWTACACS client, the device sends theusername and password to the HWTACACS sever for authentication. After passing authentication andbeing authorized, the user can log into the device to perform operations.Differences Between HWTACACS and RADIUSHWTACACS and RADIUS have many common features, like implementing AAA, using a client/servermodel, using shared keys for user information security and having good flexibility and extensibility.Meanwhile, they also have differences, as listed in Table 1-3.
