LOA  Alterna+ves:  A  Modest  Proposal  

Jim  Fenton  IIW  XX  

April  2015  

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  

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  

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  

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)  

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  

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  

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)  

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)  

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.  

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  

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.