home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0035.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  4.0 KB  |  81 lines
  1. Submitted-by: epstein@trwacs.uucp (Jeremy Epstein)
  2.  
  3. In article <1991Jul2.224427.784@uunet.uu.net>, peter@Sugar.NeoSoft.com (Peter da Silva) writes:
  4. > Submitted-by: peter@Sugar.NeoSoft.com (Peter da Silva)
  5. > 
  6. > In article <1991Jun28.192719.17816@uunet.uu.net> jmcarli@ns.PacBell.COM (Jerry M. Carlin) writes:
  7. > > The BIG problem I see with 1003.6 is lack of I&A; identification and
  8. > > authentication. What has been lacking for a LONG time is decent login.c,
  9. > > passwd.c etc functionality including ability to develop local rules
  10. > > passwords. We've seen a number of reimplementations of these functions
  11. > > on the net precisely because the current ones are so bad & inconsistant.
  12. > 
  13. > Yes. We need to be able to do the following things:
  14. > 
  15. >     Allow or deny access on a per-port or per account basis (for example,
  16. >         disable ttyM025 and user3... we have this, but it's not
  17. >         very clean and quite inconsistent for the per-port stuff).
  18. >     Allow or deny access on a scheduled basis (only allow backup to log
  19. >         in from 2AM through 10AM, all others are kept off from 2AM
  20. >         through 6AM).
  21. >     Allow or deny access to port/account combinations (for example,
  22. >         ttyM020 only allows user1 and user2 on, all others get
  23. >         "permission denied", root and backup can only log in to
  24. >         console or ttyf01, and "telnet" can't log in on any network
  25. >         ports).
  26. >     And other combinations (allow user1 on ttyM020 from 5PM through 8AM
  27. >         and all day weekends).
  28.  
  29. I'm a member of the 1003.6 working group, but speaking for myself only.
  30.  
  31. All of these ideas are good ones, but they miss the point.  1003.6 is
  32. extending 1003.1 and 1003.2 to add security relevant features.  1003.1
  33. has no mention of either login or passwd; 1003.2 mentions passwd (although
  34. I'm not sure that it will make it into the standard), but with many weasel-
  35. words.  [For example, the passwd command *may* (according to 1003.2) simply
  36. give you instructions on how to change your password, such as contacting your
  37. security administrator, getting a brain transplant, or whatever.]
  38.  
  39. In the near future we'll see many systems which don't even use passwords
  40. for authentication (I assume there are already some out there, but I'm
  41. not sure).  You'll see smart cards, voiceprints, retina scans, fingerprint
  42. analysis, etc.  It's not a good idea to specify a password-based scheme as
  43. a standard when technology is already growing beyond that.
  44.  
  45. Even if you do accept a password-based scheme, what rules do you want to
  46. enforce?  Should the standard use the DoD password guidelines (no words,
  47. randomly chosen pronouncable syllables)?  Password ageing?  There are
  48. undoubtedly other international standards which may conflict with the DoD
  49. guidelines.
  50.  
  51. Having said all that, once there is some agreement on a meta-mechanism for
  52. authenticating users I think it's entirely reasonable to define a mechanism
  53. for rules.  What Peter da Silva suggests are some good ones, but there's
  54. much more...for example, you might be allowed or denied access based on the
  55. results of a breathalyzer (sp?) attached to the side of the system (i.e.,
  56. if you're drunk, no playing footside with top secret information).  There's
  57. more than simple yes/no decisions that Peter suggests: depending on the time
  58. of day, day of the week, login terminal, etc., you may have different
  59. privileges available to you, be audited differently, have different clearances
  60. available (you may only be able to access "unclassified" data from ttya,
  61. but "secret" from ttyb), etc.
  62.  
  63. Incidentally, 1003.1 has no notion of what a "user" is, which means breaking
  64. major new ground for any such extensions.
  65.  
  66. 1003.6 will be going to ballot soon (I hope!) with the current proposed
  67. standard.  I assume that we'll then put in another request to pursue additional
  68. areas of security standardization, possibly including some of the topics
  69. discussed by Peter and Jerry Carlin.
  70.  
  71. Again, I speak only for myself, and not for 1003.6 or my employer.
  72. -- 
  73. Jeremy Epstein            UUCP: uunet!trwacs!epstein
  74. Trusted X Research Group    Internet: epstein@trwacs.fp.trw.com
  75. TRW Systems Division        Voice: +1 703/876-8776
  76. Fairfax Virginia
  77.  
  78.  
  79. Volume-Number: Volume 24, Number 35
  80.  
  81.