OGSA design team session on security (OGSA session 6)
-----------------------------------------------------

  June 9, 2:30-04:00pm
  Minutes: Olle Mulmo

Lynn Wheeler: Naked keys
------------------------

- Certificates: originally crafted for offline processing

- X.509: "ISO engineers reinventing 1960s database technology"

- Server certificates: "is person requesting a server cert the same as
  the owner of the domain name?" -> complex processing
  - Fix: domain name owner registers the naked key with the domain
    name in the DNS
  - Problem: relying on DNS eliminates the need for server certs in
    the first place

- Identity certificates
  - Putting meaningful data in certificates may violate privacy or
    institutional sensitive information: often not more than opaque id
    and public key
  - Financial transactions: a signed transaction data of 60-80 bytes
    blows the message size up 2 orders of magnitude, institution only
    uses public key from cert (and have other means to obtain that
    key anyway)

- "Certificates can emulate offline systems"
  - But all systems where value is at stake are all online nowadays
  - Certs are expensive and only protects the no-value market segments
    -> negative feedback loop

- Trusted Third Parties (TTP)
  - contract between user and CA
  - contract between user and relying party (business)
  - no contract between relying party and CA :-/

- The non-repudiation scam
  - anytime the consumer's keypair is used to produce a signature, he's
    at a disadvantage in case of disputes

- Conclusions:
  - The benefit vs. cost of using certificates is questionable
  - Any processing that is of value is online anyhow
  - Real PKI issue: How do I ensure the signature is created by a
    trusted device in a trusted environment


Steve Chan: One-time passwords
------------------------------

- Background: several large successful hacking attempts in the US
  - Over 20 sites, 3000 computers, an unknown # of accounts
  - Specifically targeting labs and academics as they are in
    collaborative environments
  - Methodology: obtain password via password sniffer to login at site
    as normal user, use script-kiddie rootkit to acquire root access
    on unpatched computer, install additional password sniffing software
    to obtain new passwords, repeat at next site

- Facts
  - Users use same password at several sites
  - Not possible to keep all systems updated and well patched at all
    times
  - Passwords are only as secure as the least secure site that share
    some of your users

- So, remove the passwords
  - Go to OTP
  - Does not address stolen long or short term tokens (proxy certs,
    krb tickets), but elevates the protection level in the continous
    arms race

- Problems
  - Each and every incoming connection requiring OTP authentication
    -> not user friendly
  - Each site solving the problem -> many tokens to keep track
    -> not user friendly
  - Not all OTP solutions are adequate for our usage patterns

- Short term requirements
  - Roadmap to facilitate cross site authentication (reduce # of
    tokens), but keep authZ decisions local (a must)
  - OTP solutions must be hardware based (software cannot be trusted)
    [Olle: what about the example with CryptoCard software running in
     an always-disconnected Palm?]
  - Must support "all" platforms
  - Vendor neutral interfaces (e.g. RADIUS)

- Long term requirements
  - Continue to raise the bar - security is an arms race
  - Hackers aware of ssh keys, same techniques can be used against
    grid credentials and kerberos tickets
  - Any token that has a validity needs a revocation mechanism

- Recommendations
  - Use Kerberos/GSI for automated processes only, OTP when the end-user
    is an "active participant"
  - Integrate OTP with Kerberos and MyProxy/GridLogon
  - Deploy OCSP
  - Eliminate the use of ssh keys

- Findings
  - No OTP off the shelf solution exists that scales to the required #
    of sites and users


Dane Skow: Fermilab on OTP experiences
--------------------------------------

[Sorry, I lost concentration here, the notes are a bit scarce...]

- Technology
  - CryptoCard: one-time cost, public algorithm (in-house client
    implementations on e.g. PDAs), reliable

- Issues/Concerns
  - Users hate having to carry hardware tokens
  - But, prefer the tokens vs. having to install non-conventional
    client software
  - Costs vs. risk tradeoff


Mike Helm: Grid Integrated Radius Authentication Fabric (GIRAF)
---------------------------------------------------------------

- Wants to move towards issuing certificates on demand
  - Driven by (OTP driven) Radius based infrastructure
  - "Proxy" Radius server at ESNet for cross-site federation[*] of
    organizational Radius servers

  [* Disclaimer: This is the understanding of the confused note taker]

- Outsourcing PKI credential management to sites (sub CA)
  - Radius server returns the approved subject name to issue a cert to

Frank: Conclusions
------------------

- We are moving from CA driven PMAs to trusting each other's OTP services
  - Nothing fundamentally change though, same administrative burden

- Must standardize on "authentication strength" assertions
  - Conveying trust levels/key quality to relying parties