Subject: re: Expiring Passwords

From: Chris Newman <[email-masked]>
Date: Mon, 29 Dec 1997 16:15:59 -0800 (PST)

[Moving discussion from IMAP list to SASL list]

On Wed, 24 Dec 1997, John Haxby wrote:
> However, you mention service-specific passwords.  This is what I have
> difficulty with.  In particular, with IMAP servers, I'm having trouble with
> the concept that an IMAP server must use some central authentication to
> allow password changing.  Other services, whether Internet or not, allow
> password changing on a service-by-service basis.

Most Internet protocols do not include a password changing service.
However, I do see an interesting architectural decision underneath this
that would seem to merit discussion:

Should "password change" be part of the authentication service provided by
every protocol (e.g., a SASL-like beast which is slotted into every
protocol) or should it be an independent service which can change the
user's one password (99% case) or service-specific password (1% case)?

There are good reasons for both architectures.

A SASL-enabled protocol will already have the machinary to access an
authentication database at least to the extent of verifying the password.
Including the password change service as part of that service will
simplify the issue of locating the correct backend authentication
database.

On the flip side, password changing is a very sensitive operation which
needs a higher level of mandatory security than most protocols.
Splitting it into a separate protocol will allow that protocol to be much
more carefully analyzed for correctness and thus reduce the security risk
to sites where it is deployed.  But with the 1% (or less, but not
ignorable) case of service-specific passwords, this becomes a rather ugly
architecture.

I'm inclined towards a separate password change protocol as I tend to
prefer modular protocol design and prefer to cater to the 99% case.

The set of cookie-cutter features that app protocols need is growing:
  * protocol structure and data types
  * basic commands: logout, noop
  * error messages: basic errors, detailed errors
  * I18n: UTF-8, language control for error messages, etc.
  * SASL
  * Referrals
 [* STARTTLS command]
 [* command/response interleaving]
I'd prefer to avoid growing this list more than necessary as it
can have a multiplicative effect on Internet complexity.

But I will admit that this decision is not a slam-dunk decision.  What do
other people think?

		- Chris

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Dec 1997 16:44:07 -0800

I would tend to want to define this in SASL rather than outside for the
simple reason that it would be easier for someone who had already
implemented SASL to implement this extension. On the political front, it
would help nudge (shove?) client and server implementors who haven't to
implement SASL for this one feature, if for no other reason.

And, if we like Chris' list of "what an application protocol should have",
SASL is already there, so we don't have to add "password changing" to that
list, which should be available to any password-based protocol.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Dec 1997 20:06:08 -0500 (Eastern Standard Time)

> simple reason that it would be easier for someone who had already

Absolutely - in SASL.  To my mind, changing the authentication credentials 
is *part* of the authentication process; it's not peripheral to it.  A 
mechanism for making that change should be part of the authentication layer.

As I study my company's own Lotus Notes product, which has a very strong 
authentication system, I see the weakness in its not providing a way for 
the user to change her own authentication certificates.

Barry Leiba, Multimedia Messaging  ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: "Robert J. DuWors" <[email-masked]>
Date: Mon, 29 Dec 1997 21:04:51 -0500

I see two distinct issues:

  1) Should one-password-fit-all across all authentication mechanisms 
     and across all services? [which is actually two closely related
     questions].  It is argued this is the 99% case [following the
     single-sign-on philosophy as applied to passwords].

  2) Should password changing be in-band or out-of-band in regards
     to the authentication protocol [and perhaps altogether on the
     Internet]?  Ironically, many "application protocols" such as
     chat services [even financial services] use [insecure] e-mail
     as an out-of band protocol for this purpose.  :-)
     
1) seems 99% plausible as operationally desirable [although more stringent
policy must be possible if not particularly easy].  Also of concern is the
relative risk a stored verifier belonging to one mechanism/service
revealing another mechanisms's verifier which uses the same root
pass[word/phrase], e.g. APOP versus CRAM-MD5 versus SCRAM-MD5 -if this is
not an issue then storing plain text passwords is ok [maybe that is the
answer; after all, if they steal your authentication database, of course
your authentication scheme is blown].
  
2) raises serious design tradeoffs between architectural cleanliness and
[enterprise/user community specific] security policy.  Perhaps the
compromise answer has to be that a pass[word/phrase] changing protocol MAY
be bundled with SASL authentication much like the EXTERNAL/TLS hooks but
SHOULD not be required.

