std-agent-id.raw 2.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
  1. PAM working group ## A.G. Morgan
  2. ## $Id$ ##
  3. ## Pluggable Authentication Modules ##
  4. ## REGISTERED AGENTS AND THEIR AGENT-ID'S ##
  5. #$ Purpose of this document
  6. #$$#{definition} Definition of an agent-id
  7. The most complete version of a "PAM agent-id" is contained in this
  8. reference [#$R#{PAM_RFC2}]. A copy of a recent definition is
  9. reproduced here for convenience. The reader is recommended to consult
  10. reference [#{PAM_RFC2}] for definitions of other terms that are
  11. used in this document.
  12. ## -------------- ##
  13. The agent_id is a sequence of characters satisfying the following
  14. regexp:
  15. /^[a-z0-9\_]+(@[a-z0-9\_.]+)?$/
  16. and has a specific form for each independent agent.
  17. o Agent_ids that do not contain an at-sign (@) are to be considered as
  18. representing some authentication mode that is a "public
  19. standard". Registered names MUST NOT contain an at-sign (@).
  20. o Anyone can define additional agents by using names in the format
  21. name@domainname, e.g. "ouragent@example.com". The part following
  22. the at-sign MUST be a valid fully qualified internet domain name
  23. [RFC-1034] controlled by the person or organization defining the
  24. name. (Said another way, if you control the email address that
  25. your agent has as an identifier, they you are entitled to use
  26. this identifier.) It is up to each domain how it manages its local
  27. namespace.
  28. ## -------------- ##
  29. #$ Registered agent-id's
  30. The structure of this section is a single subsection for each
  31. registered agent-id. This section includes a full definition of binary
  32. prompts accepted by the agent and example responses of said
  33. agent. Using the defining section alone, it should be possible for a
  34. third party to create a conforming agent and modules that can
  35. interoperate with other implementations of these objects.
  36. *$ "userpass" - the user+password agent
  37. Many legacy authentication systems are hardcoded to support one and
  38. only one authentication method. Namely,
  39. username: joe
  40. password: <secret>
  41. Indeed, this authentication method is often embedded into parts of the
  42. transport protocol. The "user+password" agent with PAM agent-id:
  43. "userpass"
  44. Is intended to support this legacy authentication scheme. The protocol
  45. for binary prompt exchange with this 'standard agent' is as follows:
  46. Case 1: module does not know the username, but expects the agent to
  47. obtain this information and also the user's password:
  48. module: {LENGTH;PAM_BP_SELECT;userpass;'/'}
  49. agent: {}
  50. Case 2: module has suggested username, but would like agent to confirm
  51. it and gather password:
  52. module: {}
  53. agent: {}
  54. Case 3: module knows username and will not permit the agent to change it:
  55. module: {}
  56. agent: {}
  57. #$ References
  58. [#{PAM_RFC2}] Internet draft, "Pluggable Authentication Modules
  59. (PAM)", available here:
  60. # http://linux.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt #
  61. #$ Author's Address
  62. Andrew G. Morgan
  63. Email: morgan@kernel.org