Delegating Network Security with More Information with More - - PowerPoint PPT Presentation

▶
delegating network security with more information with
SMART_READER_LITE
LIVE PREVIEW

Delegating Network Security with More Information with More - - PowerPoint PPT Presentation

Sep 27, 2023 207 likes •548 views

Delegating Network Security with More Information with More Information {Stanford: [ Jad Naous , Ryan Stutsman, David Mazires, Nick McKeown,], MIT CSAIL: [Nickolai Zeldovich]} Context Roberto Alicia

slide-1
SLIDE 1

Delegating Network Security with More Information with More Information

{“Stanford”: [“Jad Naous”, “Ryan Stutsman”, “David Mazières”, “Nick McKeown”,], “MIT CSAIL”: [“Nickolai Zeldovich”]}

slide-2
SLIDE 2

Context

Roberto Alicia Carlito

slide-3
SLIDE 3

Context

slide-4
SLIDE 4

Context

Alicia

slide-5
SLIDE 5

Policies Alicia Wants

  • Skype only to Skype
  • email clients only to email server
  • Only Roberto can use openssh ver < 5.0
  • Allow R&D machines to talk anywhere in net,
  • Allow R&D machines to talk anywhere in net,

but not Sales

slide-6
SLIDE 6

Common Problem

Alicia does not have all information necessary

slide-7
SLIDE 7

Simple Solution

Ask!

slide-8
SLIDE 8

Who should Alicia ask?

  • Ask the whole path between sender and destination.
  • Each network along the path might have different

information (e.g. authenticated user) information (e.g. authenticated user)

  • Augment responses along the path
  • Communicate any relevant information
  • Let the Alicia decide what to use
slide-9
SLIDE 9

What information might Alicia want?

  • username and authenticated usernames
  • Application name, type, hash, version, …
  • OS information, patches, …
  • Network name, type, location, security, …
  • Network name, type, location, security, …
  • Application expected behavior, network rules,

destination rules, …

slide-10
SLIDE 10

Soliciting Information: ident++

Proposal for requesting information:

1. Ask for more information for every new flow. 2. Arbitrary user/admin-definable key-value pairs 3. Networks along the path augment responses

slide-11
SLIDE 11

Example: e-mail

  • Mail-server accessed by mail clients only
  • Thunderbird is the only mail client allowed
  • Only users authenticated by the network are

allowed access. allowed access.

slide-12
SLIDE 12

Example: e-mail

Data Flow From 192.168.0.1:2358 To 192.168.1.1:25 Payload

slide-13
SLIDE 13

Example: e-mail

Query From 192.168.0.1:2358 To 192.168.1.1:25 Query From 192.168.0.1:2358 To 192.168.1.1:25

slide-14
SLIDE 14

Example: e-mail

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: thunderbird
  • version: 2.0.3
  • user:roberto
  • type: email-client

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: cyrus
  • user: imap
  • type: email-server
slide-15
SLIDE 15

Example: e-mail

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: thunderbird
  • version: 2.0.3
  • user: roberto
  • type: email-client
  • authed-user: roberto

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: cyrus
  • user: imap
  • type: email-server
slide-16
SLIDE 16

Example: e-mail

Data Flow From 192.168.0.1:2358 To 192.168.1.1:25 Payload

slide-17
SLIDE 17

Example: evil e-mail

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: thunderbird
  • version: 2.0.3
  • user: roberto
  • type: email-client
  • authed-user: unknown

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: cyrus
  • user: imap
  • type: email-server
slide-18
SLIDE 18

Example: evil e-mail

slide-19
SLIDE 19

Example: e-mail

Backbone Firewall Rules: block all pass all with eq(@src[type], email-client) Client Configuration File: @app /usr/bin/thunderbird { name : thunderbird version : 2.0.3 type : email-client } email-client) with eq(@dst[type], email-server) with eq(@src[name], thunderbird) with not eq(@src[auth-user], unknown) }

slide-20
SLIDE 20

Extended PF language

  • PF+=2 Allows flexible policies based on

query results (key-value pairs)

  • Extensible via arbitrary functions.
slide-21
SLIDE 21

Trust and Delegation

  • We delegate every day
  • Makes lives easier
  • Delegate to trusted people
  • Trust levels vary so delegation levels vary
  • Trust levels vary so delegation levels vary
slide-22
SLIDE 22

Example: e-mail

David Roberto Alicia Carlito

slide-23
SLIDE 23

Example: e-mail

  • Mail-server accessed by mail clients only
  • Thunderbird is the only mail client allowed
  • Only users authenticated by the network are

allowed access. allowed access.

slide-24
SLIDE 24

How it is done today

Alicia, Carlito, and David get together, coordinate, and then change the rules. An easier way?

slide-25
SLIDE 25

Example: e-mail

Data Flow From 192.168.0.1:2358 To 192.168.1.1:25 Payload

slide-26
SLIDE 26

Example: e-mail

Query From 192.168.0.1:2358 To 192.168.1.1:25 Query From 192.168.0.1:2358 To 192.168.1.1:25

slide-27
SLIDE 27

Example: e-mail

Response

From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: thunderbird
  • version: 2.0.3
  • user:roberto
  • type: email-client

Response

From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: cyrus
  • user: imap
  • type: email-server
  • rule: only from email-client
slide-28
SLIDE 28

Example: e-mail

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: thunderbird
  • version: 2.0.3
  • user: roberto
  • type: email-client
  • authed-user: bob

Response From 192.168.0.1:2358 To 192.168.1.1:25

  • app-name: cyrus
  • user: imap
  • type: email-server
  • rule: only from email-client
  • rule: thunderbird only
slide-29
SLIDE 29

Example: e-mail

Data Flow From 192.168.0.1:2358 To 192.168.1.1:25 Payload

slide-30
SLIDE 30

Example: e-mail

Backbone Firewall Rules: block all pass all with allowed(@dst[rules]) with not eq(@src[auth-user], Server Configuration File: @app /usr/bin/cyrus { name : cyrus type : email-server rule : block all with not eq(@src[auth-user], unknown) block all with not eq(@src[type], email-client) }

slide-31
SLIDE 31

Third-Party Delegation

  • Another Example

– Allow users to run any application as long as it conforms to rules signed by trusted third-party – Rules can be downloaded by user and stored – Rules can be downloaded by user and stored locally. – Security devices check signatures before accepting rules.

slide-32
SLIDE 32

Summary

  • If you don’t know, ask!
  • Trust and delegation intertwined (be careful

who you delegate to or what information you trust) trust)

  • ident++ delegation enabler, says nothing

about trust

slide-33
SLIDE 33

Questions? Questions?

This work was funded partially by an NSF grant.