rfc2548.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Implementation Note
         This attribute should only be returned in response to an
         Access-Request packet containing MS-CHAP attributes.

2.4.2.  MS-MPPE-Send-Key

   Description

      The MS-MPPE-Send-Key Attribute contains a session key for use by
      the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
      name implies, this key is intended for encrypting packets sent
      from the NAS to the remote host.  This Attribute is only included
      in Access-Accept packets.

   A summary of the MS-MPPE-Send-Key Attribute format is given below.
   The fields are transmitted left to right.










Zorn                         Informational                     [Page 20]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type
      16 for MS-MPPE-Send-Key.

   Vendor-Length
      > 4

   Salt
      The Salt field is two octets in length and is used to ensure the
      uniqueness of the keys used to encrypt each of the encrypted
      attributes occurring in a given Access-Accept packet.  The most
      significant bit (leftmost) of the Salt field MUST be set (1).  The
      contents of each Salt field in a given Access-Accept packet MUST
      be unique.

   String
      The plaintext String field consists of three logical sub-fields:
      the Key-Length and Key sub-fields (both of which are required),
      and the optional Padding sub-field.  The Key-Length sub-field is
      one octet in length and contains the length of the unencrypted Key
      sub-field.  The Key sub-field contains the actual encryption key.
      If the combined length (in octets) of the unencrypted Key-Length
      and Key sub-fields is not an even multiple of 16, then the Padding
      sub-field MUST be present.  If it is present, the length of the
      Padding sub-field is variable, between 1 and 15 octets.  The
      String field MUST be encrypted as follows, prior to transmission:

         Construct a plaintext version of the String field by concate-
         nating the Key-Length and Key sub-fields.  If necessary, pad
         the resulting string until its length (in octets) is an even
         multiple of 16.  It is recommended that zero octets (0x00) be
         used for padding.  Call this plaintext P.

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.  Encryption
         is performed in the following manner ('+' indicates
         concatenation):



Zorn                         Informational                     [Page 21]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


      b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
      b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
                  .                      .
                  .                      .
                  .                      .
      b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

      The   resulting   encrypted   String   field    will    contain
      c(1)+c(2)+...+c(i).

   On receipt, the process is reversed to yield the plaintext String.

   Implementation Notes
      It is possible that the length of the key returned may be larger
      than needed for the encryption scheme in use.  In this case, the
      RADIUS client is responsible for performing any necessary
      truncation.

      This attribute MAY be used to pass a key from an external (e.g.,
      EAP [15]) server to the RADIUS server.  In this case, it may be
      impossible for the external server to correctly encrypt the key,
      since the RADIUS shared secret might be unavailable.  The external
      server SHOULD, however, return the attribute as defined above; the
      Salt field SHOULD be zero-filled and padding of the String field
      SHOULD be done.  When the RADIUS server receives the attribute
      from the external server, it MUST correctly set the Salt field and
      encrypt the String field before transmitting it to the RADIUS
      client.  If the channel used to communicate the MS-MPPE-Send-Key
      attribute is not secure from eavesdropping, the attribute MUST be
      cryptographically protected.

2.4.3.  MS-MPPE-Recv-Key

   Description

      The MS-MPPE-Recv-Key Attribute contains a session key for use by
      the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
      name implies, this key is intended for encrypting packets received
      by the NAS from the remote host.  This Attribute is only included
      in Access-Accept packets.

   A summary of the MS-MPPE-Recv-Key Attribute format is given below.
   The fields are transmitted left to right.








Zorn                         Informational                     [Page 22]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type
      17 for MS-MPPE-Recv-Key.

   Vendor-Length
      > 4

   Salt
      The Salt field is two octets in length and is used to ensure the
      uniqueness of the keys used to encrypt each of the encrypted
      attributes occurring in a given Access-Accept packet.  The most
      significant bit (leftmost) of the Salt field MUST be set (1).  The
      contents of each Salt field in a given Access-Accept packet MUST
      be unique.

   String
      The plaintext String field consists of three logical sub-fields:
      the Key-Length and Key sub-fields (both of which are required),
      and the optional Padding sub-field.  The Key-Length sub-field is
      one octet in length and contains the length of the unencrypted Key
      sub-field.  The Key sub-field contains the actual encryption key.
      If the combined length (in octets) of the unencrypted Key-Length
      and Key sub-fields is not an even multiple of 16, then the Padding
      sub-field MUST be present.  If it is present, the length of the
      Padding sub-field is variable, between 1 and 15 octets.  The
      String field MUST be encrypted as follows, prior to transmission:

         Construct a plaintext version of the String field by
         concatenating the Key-Length and Key sub-fields.  If necessary,
         pad the resulting string until its length (in octets) is an
         even multiple of 16.  It is recommended that zero octets (0x00)
         be used for padding.  Call this plaintext P.

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.  Encryption
         is performed in the following manner ('+' indicates
         concatenation):