--Rob DuWors

>user's one password (99% case) or service-specific password (1% case)?

--------------------------------------------------------------
Robert J. DuWors  <mailto:[email-masked]> tel:+1.440.255.2869         
Connected Systems Group  7638 Aster Drive, Mentor, Ohio  44060

---

From: Chris Newman <[email-masked]>
Date: Tue, 30 Dec 1997 00:37:43 -0800 (PST)

The choices on the table as I see them:

* A password-change SASL mechanism

Pros: fits easily into existing SASL-profiled protocols
      handles 1% service-specific password case elegantly
      Doesn't require new "service"

Neutral:  Would make SASL implementation model significantly more complex
             but might also make it more attractive to vendors

Cons: Every service would have to support proxied password changing in a
        large installation
      Wouldn't support bulk administrative changing of user passwords
      Adds complexity to core service

* A credential/password-change framework that could be added to protocols
  independent of SASL

Pros: handles 1% service-specific password case elegantly
      Doesn't require new "service"

Cons: Every service would have to support proxied password changing in a
        large installation
      Wouldn't support bulk administrative changing of user passwords
      Adds complexity to many protocols

* A separate password change protocol

Pros: Doesn't require proxying password change in large installations
      Doesn't require adding security sensitive service to complex
        protocols (making the service less secure and protocol more
        complex)
      Allows functional (or even vendor) separation of services
      Can support bulk administrative changing of user credentials

Cons: handles 1% service-specific password case poorly unless Mark's
         referral proposal is adopted
      hard for some vendors to create/market a new "service"

---

From: Rob Earhart <[email-masked]>
Date: Tue, 30 Dec 1997 15:49:57 -0500 (EST)

> can have a multiplicative effect on Internet complexity.

  That's actually why I proposed draft-earhart-ap-spec-00.txt last
summer; it had the potential to wrap up a lot of the infrastructure
that application protocols need.  Think it'd be worth updating and
resubmitting?

  (As a bonus, password-change could easily be treated as an extension
to AP, so it could either coexist with another protocol on the same
connection or be an independant service, as desired.)

  )Rob

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 Dec 1997 13:40:50 -0800

I've been thinking about this, and now feel that a separate password
change protocol is needed.  Password changing, unlike authentication,
is really not an intrinsic part of most application protocols; it is a
separate service, with its own needs.  Of course, applications are free
to offer password changing as part of their UI.  What we need, as Chris
noted, is a replacement for poppassd.

This isn't to say that a SASL mechanism or set of mechanisms might not
be a good choice.

--
Randall Gellens       ||    Opinions are personal; facts are suspect;
[email-masked]    ||    I speak for myself alone

Excellent day to have a rotten day.

---

From: Rob Earhart <[email-masked]>
Date: Thu, 1 Jan 1998 00:52:42 -0500 (EST)

I think that a seperate password changing protocol is the way to go. 
The only serious con is that it doesn't elegantly handle service-specific
passwords for existing protocols; I'm tempted to just say that existing
applications which want this will need to be do something special anyway
(either a small code rewrite, or an auxiliary client, as password changing
doesn't really seem like something that fits into a plugin SASL
architecture), so why not make it a seperate protocol at the same time?

  Just for fun, I threw together and attached a definition of a password
change protocol. I didn't include a "service" parameter; it seems like one
could use a seperate password-change service for each service-specific
password, and trying to include it made things a bit complicated.  Any
comments? 

  )Rob

Network Working Group                                         R. Earhart
Internet Draft: PCP                                      Carnegie Mellon
Document: draft-earhart-pcp-spec-00.txt                     January 1998
Expires July 1998

                        Password Change Protocol

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  and may be updated, replaced, or obsoleted by other
   documents at any time.  It is not appropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   This document suggests a proposed protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this draft is unlimited.

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Abstract

   Shared secrets are a common part of many authentication systems.  It
   is widely believed that occasionally changing the shared secret
   increases system security.  PCP provides a general mechanism by which
   clients may change a shared secret associated with an authentication
   mechanism.

Earhart                                                         [Page 1]

Internet DRAFT          Password Change Protocol            January 1998

1.   Introduction

   PCP is used to change a user's password for a given authentication
   mechanism in a secure fashion, as either an independent protocol or
   composed with another protocol using AP.

   PCP uses the AP framework for syntax and basic protocol semantics, as
   this is simpler, cleaner, and clearer than writing the protocol from
   scratch.

