Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 2868 compliance #21

Open
MikhailMS opened this issue Sep 21, 2021 · 0 comments
Open

RFC 2868 compliance #21

MikhailMS opened this issue Sep 21, 2021 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers invalid This doesn't seem right

Comments

@MikhailMS
Copy link
Owner

MikhailMS commented Sep 21, 2021

In RFC 2868

Tunnel-Password
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the value of the Tag field is greater than 0x00 and
      less than or equal to 0x1F, it SHOULD be interpreted as indicating
      which tunnel (of several alternatives) this attribute pertains;
      otherwise, the Tag field SHOULD be ignored.

   Salt
      The Salt field is two octets in length and is used to ensure the
      uniqueness of the encryption key used to encrypt each instance of
      the Tunnel-Password attribute 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 Data-Length and Password sub-fields (both of which are
      required), and the optional Padding sub-field.  The Data-Length
      sub-field is one octet in length and contains the length of the
      unencrypted Password sub-field.  The Password sub-field contains
      the actual tunnel password.  If the combined length (in octets) of
      the unencrypted Data-Length and Password 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 Data-Length and Password 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):

            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.

and

## Taken from https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary/radius/dictionary.rfc2868
   ATTRIBUTE	Tunnel-Type                     64	integer	has_tag  
   ATTRIBUTE	Tunnel-Medium-Type		65	integer	has_tag   
   ATTRIBUTE	Tunnel-Client-Endpoint		66	string	has_tag   
   ATTRIBUTE	Tunnel-Server-Endpoint	        67	string	has_tag  
   ATTRIBUTE	Tunnel-Password			69	string	has_tag,encrypt=2
   ATTRIBUTE	Tunnel-Private-Group-Id	        81	string	has_tag
   ATTRIBUTE	Tunnel-Assignment-Id		82	string	has_tag
   ATTRIBUTE	Tunnel-Preference               83	integer	has_tag
   ATTRIBUTE	Tunnel-Client-Auth-Id		90	string	has_tag
   ATTRIBUTE	Tunnel-Server-Auth-Id		91	string	has_tag

Introduces new attributtes with new logic around it, so need to ensure

  • Dictionary parser can handle it
  • Salt for Tunnel-Password is implemented (we do have salt/unsalt functions already, so need to make sure they work here)
@MikhailMS MikhailMS changed the title RFC 2868 complience RFC 2868 compliance Sep 21, 2021
@MikhailMS MikhailMS added enhancement New feature or request good first issue Good for newcomers invalid This doesn't seem right labels Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

1 participant