Zorn                         Informational                     [Page 23]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


         b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
         b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
                     .                      .
                     .                      .
                     .                      .
         b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

         The resulting encrypted String field will contain
         c(1)+c(2)+...+c(i).

      On receipt, the process is reversed to yield the plaintext String.

   Implementation Notes
      It is possible that the length of the key returned may be larger
      than needed for the encryption scheme in use.  In this case, the
      RADIUS client is responsible for performing any necessary
      truncation.

      This attribute MAY be used to pass a key from an external (e.g.,
      EAP [15]) server to the RADIUS server.  In this case, it may be
      impossible for the external server to correctly encrypt the key,
      since the RADIUS shared secret might be unavailable.  The external
      server SHOULD, however, return the attribute as defined above; the
      Salt field SHOULD be zero-filled and padding of the String field
      SHOULD be done.  When the RADIUS server receives the attribute
      from the external server, it MUST correctly set the Salt field and
      encrypt the String field before transmitting it to the RADIUS
      client.  If the channel used to communicate the MS-MPPE-Recv-Key
      attribute is not secure from eavesdropping, the attribute MUST be
      cryptographically protected.

2.4.4.  MS-MPPE-Encryption-Policy

   Description

      The MS-MPPE-Encryption-Policy Attribute may be used to signify
      whether the use of encryption is allowed or required.  If the
      Policy field is equal to 1 (Encryption-Allowed), any or none of
      the encryption types specified in the MS-MPPE-Encryption-Types
      Attribute MAY be used.  If the Policy field is equal to 2
      (Encryption-Required), any of the encryption types specified in
      the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
      one MUST be used.

   A summary of the MS-MPPE-Encryption-Policy Attribute format is given
   below.  The fields are transmitted left to right.





Zorn                         Informational                     [Page 24]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Policy
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Policy (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type
      7 for MS-MPPE-Encryption-Policy.

   Vendor-Length
      6

   Policy
      The Policy field is 4 octets in length.  Defined values are:

         1      Encryption-Allowed 2      Encryption-Required

2.4.5.  MS-MPPE-Encryption-Types

   Description

      The MS-MPPE-Encryption-Types Attribute is used to signify the
      types of encryption available for use with MPPE.  It is a four
      octet integer that is interpreted as a string of bits.

   A summary of the MS-MPPE-Encryption-Policy Attribute format is given
   below.  The fields are transmitted left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Types
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Types (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type
      8 for MS-MPPE-Encryption-Types.

   Vendor-Length
      6

   Policy
      The Types field is 4 octets in length.  The following diagram
      illustrates the Types field.




Zorn                         Informational                     [Page 25]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999


         3                   2                   1
       1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                         |S|L| |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      If the L bit is set, RC4[5] encryption using a 40-bit key is
      allowed.  If the S bit is set, RC4 encryption using a 128-bit key
      is allowed.  If both the L and S bits are set, then either 40- or
      128-bit keys may be used with the RC4 algorithm.

2.5.  Attributes for BAP Support

   This section describes a set of vendor-specific RADIUS attributes
   designed to support the dynamic control of bandwidth allocation in
   multilink PPP [11].  Attributes are defined that specify whether use
   of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or
   required on incoming calls, the level of line capacity (expressed as
   a percentage) below which utilization must fall before a link is
   eligible to be dropped, and the length of time (in seconds) that a
   link must be under-utilized before it is dropped.

2.5.1.  MS-BAP-Usage

   Description

      This Attribute describes whether the use of BAP is allowed,
      disallowed or required on new multilink calls.  It MAY be used in
      Access-Accept packets.

   A summary of the MS-BAP-Usage Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type
      13 for MS-BAP-Usage.

   Vendor-Length
      6





Zorn                         Informational                     [Page 26]

RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999