O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

LOA Alternatives - A Modest Proposal

1.838 visualizações

Publicada em

Presentation for Vectors of Trust session at Internet Identity Workshop XX

Publicada em: Tecnologia
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

LOA Alternatives - A Modest Proposal

  1. 1. LOA  Alterna+ves:   A  Modest  Proposal   Jim  Fenton   IIW  XX   April  2015  
  2. 2. Background   •  LOA  is  defined  in  OMB  Memo  M-­‐04-­‐04,  “E-­‐ Authen+ca+on  Guidance  for  Federal   Agencies”   •  Technical  means  to  sa+sfy  are  defined  in  NIST   SP  800-­‐63-­‐*   •  Federal  authen+ca+on  requirements  are   changing  due  to  Execu+ve  Order  13681  
  3. 3. EO  13681   “…all  agencies  making  personal  data  accessible  to  ci+zens   through  digital  applica+ons  require  the  use  of  mul+ple  factors  of   authen+ca+on  and  an  effec+ve  iden+ty  proofing  process,  as   appropriate.”   -­‐-­‐  Execu+ve  Order  13681   October  17,  2014   Ø Current  LOA  1  and  2  are  going  to  be  a  lot  less  useful  
  4. 4. Three  Alterna+ves  for  OMB   •  (1)  Keep  current  LOA  structure,  change  impact   – Increase  impact  of  personal  data  disclosure   – Drives  more  things  to  LOA  3   •  (2)  Keep  LOA  structure,  change  800-­‐63   – Likely  to  confuse  agencies  and  industry   •  (2)  Change  the  LOA  structure  somehow   – Let’s  discuss  this  more  
  5. 5. Some  principles   •  Avoid  current  LOA  problems   – LOA  2  both  proofed  and  pseudonymous   – No  strong  pseudonymous  authen+ca+on   – Lower  LOA  geeng  less  useful   •  Keep  it  simple   – Emphasize  meaningful  dis+nc+ons  between  levels   – Minimize  dimensionality  (of  vector)  
  6. 6. Meaningful  dis+nc+ons?   •  As  mul+-­‐factor  authen+ca+on  becomes  more  widely  used,  dis+nc+ons  in   single-­‐factor  become  less  important   Authen'ca'on   LOA   Proofing   Single  factor   1   None   Single  factor   2  pseudonymous   None   Single  factor   2   Remote   Mul+-­‐factor   3   Remote   Mul+-­‐factor  w/   hardware  token   4   In-­‐person  only   {  Similar  (though   not  iden+cal)   requirements   }   Similar  (though   not  iden+cal)   requirements  
  7. 7. A  New  Model   •  Separate  Level  of  Assurance  into  two  parts:   –  Level  of  Strength  (of  authen+ca+on)   –  Level  of  Confidence  (of  akributes)   •  Emphasis  on  meaningful  dis+nc+ons   –  Significant  differences  in  usability,  availability   –  Require  good  prac+ces  internally  (e.g.,  use  of  crypto  rather  than   shared  secrets)   •  Emphasis  on  expressing  the  relying  party’s  requirements  to   the  user  and  authen+ca+on  and  akribute  providers  
  8. 8. Level  of  Strength  (LoS)   •  Measures  the  strength  of  the  authen+ca+on   process   •  Candidate  levels:   •  Detailed  requirements  per  level  to  be  defined  in   SP  800-­‐63-­‐2  successor   Level   Descrip'on   1   Single-­‐factor  authen+ca+on  (cf.  LOA  2)   2   Two-­‐factor  authen+ca+on  (cf.  LOA  3)   3   Two-­‐factor  authen+ca+on  with  hardware  token  (cf.  LOA  4)  
  9. 9. Level  of  Confidence  (LoC)   •  Measure  of  the  degree  to  which  the  Relying  Party  can   depend  on  akributes,  par+cularly  iden+fying  akributes   •  Incorporates  the  iden+ty  proofing  process  and  the   binding  to  the  creden+al   •  Again,  detailed  requirements  TBD.   Level   Descrip'on   1   Self-­‐asserted  akribute  (cf.  LOA  1)   2   Remotely  iden+ty  proofed  (cf.  LOA  3)   3   In-­‐person  iden+ty  proofed  (cf.  LOA  4)  
  10. 10. Mapping  LOA  to  LOS/LOC   LOA   Level  of  Strength   Level  of  Confidence   1   1  (see  note)   1   2   1   1  (pseudonynous)  or  2   3   2   2   4   3   3   Note:  Some  LOA  1  authen+ca+on  methodologies  may  not  be  acceptable  at  LOS  1.  
  11. 11. Mapping  LOS/LOC  to  LOA   LOC  1   LOC  2   LOC  3   LOS  1   1,  2P   2   Note  2   LOS  2   Note  1   3   Note  2   LOS  3   Note  1   4   Notes:   1.    Strong  pseudonymous  or  anonymous  authen+ca+on   2.    Lower  LOS  may  limit  effec+ve  LOC  
  12. 12. Not  included   •  Characteris+cs  of  authen+ca+on  and  akribute  provider   –  Accredita+on  of  the  authen+ca+on  or  akribute  provider   •  May  only  permit  certain  levels  of  asser+on   –  Trust  by  relying  party  of  accredi+ng  agency   •  Addi+onal  detail  (such  as  loca+on)  for  risk-­‐based   authen+ca+on  decisions   –  Are  these  really  akributes?   •  Risk  characteris+cs  at  each  level   –  To  be  defined  based  on  detailed  technical  requirements  at   each  level   •  Asser+on  metadata   –  Expira+on,  usage  restric+ons,  etc.  

×