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

From: Stefan Winter <[email-masked]>
Date: Mon, 24 Oct 2016 12:56:39 +0200

Hello,

we have been given a 90 minute slot for the next IETF meeting in Seoul.
We'll meet on Wednesday morning (0930 local time).

https://datatracker.ietf.org/meeting/97/agenda.html

Please send requests for a talking slot during the meeting to the
chairs, ideally before Monday 31 Oct (preliminary agendas due date).

With 30 more minutes than usual, I hope we can be a bit more generous in
the slot allocation and don't have to rush things through. I hope we can
repeat the refreshing vivid experience we had in Berlin at IETF 96!

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Oct 2016 07:54:09 -0400

> chairs, ideally before Monday 31 Oct (preliminary agendas due date).

  I'd like 10min to talk about a proxy considerations document.  This was discussed informally in Berlin.

  Perhaps also 5min to discuss DHCP packet signing via 802.1X.  I should have a rough draft later today.  The draft will be submitted to the security area for AD sponsorship.  But it would be good to get comments from RADEXT too, because there is some overlap.

  Alan DeKok.

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 25 Oct 2016 22:41:40 +0000

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>).

Comments are welcome on the list too, of course.

Thanks,
Brian

> On Oct 24, 2016, at 3:56 AM, Stefan Winter <[email-masked]> wrote:
> 
> Hello,
> 
> 
> <0x8A39DC66.asc>_______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Oct 2016 19:47:26 -0400

> On Oct 25, 2016, at 6:41 PM, Brian Weis (bew) <[email-masked]> wrote:
> 
> Hi Stefan,
> 

  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

- 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?

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

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Fri, 28 Oct 2016 21:33:15 +0000

Hi Alan,

Many thanks for your review.

> On Oct 26, 2016, at 4:47 PM, Alan DeKok <[email-masked]> wrote:
> 
> 

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

> - 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