Báo cáo Nghiên cứu về Firewall ASA

IUS phải chuyển một gói tin với các trường mã thiết lập là 5 (Accounting-Response). Khi gói tin Accounting-Response được tiếp nhận bởi máy khách, trường nhận dạng trùng khớp với một Accounting-Request chờ xử lý. Trường phải xác thực phản hồi phải chứa các phản hồi chính xác cho các Accounting-Request chờ xử lý. Gói tin không hợp lệ được âm thầm bỏ đi. Một gói Accounting-Response RADIUS không bắt buộc phải có những thuộc tính trong đó. Mã (5) Từ định danh (Duy nhất) Độ dài (Tiêu đề và tải trọng) Bộ xác thực (Phản hồi) Các thuộc tính: Chứa hoặc không chứa danh sách các thuộc tính (Tùy biến) Hình 2-9: Gói tin Accounting-Response điển hình Mã: 5 – Accounting-Response. Định danh: Các trường nhận dạng là một bản sao của trường nhận dạng của gói Accounting-Request đã dẫn đến gói Accounting-Response này. Xác thực phản hồi: Các xác thực phản hồi của một gói Accounting-Response chứa một giá trị mảng băm MD5 16 octet tính theo phương pháp mô tả trong "Xác thực phản hồi" ở trên. Thuộc tính: Các trường thuộc tính thay đổi trong chiều dài, và có một danh sách trống hay nhiều thuộc tính. 2.4. Bí mật chia sẻ: Để tăng cường an ninh và tăng tính toàn vẹn giao dịch, giao thức RADIUS sử dụng khái niệm bí mật chia sẻ. Bí mật chia sẻ là những giá trị tạo ra một cách ngẫu nhiên mà cả hai máy khách và máy chủ đều biết (vì thế mà gọi "chia sẻ"). Những bí mật chia sẻ được sử dụng trong tất cả các hoạt động có yêu cầu dữ liệu ẩn và giá trị che giấu. Giới hạn kỹ thuật duy nhất là những bí mật chia sẻ phải có chiều dài lớn hơn 0, nhưng RFC khuyến cáo rằng các bí mật ít nhất là 16 octet. Một bí mật có độ dài đó là hầu như không thể bẻ với phương pháp vét cạn. Bí mật chia sẻ (thường chỉ gọi là "bí mật") là duy nhất với một cặp máy khách và máy chủ RADIUS nói riêng. Ví dụ, nếu một người sử dụng đăng ký nhiều nhà cung cấp dịch vụ Internet để truy cập quay số, người dùng này đã gián tiếp tạo các yêu cầu tới nhiều máy chủ RADIUS. Những bí mật chia sẻ giữa thiết bị NAS máy khách tại các ISP A, B, và C được sử dụng để giao tiếp với các máy chủ RADIUS tương ứng không phù hợp. Trong khi một số triển khai RADIUS quy mô lớn hơn có thể tin rằng bảo vệ an ninh giao dịch bằng cách sử dụng một sự thay đổi bí mật chia sẻ tự động là một bước đi thận trọng, có một khó khăn tiềm ẩn khá lớn: không có sự bảo đảm các máy khách và các máy chủ có thể đồng bộ hóa với các bí mật chia sẻ mới trong thời gian thích hợp nhất. Và ngay cả khi nó đã được chắc chắn rằng các đồng bộ hóa đồng thời có thể xảy ra, nếu còn tồn tại các yêu cầu tới các máy chủ RADIUS và máy khách đang bận xử lý (và, do đó, nó bỏ lỡ thời cơ để đồng bộ hóa các bí mật mới), sau đó những yêu cầu còn tồn tại sẽ bị từ chối bởi máy chủ. 2.5. Các thuộc tính và giá trị: 2.5.1. Các thuộc tính: Số 1-255 Độ dài >3 Giá trị Phụ thuộc vào số thuộc tính Các thuộc tính Tiêu đề Tải trọng AVP Gói RADIUS Hình 2-10: Mẫu truyền các cặp giá trị thuộc tính (AVP) tiêu chuẩn Số thuộc tính: Con số này biểu thị các loại thuộc tính trình bày trong gói. Tên của thuộc tính không được thông qua trong gói - chỉ có số. Nói chung, số thuộc tính có thể trong khoảng 1-255, với một số cụ thể phục vụ như là một "cửa ngõ" của các loại cho các nhà cung cấp để cung cấp các thuộc tính cụ thể của mình. Chiều dài thuộc tính: Trường này mô tả chiều dài của trường thuộc tính, mà cần phải từ 3 trở lên. Trường này theo cách tương tự như các lĩnh vực chiều dài của tiêu đề gói tin RADIUS. Giá trị: Chứa đặc điểm hoặc đặc tính của chính thuộc tính đó, trường này cần thiết cho mỗi thuộc tính trình bày, thậm chí nếu giá trị bản thân nó là bằng không. Độ dài này sẽ thay đổi dựa trên bản chất vốn có của các thuộc tính của nó. Cơ cấu AVP thể hiện trong hình 2-6 bao gồm một tập liên tục các byte chứa ít nhất ba octet, với các octet đầu tiên là loại, thứ hai là chiều dài, và octet cuối cùng là giá trị của các thuộc tính của chính nó. Các máy chủ RADIUS biết đầy đủ về một thuộc tính có tên gọi chính thức của nó không cần được truyền đi trong gói. Các mã số (số thuộc tính) là đủ để suy ra loại thông tin được truyền đi trong giá trị cụ thể đó. Các loại thuộc tính: Có 6 loại như được nêu trong RFC: Số nguyên (INT): là những giá trị có chứa số nguyên. Một thuộc tính như Idle Timeout có thể được thiết lập giá trị số nguyên là 15. Liệt kê (ENUM): dữ liệu đó là của các loại liệt kê bao gồm một số nguyên, nhưng giá trị này dựa trên một tập hợp cấu hình người sử dụng của dãy nhiều giá trị và nhiều ý nghĩa. Có thể gặp phải các giá trị liệt kê được gọi là giá trị số nguyên theo ngữ nghĩa, trong khi không theo ngữ nghĩa giá trị nguyên chỉ đơn giản là loại số nguyên. Địa chỉ IP (IPADDR): loại dữ liệu này là một số 32-bit được thiết kế để thông qua một địa chỉ IP chính xác. Trong khi RADIUS theo mặc định sẽ xem xét một địa chỉ IP theo giá trị, một số triển khai thực hiện có thể được cấu hình để xử lý nó với một giá trị định sẵn, chẳng hạn như một subnet mask riêng. Ngoài ra, một phần mở rộng gần đây để các giao thức RADIUS cho phép các địa chỉ IPv6 được sử dụng trong loại này. Chuỗi ký tự (STRING): Chuỗi ký tự thường được xác định là chuỗi in UTF-8 có thể được đọc theo giá trị. Dữ liệu được truyền dưới dạng một dãy ký tự có thể bị chặn hay không bị chặn, bất cứ cái nào là thích hợp. Ngày tháng (DATE): là một con số không dấu 32-bit đại diện cho giây trôi qua kể từ ngày 1 tháng 1 năm 1970. Nhị phân (BINARY): Thường riêng biệt với một sự thực thi, các giá trị nhị phân ("0" hoặc "1") được đọc theo giá trị. Các thuộc tính nhà cung cấp cụ thể: Như với hầu hết các giao thức RADIUS, có nhiều sự linh hoạt đối với các loại thuộc tính nhà cung cấp cụ thể xảy ra trong nhiều thực hiện khác nhau. Phần lớn thuộc tính này tạo ra là để trực tiếp hỗ trợ các tính năng đặc biệt, các đặc trưng không chuẩn hoặc gia tăng giá trị mà một số thiết bị máy khách RADIUS đặc biệt có khả năng cung cấp. Tất nhiên, có lẽ bởi vì trong thực tế là một tiêu chuẩn, một số nhà cung cấp - đặc biệt là Robotics/3Com Hoa Kỳ - không theo đặc tả RFC. Các giao thức RADIUS định nghĩa một AVP cụ thể như là một "cửa ngõ" AVP trong đó các thuộc tính nhà cung cấp cụ thể, hoặc VSAs, có thể được đóng gói. VSA được thực hiện ở tải trọng giá trị của AVP tiêu chuẩn 26, được gọi là nhà cung cấp cụ thể. Hình 2-11 cho thấy AVP tiêu chuẩn và làm thế nào thông tin được thực hiện trong VSA. Số 26 Độ dài X Giá trị ID 262 Số 47 Độ dài X Giá trị … VAS bên trong tải trọng Tải trọng gói RADIUS Hình 2-11: Sự truyền đi của 1 VAS bên trong 1 AVP tiêu chuẩn. ID nhà cung cấp Phần này của VSA gồm bốn octet mà đại diện cho nhà phát triển / thiết kế / chủ sở hữu của VSA. Những mã số tiêu chuẩn được quy định trong tài liệu RFC 1700 là "Các số được gán”. Cụ thể hơn, các nhà cung cấp cá nhân được mã hoá với con số duy nhất được gọi là mã doanh nghiệp tư nhân quản lý mạng hoặc NMPECs. Thứ tự của các nội dung trường ID nhà cung cấp được dựa trên một tiêu chuẩn nghiêm ngặt, với byte cao nhất để giá trị 4 octet được thiết lập về 0, và sau đó 3 byte cuối cùng đặt vào mã NMPEC. Loại nhà cung cấp Trường loại nhà cung cấp, dài một octet, chức năng hành xử theo cách tương tự như số thuộc tính trong một AVP tiêu chuẩn. Các loại nhà cung cấp là những giá trị với phạm vi từ 1 đến 255, và tầm quan trọng và ý nghĩa của từng giá trị được biết đến bên trong các máy chủ RADIUS. Chiều dài Trường này là một con số một octet cho biết chiều dài của toàn bộ VSA, với chiều dài tối thiểu của toàn bộ VSA là 7. Một lần nữa, hoạt động của trường này là tương tự như lĩnh vực chiều dài trong một tiêu chuẩn, RFC định nghĩa AVP. Giá trị Các trường giá trị được yêu cầu phải dài ít nhất một octet và chứa dữ liệu được cụ thể cho các chính VSA đó. Hầu hết các giá trị này được đọc, hiểu, và phân tích bởi máy khách và máy chủ RADIUS trên đầu thu nhận thức của các tính năng đặc biệt và khả năng phi tiêu chuẩn mà triển khai thực hiện cụ thể của chúng có hỗ trợ. 2.5.2. Các giá trị: Tất cả các thuộc tính phải có giá trị, thậm chí nếu giá trị của thuộc tính này là vô giá trị. Giá trị đại diện cho các thông tin mà mỗi thuộc tính riêng biệt được thiết kế để chuyển tải. Chúng mang theo "phần cốt lõi" của thông tin. Giá trị phải phù hợp với các quy tắc loại thuộc tính. Bảng 2-8 cho thấy ví dụ của từng loại thuộc tính và trường giá trị dự kiến tải trọng cho từng loại. Loại thuộc tính Chiều dài (Octet) Kích thước / Phạm vi Ví dụ tải trọng Số nguyên (INT) 4 32 bit Không dấu 6 256 2432 65536 Liệt kê (ENUM) 4 32 bit Không dấu 3 = Callback-Login 4 = Callback-Framed 13 = Framed-Compression 26 = Vendor-Specific Chuỗi (String) 1-253 Tùy biến "HUTECH" "Long" "206.229.254.2" "google.com" Địa chỉ IP (IPADDR) 4 32 bit 0xFFFFFE 0xC0A80102 0x1954FF8E 0x00000A Ngày tháng (DATE) 4 32 bit Không dấu 0xC0A80102 0xFFFFFE 0x00000A 0x1954FF8E Nhị phân (BINARY) 1 1 bit 0 1 Mỗi thuộc tính giá trị được liệt kê trong RFC RADIUS. 3. Hoạt động: 3.1. Quá trính truy cập: Khi một máy khách được cấu hình để sử dụng RADIUS, bất kỳ người sử dụng của máy khách đưa ra thông tin xác thực cho máy khách. Điều này có thể được tùy biến với một đăng nhập nhanh chóng, nơi người dùng sẽ nhập tên người dùng và mật khẩu của họ. Máy khách tạo ra một "Access-Request" có chứa các thuộc tính như tên của người dùng, mật khẩu của người dùng, các ID của máy khách và ID cổng mà người dùng đang truy cập. Khi có mật khẩu, nó được ẩn bằng cách sử dụng một phương pháp dựa trên MD5. Các Access-Request được gửi tới máy chủ RADIUS qua mạng. Nếu không có phản hồi được trả về trong một khoảng thời gian, yêu cầu được gửi lại một số lần. Các máy khách cũng có thể chuyển tiếp yêu cầu tới một máy chủ thay thế hoặc các máy chủ trong trường hợp máy chủ chính bị ngừng hoạt động hoặc không thể truy cập. Một máy chủ thay thế có thể được sử dụng hoặc sau khi một số cố gắng truy cập tới các máy chủ chính bị lỗi, hoặc trong một kiểu vận hành lần lượt. Một khi các máy chủ RADIUS nhận được yêu cầu, nó xác nhận hợp lệ của máy khách gửi. Một yêu cầu từ máy khách mà các máy chủ RADIUS không có một bí mật được chia sẻ phải được âm thầm bỏ đi. Nếu máy khách là hợp lệ, máy chủ RADIUS tra cứu một cơ sở dữ liệu của người dùng để tìm người sử dụng có tên phù hợp với yêu cầu. Mục người sử dụng trong cơ sở dữ liệu chứa một danh sách các yêu cầu đó phải được đáp ứng để cho phép người sử dụng truy cập. Điều này luôn luôn bao gồm xác minh mật khẩu, nhưng cũng có thể chỉ định các máy khách hoặc cổng mà người dùng được phép truy cập. Máy chủ RADIUS có thể làm cho yêu cầu của các máy chủ khác đáp ứng các yêu cầu, trong trường hợp nó hoạt động như một máy khách. Nếu bất kỳ thuộc tính Proxy-State được đưa ratrong các Access-Request, chúng phải được sao chép chưa sửa đổi và đặt vào các gói tin trả lời. Các thuộc tính khác có thể được đặt trước, sau, hoặc thậm chí giữa các thuộc tính Proxy-State. Nếu điều kiện nào không được đáp ứng, máy chủ RADIUS gửi một phản hồi "Access-Reject" cho biết yêu cầu người sử dụng này không hợp lệ. Nếu muốn, các máy chủ có thể bao gồm các tin nhắn văn bản trong Access-Reject có thể được hiển thị bởi các máy khách cho người dùng. Không có thuộc tính khác (trừ Proxy-State) được phép trong một Access-Reject. Nếu tất cả các điều kiện được đáp ứng và các máy chủ RADIUS muốn ra một thách thức mà người dùng phải đáp ứng, các máy chủ RADIUS gửi một phản hồi "Access-Challenge". Nó có thể bao gồm các tin nhắn văn bản được hiển thị bởi các máy khách cho người sử dụng phản hồi cho thách thức này, và có thể bao gồm một thuộc tính trạng thái. Nếu máy khách nhận được một Access-Challenge và hỗ trợ thách thức / phản ứng nó có thể hiển thị các tin nhắn văn bản, nếu có, cho người sử dụng, và sau đó nhắc nhở người dùng về một phản hồi. Máy khách sau đó nộp lại bản gốc Access-Request của nó với một ID yêu cầu mới, với các thuộc tính người dùng mật khẩu thay thế bằng các phản hồi (đã mã hóa), và bao gồm cả các thuộc tính trạng thái từ các Access-Challenge, nếu có. Chỉ có 0 hoặc 1 thể hiện của thuộc tính trạng thái có mặt trong yêu cầu. Máy chủ có thể đáp ứng với Access-Request mới này với một Access-Accept, một Access-Reject, hoặc một Access-Challenge khác. Nếu có đủ điều kiện, danh sách các giá trị cấu hình cho người sử dụng được đặt vào một phản hồi "Access-Accept". Những giá trị này bao gồm các loại hình dịch vụ (ví dụ: SLIP, PPP, người dùng đăng nhập) và tất cả các giá trị cần thiết để cung cấp các dịch vụ mong muốn. Đối với SLIP và PPP, điều này có thể bao gồm giá trị như địa chỉ IP, subnet mask, MTU, nén mong muốn, và nhận dạng lọc gói mong muốn. Đối với những người dùng chế độ ký tự, điều này có thể bao gồm giá trị như giao thức và máy chủ mong muốn. Trong xác thực thách thức / phản hồi, người sử dụng được cho một số không thể đoán trước và thách thức để mã hóa nó và trả lại kết quả. Người được ủy quyền đều được trang bị các thiết bị đặc biệt như thẻ thông minh hoặc các phần mềm tạo thuận lợi cho tính toán của các phản hồi chính xác một cách dễ dàng. Người sử dụng trái phép, thiếu thiết bị thích hợp hoặc phần mềm và không biết khóa bí mật cần thiết để cạnh tranh như một thiết bị hoặc phần mềm, chỉ có thể đoán phản hồi. Các gói tin Access-Challenge thường có chứa một tin nhắn trả lời bao gồm một thách thức để được hiển thị cho người dùng, chẳng hạn như một giá trị số không bao giờ được lặp lại. Người sử dụng sau đó đi vào các thách thức trong thiết bị của mình (hoặc phần mềm) và tính toán một phản hồi, người dùng nhập vào máy khách rồi máy đó chuyển tiếp nó tới máy chủ RADIUS thông qua một Access-Request thứ hai. Nếu phản hồi trùng khớp với phản hồi mong muốn máy chủ RADIUS trả lời với một Access-Accept, nếu không một Access-Reject sẽ được trả về máy khách. 1 3 2 4 6 5 Người dùng Máy chủ Radius ACS ASA Hình 2-12: Quá trình xác thực RADIUS đơn giản. Người dùng cố gắng truy cập vào Cisco ASA. Cisco ASA yêu cầu người dùng nhập tên và mật khẩu. Người dùng nhập vào thông số của mình và gửi cho cisco ASA. Cisco ASA gửi gói Access-Request tới máy chủ RADIUS. Nếu thông số người dùng nhập có trong cơ sở dữ liệu tại máy chủ RADIUS, máy chủ RADIUS sẽ gửi gói Access-Accept về cho Cisco ASA, nếu thông số người dùng nhập không có thì máy chủ RADIUS sẽ gửi gói Access-Reject về cho cisco ASA. 6) Cisco ASA sẽ phản hồi về cho máy khách biết được phép hay không được phép truy cập vào 1 dịch vụ cụ thể. 3.2. Quá trình kế toán: Khi một máy khách được cấu hình để sử dụng RADIUS kế toán, khi bắt đầu cung cấp dịch vụ nó sẽ tạo ra một gói tin bắt đầu kế toán mô tả các loại hình dịch vụ được cung cấp và người sử dụng nó đang được chuyển tới, và sẽ gửi tới máy chủ kế toán RADIUS, trong đó sẽ gửi lại một xác nhận rằng gói tin đã được nhận. Khi kết thúc cung cấp dịch vụ máy khách sẽ tạo ra một gói kết thúc kế toán mô tả các loại hình dịch vụ đã được giao và thông số tùy ý như là thời gian trôi qua, octet vào và ra, hoặc các gói dữ liệu vào và ra. Nó sẽ gửi tới máy chủ kế toán RADIUS, và sẽ gửi phản hồi một xác nhận rằng gói tin đã được nhận. Accounting-Request (dù cho bắt đầu hoặc kết thúc) được gửi tới máy chủ kế toán RADIUS qua mạng. Nó khuyến cáo các khách hàng tiếp tục cố gắng gửi gói tin Accounting-Request cho đến khi nhận được một xác nhận, bằng cách sử dụng một số hình thức chờ để truyền. Nếu không có phản hồi được trả về trong một khoảng thời gian, yêu cầu được gửi lại một số lần. Máy khách cũng có thể chuyển tiếp yêu cầu tới một máy chủ thay thế hoặc các máy chủ trong trường hợp máy chủ chính ngừng hoạt động hoặc không thể truy cập. Một máy chủ thay thế có thể được sử dụng hoặc sau khi một số cố gắng đến các máy chủ chính bị lỗi, hoặc trong một kiểu vận hành lần lượt. Máy chủ kế toán RADIUS có thể làm cho yêu cầu của các máy chủ khác đáp ứng các yêu cầu, trong trường hợp nó hoạt động như một máy khách. Nếu máy chủ kế toán RADIUS không thể thành công ghi lại các gói tin kế toán, nó không phải gửi một xác nhận Accounting-Response cho máy khách. 4. RFCs: 4.1. Nguồn gốc: RADIUS ban đầu được quy định trong một RFI bởi Merit Network vào năm 1991 để kiểm soát truy cập quay số tới NSFNET. Livingston Enterprises trả lời cho RFI với mô tả của một máy chủ RADIUS. Merit Network quyết định liện hệ với Livingston Enterprises giao hàng loạt PortMaster của các Network Access Server và máy chủ RADIUS ban đầu cho Merit. RADIUS sau đó (1997) được xuất bản như RFC 2058 và RFC 2059 (phiên bản hiện tại là RFC 2865 và RFC 2866). Bây giờ, tồn tại một số máy chủ RADIUS thương mại và mã nguồn mở. Các tính năng có thể khác nhau, nhưng hầu hết có thể thấy sử dụng trong các tập tin văn bản, máy chủ LDAP, cơ sở dữ liệu khác nhau... Tài liệu kế toán có thể được ghi vào tập tin văn bản, cơ sở dữ liệu khác nhau, chuyển tiếp đến máy chủ bên ngoài... SNMP thường được sử dụng để giám sát từ xa và kiểm tra xem một máy chủ RADIUS còn hoạt động hay không. Các máy chủ RADIUS proxy được sử dụng để tập trung quản lý và có thể viết lại các gói tin RADIUS (đối với lý do bảo mật, hoặc để Chuyển đổi giữa các nhà cung cấp). Các giao thức Diameter là kế hoạch thay thế cho RADIUS. Diameter sử dụng SCTP hoặc TCP trong khi RADIUS sử dụng UDP là lớp vận chuyển. 4.2. Bảng RFCs: RFC Tiêu đề Ngày RFC 2548 Microsoft Vendor-specific RADIUS Attributes 3/1999 RFC 2865 Remote Authentication Dial In User Service (RADIUS) 6/2000 RFC 2866 RADIUS Accounting 6/2000 RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support 6/2000 RFC 2868 RADIUS Attributes for Tunnel Protocol Support 6/2000 RFC 2869 RADIUS Extensions 6/2000 RFC 3162 RADIUS and IPv6 8/2001 RFC 3579 RADIUS Support for EAP 9/2003 RFC 5080 Common RADIUS Implementation Issues and Suggested Fixes 12/2007 RFC 5997 Use of Status-Server Packets in the RADIUS Protocol 8/2010 4.3. Sơ lược về RADIUS RFCs: 4.3.1. RFC 2865: RFC 2865 – Remote Authentication Dial In User Service: chủ yếu mô tả về cơ chế xác thực và ủy quyền khi người dùng muốn truy cập. Trong RFC có giới thiệu cấu trúc các gói tin cần dùng để thực hiện xác thực và ủy quyền cho người dùng truy cập và các thuộc tính dùng để mô tả trong các gói tin. Đồng thời cũng trình bày về cơ chế hoạt động và các trường hợp xảy ra khi người dùng muốn truy cập. Một số thay đổi so với bản RFC 2138 trước đó: Strings nên sử dụng UTF-8 thay vì US-ASCII và nên được xử lý như là dữ liệu 8-bit. Integers và dates bây giờ được xác định là giá trị 32 bit không dấu. Danh sách cập nhật các thuộc tính có thể được bao gồm trong Access-Challenge để phù hợp với các bảng thuộc tính. User-Name đề cập đến các nhận dạng truy cập mạng. User-Name bây giờ có thể được gửi trong Access-Accept để sử dụng với kế toán và đăng nhập từ xa. Giá trị them vào cho Service-Type, Login-Service, Framed-Protocol, Framed-Compression, và NAS-Port-Type. NAS-Port có thể sử dụng tất cả 32 bit. Các ví dụ hiện nay bao gồm hiển thị hệ thập lục phân của các gói dữ liệu. Cổng UDP nguồn phải được sử dụng kết hợp với bộ nhận dạng yêu cầu khi xác định các bản sao. Nhiều thuộc tính phục có thể được cho phép trong thuộc tính Vendor-Specific. Một Access-Request bây giờ yêu cầu chứa NAS-IP-Address hoặc NAS-Identifier (hoặc có thể chứa cả hai). Thêm ghi chú dưới "Operations" với nhiều thông tin hơn về proxy, truyền lại, và duy trì kết nối. Nếu nhiều thuộc tính với các loại tương tự có mặt đồng thời, thứ tự các thuộc tính cùng loại phải được duy trì bởi bất kỳ proxy nào. Làm rõ Proxy-State. Làm rõ các thuộc tính không phải phụ thuộc vào vị trí trong gói tin, miễn là thuộc tính của các loại tương tự đang được giữ theo thứ tự. Thêm vào phần lời khuyên của IANA. Cập nhật phần "Proxy" trong "Operations". Framed-MTU có thể được gửi trong Access-Request như là một gợi ý. Cập nhật lời khuyên bảo mật. Các chuỗi văn bản xác định như là một tập hợp con của chuỗi, để làm rõ việc sử dụng UTF-8. 4.3.2. RFC 2866: RFC 2866 - RADIUS Accounting: mô tả về quá trình kế toán cho máy chủ RADIUSvà là bản cập nhật cho RFC 2865. Cũng như RFC 2865, RFC 2866 cũng giới thiệu về các gói tin được dùng trong quá trình kế toán và các thuộc tính trong các gói tin đó và cũng mô tả về quá trình kế toán được diễn ra khi có yêu cầu thực hiện kế toán. Một số thay đổi so với RFC 2139: Thay thế US-ASCII bằng UTF-8. Thêm ghi chú trong Proxy. Framed-IP-Address nên chứa địa chỉ IP thực tế của người sử dụng. Nếu Acct-Session-ID đã được gửi trong một Access-Request, nó phải được sử dụng trong Accounting-Request cho phiên giao dịch đó. Các giá trị mới được thêm vào Acct-Status-Type. Thêm vào phần lời khuyên của IANA. Cập nhật tài liệu tham khảo. Các chuỗi văn bản xác định như là một tập hợp con của chuỗi, để làm rõ việc sử dụng UTF-8. 4.3.3. RFC 2867: RFC 2867 - RADIUS Accounting Modifications for Tunnel Protocol Support: mô tả về việc cải biến cơ chế RADIUS Accounting để hổ trợ cho giao thức đường hầm, cập nhật thêm cho RFC 2866. Nhiều ứng dụng giao thức đường hầm như là PPTP và L2TP bao hàm truy cập mạng quay số. Một số, như là việc cung cấp truy cập an toàn cho mạng nội bộ công ty thông qua mạng Internet, được đặc trưng bởi đường hầm chủ động: đường hầm được tạo ra theo yêu cầu của người sử dụng cho một mục đích cụ thể. Các ứng dụng khác gồm các đường hầm bắt buộc: đường hầm được tạo ra mà không có bất kỳ hành động từ người sử dụng và không có bất kỳ sự lựa chọn cho phép người dùng trong vấn đề này, như một dịch vụ của nhà cung cấp dịch vụ Internet (ISP). Thông thường, các ISP cung cấp một dịch vụ muốn thu thập dữ liệu về để thanh toán, quy hoạch mạng... Một cách để thu thập dữ liệu sử dụng trong các mạng quay số là dùng phương tiện RADIUS Accounting. Việc sử dụng RADIUS Accounting cho phép dữ liệu sử dụng quay số được thu thập tại một vị trí trung tâm, hơn là được lưu trữ tại mỗi NAS. Để thu thập dữ liệu sử dụng về đường hầm, thuộc tính RADIUS mới là cần thiết, tài liệu này xác định những thuộc tính này. Ngoài ra, một số giá trị mới cho các thuộc tính Acct-Status-Type được đề xuất. Kiến nghị cụ thể và ví dụ về việc áp dụng các thuộc tính này cho giao thức L2TP được mô tả trong RFC 2809. Các giá trị Acct-Status-Type mới: Tunnel-Start: giá trị là 9, dùng để đánh dấu việc tạo một đường hầm mới với nút khác. Tunnel-Stop: giá trị là 10, , dùng để đánh dấu việc hủy một đường hầm từ hoặc tới nút khác. Tunnel-Reject: giá trị là 11, , dùng để đánh dấu việc từ chối tạo một đường hầm với nút khác. Tunnel-Link-Start: giá trị là 12, dùng để đánh dấu sự tạo thành của một liên kết đường hầm. Tunnel-Link-Stop: giá trị là 13, dùng để đánh dấu sự phá hủy một lien kết đường hầm. Tunnel-Link-Reject: giá trị là 14, dùng để đánh dấu việc từ chối tạo nên một liên kết mới trong một đường hầm đang tồn tại. Và 2 thuộc tính mới: Acct-Tunnel-Connection: Thuộc tính này có thể được sử dụng để cung cấp một phương tiện để nhận diện ra một phiên đường hầm cho mục đích kiểm toán. Acct-Tunnel-Packets-Lost: Thuộc tính này chỉ ra số gói dữ liệu bị mất trên một liên kết được đưa. 4.3.4. RFC 2868: RFC 2868 - RADIUS Attributes for Tunnel Protocol Support: mô tả các thuộc tính RADIUS hỗ trợ cho giao thức đường ống, cập nhật them cho RFC 2865. Các thuộc tính RADIUS mới là cần thiết để chuyển các thông tin đường hầm từ máy chủ RADIUS tới điểm cuối của đường hầm. Các thuộc tính mới: Tunnel-Type: Thuộc tính này chỉ ra giao thức đường hầm sẽ được sử dụng hoặc các giao thức đường hầm đang được sử dụng. Tunnel-Medium-Type: Thuộc tính này chỉ ra phương tiện được sử dụng để tạo đường hầm theo các giao thức (như là L2TP), điều này có thể có tác dụng trên nhiều phương tiện vận chuyển. Tunnel-Client-Endpoint: Thuộc tính này chứa địa chỉ của người khởi xướng cuối của đường hầm. Tunnel-Server-Endpoint: Thuộc tính này chứa địa chỉ của máy chủ cuối của đường hầm. Tunnel-Password: Thuộc tính này chứa mật khẩu dùng để xác thực tới máy chủ truy cập từ xa. Tunnel-Private-Group-ID: Thuộc tính này chỉ ra ID nhóm cho một phiên hầm cụ thể. Tunnel-Assignment-ID: Thuộc tính này được sử dụng để chỉ ra người khởi xướng đường hầm một đường hầm cụ thể để phân công một phiên. Tunnel-Preference: Khi máy chủ RADIUS gởi trả nhiều hơn một bộ thuộc tính đường hầm về cho người khởi xướng đường hầm, thuộc tính này được gán vào trong mỗi bộ thuộc tính đường hầm để thiết lập độ ưu tiên cho mỗi đường hầm. Tunnel-Client-Auth-ID: Thuộc tính này ghi rõ tên người khởi xướng đường hầm sử dụng trong giai đoạn xác nhận khởi tạo đường hầm. Tunnel-Server-Auth-ID: Thuộc tính này ghi rõ tên người tận cùng đường hầm sử dụng trong giai đoạn xác nhận khởi tạo đường hầm. 4.3.5. RFC 2869: RFC 2869 – RADIUS Extensions: đưa ra gợi ý về một số thuộc tính bổ sung có thể được thêm vào RADIUS để thực hiện nhiều chức năng hữu ích khác nhau. Những thuộc tính không có trường mở rộng trải qua trước đóđược nêu ra và do đó bị coi là thử nghiệm. Extensible Authentication Protocol (EAP) là một phần mở rộng PPP cung cấp hỗ trợ cho các phương pháp xác thực bổ sung bên trong PPP. RFC này mô tả cách mà thuộc tính EAP-Message và Message-Authenticator được sử dụng để cung cấp EAP hỗ trợ