Re: [radext] Meeting in Seoul - call for talking slot requests

["Brian Weis (bew)" <[e-mail]>]

Hi Alan,

Many thanks for your review.

> On Oct 26, 2016, at 4:47 PM, Alan DeKok <[e-mail]> wrote:
> 
> 
>> On Oct 25, 2016, at 6:41 PM, Brian Weis (bew) <[e-mail]> wrote:
>> 
>> Hi Stefan,
>> 
>> I have recently posted a new draft <https://tools.ietf.org/html/draft-weis-radext-mud-00>, and if possible I’d appreciate 10 minutes or so of the meeting to introduce it. The draft allows RADIUS to help complete a solution using the Manufacturer Usage Description (MUD) Specification (<https://tools.ietf.org/html/draft-ietf-opsawg-mud-01>).
> 
>  My $0.02, mostly nits.
> 
> - define the new attribute as of type "string", and reference the data types draft.  This lets you remove the ASCII art

I wasn’t aware of this document, will look into doing this for the next version. 

> - perhaps have a discussion of the security implications of MAB in Section 5.  I don't recall seeing a discussion of this before in a RADIUS document
> 
> - i.e.MAB requests rely on MAC address from the end user machine... which can be trivially forged.  What are the implications of send the wrong MUD info to a machine which is lying to you?

That’s an interesting point. I touched on a a similar issue in the current security considerations, acknowledging that the actual DHCP or LLDP message might have been received on the NAS unprotected. But I take your point that sine MAB is mentioned that implications of a forged  MAC address is probably in scope. One mitigation would be to require 802.1X and only accept MUD URIs in packets from which the MAC address(es) that have strongly authenticated. To completely mitigate the attack, add MACsec (IEEE 802.1AE) to wired ports. 

In any case, MUD is most valuable in helping devices emitting a MUD URI using a MAC address that it actually owns, because the NAS can proactively install policy to protect that MAC address against attacks in the future. I’ll think about what the security considerations section should say about the ramifications of an evil device specifying a false MAC address given that, as you say, perhaps no other RADIUS document has done that.

>  But the concept does seem rather simple.  I think a short & clear specification such as this is good.

Excellent, thanks.
Brian 

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]