2.   Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [KEYWORDS].

3.   Protocol Overview

   At session startup, the server indicates its willingness to offer
   password-changing capability by sending the PCP capability in the
   initial AP greeting.

   If a SASL [SASL] security mechanism is negotiated via the
   AUTHENTICATE which is of acceptable strength to the server, and
   session integrity and privacy have been enabled, the server MUST send
   an untagged PCP response just before the completion of the
   AUTHENTICATE command, indicating its willingness to perform password
   change operations.

   Once the session is in the authenticated state, the client MAY
   proceed to issue CHANGEPW commands to set users' passwords, at any
   time until the session is closed.  Clients are responsible for
   independently deciding whether or not the negotiated mechanism,
   integrity, and privacy are suitable, but MUST NOT issue CHANGEPW
   commands unless the server has issued an untagged PCP response.

4.   Link Level

   The AP framework assumes a reliable data stream such as provided by
   TCP.  When TCP is used and PCP is not used with another service, a
   PCP server listens on port <xxx>.

5.   Capabilities, Commands, and Responses

Earhart                                                         [Page 2]

Internet DRAFT          Password Change Protocol            January 1998

   PCP defines a single capability, "PCP" (which MUST be sent by a
   server implementing PCP in the initial AP session greeting), the PCP
   untagged response (to be sent as part of the AUTHENTICATE command),
   and the CHANGEPW command, which is used for changing the user's
   password.

5.1. PCP Response

   Data:       none

      The PCP untagged response is sent in response to a successful AP
      AUTHENTICATE command, before the AUTHENTICATE completes, to
      indicate that the server accepts the negotiated authentication
      mechanism and session integrity and privacy layers for the purpose
      of password change.

      Servers advertising the PCP capability MUST send a PCP untagged
      response to an authenticate command if and only if the negotiated
      mechanism and session security and privacy layers are suitable to
      the server for sending passwords.

      Clients MUST NOT attempt to change a user's password unless they
      have received a PCP untagged response from the server.

5.2. CHANGEPW Command

   Arguments:  userid or NIL
               auth-type
               new-password

   Data:       none

   Result:     OK - password changed
               NO - password unacceptable or insufficient authorization
               BAD - command unknown, arguments invalid, negotiated
               security layer unacceptable for password changes
               (accompanied by an AUTH-TOO-WEAK response code), or
               encryption is not enabled for the connection (accompanied
               by an ENCRYPT-NEEDED response code)

      The CHANGEPW command changes the password for the indicated user
      (or, if NIL, for the userid used in authentication) on the
      server's system for a given authentication mechanism to the new
      password.  This MAY change the user's password for other
      authentication mechanisms on the same system which use the same
      database.

Earhart                                                         [Page 3]

Internet DRAFT          Password Change Protocol            January 1998

      The server MAY perform arbitrary validation of the password; if
      the password is unacceptable for any reason, the server MAY
      respond with a NO.

      If the server does not feel the negotiated security layer is
      strong enough for password changes, it MAY reject the request with
      an AUTH-TOO-WEAK response code (this may occur when PCP is coupled
      with another service on the same connection).  If the security
      layer is strong enough but session integrity or privacy is
      disabled, it MUST reject the request with an ENCRYPT-NEEDED
      response code.

         Note that both of these are considered BAD conditions; they
         should never arise in practice.  A server MUST NOT send a PCP
         untagged response unless the security layer is considered
         strong and session integrity and privacy are enabled, and a
         client MUST NOT attempt to change a password unless it has
         received a PCP untagged response, so if either of the above two
         conditions is not met, something has gone drastically wrong.

      When PCP is being used by itself, the server MUST NOT allow any
      authentication mechanisms or integrity/privacy layers to be
      negotiated which are not acceptable for password transmission.

      The CHANGEPW command MUST only be used in the authenticated state,
      and MUST ONLY BE USED IF A PCP UNTAGGED RESPONSE HAS BEEN
      RECEIVED.

      The string sent as the new password is the user's plaintext
      password.

         Note: This could, instead, be defined on a per-mechanism basis,
         as something appropriate to the mechanism; for instance, with
         CRAM-MD5, the 16-octet shared secret that the server has to
         store could be sent across, instead of the user's plaintext
         password.  I think it's better to send the password itself
         across, though, as some site administrators will want to
         validate their users' password choices, and doing so without
         the plaintext password is difficult.

      Example:  C: a001 CHANGEPW NIL "CRAM-MD5" "blurdybloop"
                S: a001 OK "Password changed"

