Wallet Secure Data Distribution and Management Russ Allbery June - - PowerPoint PPT Presentation

wallet
SMART_READER_LITE
LIVE PREVIEW

Wallet Secure Data Distribution and Management Russ Allbery June - - PowerPoint PPT Presentation

Stanford University June 6, 2006 1 Wallet Secure Data Distribution and Management Russ Allbery June 6, 2006 Russ Allbery (rra@stanford.edu) Stanford University June 6, 2006 2 Contents The Starting Point Overview and Goal


slide-1
SLIDE 1

Stanford University June 6, 2006 1

Wallet

Secure Data Distribution and Management Russ Allbery June 6, 2006

Russ Allbery (rra@stanford.edu)

slide-2
SLIDE 2

Stanford University June 6, 2006 2

Contents

  • The Starting Point
  • Overview and Goal
  • remctl
  • remctl v2
  • Wallet Structure
  • Classes of Data
  • Authorization Methods
  • Data Storage Methods
  • Implementation Details

Russ Allbery (rra@stanford.edu)

slide-3
SLIDE 3

Stanford University June 6, 2006 3

The Starting Point

  • leland srvtab to distribute srvtabs and keytabs
  • keytab support underdocumented and strange
  • Supports cached keytabs, questionable implementation
  • Based on IBM sysctl, K4 authentication only
  • Only supports ACL files on disk

Russ Allbery (rra@stanford.edu)

slide-4
SLIDE 4

Stanford University June 6, 2006 4

Overview and Goal

  • Distribute keytabs with better ACL management than kadmin
  • Use the same method for certificates, passwords, etc.
  • Store or automatically generate
  • Allow upload of data into the wallet
  • Flexible authorization system
  • Self-contained distributable client

Russ Allbery (rra@stanford.edu)

slide-5
SLIDE 5

Stanford University June 6, 2006 5

remctl

  • Simple replacement for sysctl
  • Already in extensive use
  • Check an ACL and run a command, nothing more
  • A few problems:

– 32KB output size limit – Cannot stream output – No library interface – No persistant connections – Weird and underdocumented protocol – Unfortunate choice of ports

Russ Allbery (rra@stanford.edu)

slide-6
SLIDE 6

Stanford University June 6, 2006 6

remctl v2

  • Redesigned and documented protocol
  • Down-negotiates to the old protocol when needed
  • No output size limits, streaming output
  • Persistant connections
  • Client library with simple API
  • Extensive test suite

Russ Allbery (rra@stanford.edu)

slide-7
SLIDE 7

Stanford University June 6, 2006 7

Wallet Structure

  • Server runs under remctl for authentication
  • Stores predefined classes of secure data
  • Split into three layers:

– Data storage and generation layer – Authorization layer – Metadata layer that links the two

  • Support arbitrary authorization and data methods

Russ Allbery (rra@stanford.edu)

slide-8
SLIDE 8

Stanford University June 6, 2006 8

Classes of Data

  • keytabs regenerated on each request
  • keytabs pulled from the KDC database
  • SSL certificate private keys stored by user
  • Stanford-signed certificates generated on the fly
  • Arbitrary files (database passwords) stored by user
  • Almost certainly others to come...

Russ Allbery (rra@stanford.edu)

slide-9
SLIDE 9

Stanford University June 6, 2006 9

Authorization Methods

  • remctl provides authentication but only authorization for administrative

functions

  • Basic authorization: ACL files on disk or in MySQL
  • PTS group membership
  • LDAP group membership or attribute presence
  • NetDB roles (particularly for host keytabs)

Russ Allbery (rra@stanford.edu)

slide-10
SLIDE 10

Stanford University June 6, 2006 10

Data Storage Methods

  • File stored on disk
  • Data generated on the fly (kadmin for keytabs)
  • Data retrieved from elsewhere (pre-existing keytabs)

Russ Allbery (rra@stanford.edu)

slide-11
SLIDE 11

Stanford University June 6, 2006 11

Implementation Details

  • Client linked statically with Kerberos, remctl
  • Some Kerberos-specific knowledge in client: generating srvtabs, merging

keytabs

  • Server written in Perl
  • MySQL for metadata store
  • Runs on secure host, but not on KDC
  • Backend remctl call to retrieve existing keys from KDC

Russ Allbery (rra@stanford.edu)