Subject: [radext] [Technical Errata Reported] RFC5080 (4476)

From: RFC Errata System <[email-masked]>
Date: Thu, 17 Sep 2015 03:00:12 -0700 (PDT)

The following errata report has been submitted for RFC5080,
"Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5080&eid=4476

--------------------------------------
Type: Technical
Reported by: Michael Wang <[email-masked]>

Section: Section 2

Original Text
-------------
Section 2.1.1. page 6:
Any Access-Request packet that performs authorization checks,
including Call Check, SHOULD contain a Message-Authenticator
attribute.

section 2.2.2 page 11:
However, Access-Request packets not containing a Message-
Authenticator attribute always affect the cache, even though they may
be trivially forged.  To avoid this issue, server implementations may
be configured to require the presence of a Message-Authenticator
attribute in Access-Request packets.  Requests not containing a
Message-Authenticator attribute MAY then be silently discarded.

Client implementations SHOULD include a Message-Authenticator
attribute in every Access-Request to further help mitigate this
issue.

Corrected Text
--------------
Section 2.1.1. page 6:
Any Access-Request packet that performs authorization checks,
including Call Check, Must contain a Message-Authenticator
attribute.

section 2.2.2 page 11:
However, Access-Request packets not containing a Message-
Authenticator attribute always affect the cache, in some case 
such forgery is not trivial.  To avoid this issue, server 
implementations MUST be configured to require the presence of 
a Message-Authenticator attribute in Access-Request packets.  
Requests not containing a Message-Authenticator attribute 
MAY then be silently discarded.

Client implementations MUST include a Message-Authenticator
attribute in every Access-Request to further help mitigate this
issue.

Notes
-----
Message-Authenticator attribute defined in [RFC3579] is mandatory attribute for IEEE802.1x EAP User and optional attribute for other type of users. In RFC5080, the message-authenticator is used as an optional attribute. However in practice, Radius Implementation without Message-Authenticator attribute for Integrity check protection has become serious issue.
The attacker can take advantage of Access-Request packets not containing a Message-Authenticator attribute to perform authentication successfully. 
Alternatively,the attacker can capture the packet and delete message-authenticatorattribute.
If the server do not check the message-authenticator attribute, the attacker can pass the authentication as well.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5080 (draft-ietf-radext-fixes-08)
--------------------------------------
Title               : Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
Publication Date    : December 2007
Author(s)           : D. Nelson, A. DeKok
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Sep 2015 07:50:58 -0400

An RFC errata is not the place to make normative changes to the RADIUS protocol.  Those changes require IETF consensus, and the publication of a new RFC.

  This errata should be rejected.

On Sep 17, 2015, at 6:00 AM, RFC Errata System <[email-masked]> wrote:

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Sep 2015 08:41:52 -0400

Thanks, Alan.

Michael, could you post this to the radext list and begin a
discussion?  I'll reject the errata.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 17 Sep 2015 12:43:04 +0000 (UTC)

Alan writes...

> An RFC errata is not the place to make normative changes to the RADIUS
> protocol.  Those changes require IETF consensus, and the publication of a
> new RFC.
> 

Agreed.  While one can appreciate the security implications that motivate the suggested change, the reason for the SHOULD language is that was the acheivable consensus of the WG, and the IETF at large, at the time.  Backwards compatibility was one of the considerations.

Regards,

Dave Nelson

---

From: wangzitao <[email-masked]>
Date: Fri, 18 Sep 2015 01:28:24 +0000

Alan, Thanks for pointing it out.
Kathleen, I'd like to post this to radext.

Best Regards!
-Michael 

-----邮件原件-----
发件人: Kathleen Moriarty [mailto:[email-masked]] 
发送时间: 2015年9月17日 20:42
收件人: Alan DeKok
抄送: RFC Errata System; wangzitao; [email-masked]; [email-masked]; Winter Stefan; [email-masked]; joel jaeggli; Benoit Claise
主题: Re: [radext] [Technical Errata Reported] RFC5080 (4476)

Thanks, Alan.

Michael, could you post this to the radext list and begin a discussion?  I'll reject the errata.

Best regards,
Kathleen

On Thu, Sep 17, 2015 at 7:50 AM, Alan DeKok <[email-masked]> wrote:
>> The following errata report has been submitted for RFC5080, "Common 
>> Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes".
>>
>> including Call Check, Must contain a Message-Authenticator attribute.
>>
>> section 2.2.2 page 11:
>> Authenticator attribute always affect the cache, in some case such 
>> forgery is not trivial.  To avoid this issue, server implementations 
>> MUST be configured to require the presence of a Message-Authenticator 
>> attribute in Access-Request packets.
>> Requests not containing a Message-Authenticator attribute MAY then be 
>> silently discarded.
>>
>> Client implementations MUST include a Message-Authenticator attribute 
>> in every Access-Request to further help mitigate this issue.
>>
>>
>> Notes
>> -----
>> use "Reply All" to discuss whether it should be verified or rejected. 
>> When a decision is reached, the verifying party (IESG) can log in to 
>> change the status and edit the report, if necessary.
>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Sep 2015 22:13:07 -0400

Michael,

Radext was copied, so you can continue the discussion from here or start a new one with go forward options.

Thanks,
Kathleen 

Sent from my iPhone

> On Sep 17, 2015, at 9:28 PM, wangzitao <[email-masked]> wrote:
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 18 Sep 2015 09:57:49 -0400

> Kathleen, I'd like to post this to radext.

  I've trimmed the CC line so that it's only you and radext.  I suggest subscribing to radext if you need to continue the discussion.

  But as a simple response... mandating Message-Authenticator can't be done for backwards compatibility reasons.  There are billions of dollars of equipment which doesn't send Message-Authenticator, and likely won't be upgraded.

  *Not* using Message-Authenticator is fine for management networks, which is a typical use-case.

  For non-management networks, RADIUS over TLS or RADIUS over IPSec is recommended.  People do this today.

  So the suggested fix is largely theoretical, and doesn't really help any real-world deployments.

  Alan DeKok.

---

From: wangzitao <[email-masked]>
Date: Mon, 21 Sep 2015 06:51:08 +0000

Alan,
Thanks for your suggestions. It is really helpful. I will feedback it to my product development team.

-Michael
-----邮件原件-----
发件人: Alan DeKok [mailto:[email-masked]] 
发送时间: 2015年9月18日 21:58
收件人: wangzitao
抄送: [email-masked]
主题: Re: [radext] [Technical Errata Reported] RFC5080 (4476)

  Alan DeKok.