6.   Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [ABNF].  This uses the ABNF core

Earhart                                                         [Page 4]

Internet DRAFT          Password Change Protocol            January 1998

   rules as specified in Appendix A of the ABNF specification [ABNF],
   and augments the core AP grammar specified in [AP].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   capability      =/ "PCP"

   command         =/ "CHANGEPW" SP userid SP auth-type SP new-password

   new-password    = string

   status-response =/ "PCP" resp-body
                      ; must be untagged

   userid          = string / NIL

7.   Security Considerations

   Security considerations are discussed throughout this memo.

   Changing a user's password is a very delicate operation.  Servers and
   clients MUST insist on appropriate authentication, session integrity
   and privacy for password changes.

   In particular:

      Clients MUST NOT send a user's password in the clear.

      Clients MUST NOT attempt to change a user's password unless the
      PCP untagged response has been received (this is intended to
      prevent an old client from attempting to use a mechanism that the
      server knows is weak).

      Servers MUST NOT send the PCP untagged response unless they are
      willing to entrust their user's passwords to the negotiated
      authentication, integrity, and privacy mechanisms.

      Clients and servers MUST take active attacks into account, and not
      allow the use of a weak security mechanism, or the disabling of
      session integrity or privacy layers (this has been stated numerous
      times, but is considered well worth repeating).

Earhart                                                         [Page 5]

Internet DRAFT          Password Change Protocol            January 1998

8.   Copyright

   Copyright (C) The Internet Society 1998. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

9.   References

   [AP] Earhart, R., "Access Protocol", Work in Progress.

   [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

      <url:ftp://ds.internic.net/rfc/rfc2234.txt>

   [CRAM-MD5] Klensin, J., Catoe, R., and Krumviede, P., "IMAP/POP
   AUTHorize Extension for Simple Challenge/Response", RFC 2195,
   September 1997.

      <url:ftp://ds.internic.net/rfc/rfc2195.txt>

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

Earhart                                                         [Page 6]

Internet DRAFT          Password Change Protocol            January 1998

      <url:ftp://ds.internic.net/rfc/rfc2119.txt>

   [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
   RFC 2222, October 1997.

      <url:ftp://ds.internic.net/rfc/rfc2119.txt>

10.  Author's Address

   Robert H. Earhart
   Carnegie Mellon
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

   Email: [email-masked]

Expires July 1998

Earhart                                                         [Page 7]

---

From: Chris Newman <[email-masked]>
Date: Mon, 29 Dec 1997 16:15:59 -0800 (PST)

- Chris

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Dec 1997 16:44:07 -0800

--Paul Hoffman, Director

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Dec 1997 20:06:08 -0500 (Eastern Standard Time)

---

From: "Robert J. DuWors" <[email-masked]>
Date: Mon, 29 Dec 1997 21:04:51 -0500

--Rob DuWors

---

From: Chris Newman <[email-masked]>
Date: Tue, 30 Dec 1997 00:37:43 -0800 (PST)

---

From: Rob Earhart <[email-masked]>
Date: Tue, 30 Dec 1997 15:49:57 -0500 (EST)

)Rob

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 Dec 1997 13:40:50 -0800

---

From: Rob Earhart <[email-masked]>
Date: Thu, 1 Jan 1998 00:52:42 -0500 (EST)

)Rob

                        Password Change Protocol

Status of this Memo

Abstract

Earhart                                                         [Page 1]


1.   Introduction

3.   Protocol Overview

4.   Link Level

Earhart                                                         [Page 2]


5.1. PCP Response

   Data:       none

5.2. CHANGEPW Command

   Arguments:  userid or NIL
               auth-type
               new-password

   Data:       none

Earhart                                                         [Page 3]


6.   Formal Syntax

Earhart                                                         [Page 4]


   capability      =/ "PCP"

   new-password    = string

   userid          = string / NIL

   In particular:

Earhart                                                         [Page 5]


8.   Copyright

9.   References

Earhart                                                         [Page 6]


10.  Author's Address

   Robert H. Earhart
   Carnegie Mellon
   5000 Forbes Ave.

   Email: [email-masked]

Expires July 1998

Earhart                                                         [Page 7]