Subject: re: Expiring Passwords

From: "Robert J. DuWors" <[email-masked]>
Date: Thu, 01 Jan 1998 20:15:18 -0500

At 12:52 AM 1/1/98 -0500, Rob Earhart wrote:
>
>
>      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"
>

This could be even worse than USER/PASS over light weight un-encrypted
links where SASL has great appeal.  OTH, verification of pass phrase
constraints by the server is highly desirable.  It would seem reasonable
that the passing of the passphrase itself should be make subject to a
password protection mechanism, e.g.

C: CHANGEPW CRAM-MD5
S: <changepw-cram challenge>
C: <changepw-cram response*> XOR <new-passphrase>

*This would have to modified CRAM: the authentication-id which is already
known need not be resent and the passphrase could be longer than the length
of the CRAM proof; it also implicitly reuses the old password one last time
as part of the cram response computation.

--Rob DuWors

--------------------------------------------------------------
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: Mon, 05 Jan 1998 12:09:50 -0800 (PST)

> C: <changepw-cram response*> XOR <new-passphrase>

I've been thinking about this sort of model for password changing for a
while.  The problem with this is that hash-function-based encryption
algorithms (which this is) have not been carefully analysed and thus
aren't trusted by the cryptography community.  They also have the same
problems with export regulations as better encryption algorithms.  If
you're going to encrypt the new passphrase you may as well use a safer
cryptographic algorithm such as triple-DES. 

There is some speculation that if the security is restricted to only the
old and new passphrase then the binary form of the program would be
exportable.  The government generally doesn't care about restricting
authentication -- it just doesn't want to permit export of programs which
can hide data from them.

After conversations with John Myers, I actually like the idea of a
password change protocol with a mandatory to implement real crypto
algorithm.  I think it's simpler than a bunch of mechanism specific
password change methods.

		- Chris

---

From: Rob Earhart <[email-masked]>
Date: Tue, 6 Jan 1998 16:51:03 -0500 (EST)

After some comments (thanks, Jack!), I've revised the proposal for PCP,
and attached a new copy.  The biggest change is that it no longer deals
with specific mechanisms (CRAM-MD5, Kerberos, etc), and instead does
things with services (IMAP, ACAP, all, mail-related, etc...), which I
think is probably easier for users to comprehend, and allows for site
definitions of service-specific passphrases to be dealt with quite
cleanly.

  I think I'd rather just require that the entire session be encrypted
with something strong, rather than trying to use some sort of
mechanism-specific thing to transfer the passphrase, which quickly becomes
complicated.

  )Rob

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

                       Passphrase 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

   Passphrases are a common part of many authentication systems.  It is
   widely believed that occasionally changing one's passphrase increases
   system security.  PCP provides a general mechanism by which clients
   may change the passphrase associated with some set of services.

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

1.   Introduction

   PCP is used to change a user's passphrase for some set of services 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
   passphrase-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
   passphrase change operations.

   Once the session is in the authenticated state, the client MAY
   proceed to list the available service-tags using the LISTPWSERVICES
   command, and issue CHANGEPW commands to set a user's passphrase for a
   set of services associated with those service-tags, 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.

   A service-tag is an opaque string, defined by the server within the
   context of the connection, which corresponds to some set of services
   for which the user's passphrase may be changed.

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

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

   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),
   the LISTPWSERVICES command and PWSERVICE response used for obtaining
   the list of service-tags, and the CHANGEPW command, which is used for
   changing the user's passphrase for a given set of services.

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 passphrase 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 passphrases.

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

5.2. LISTPWSERVICES Command

   Arguments:  none

   Data:       intermediate response: PWSERVICE

   Result:     OK - listpwservices completed
               BAD - command unknown or arguments invalid

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

      The LISTPWSERVICES command generates PWSERVICE responses to
      enumerate the service-tags available for use with the CHANGEPW
      command, as well as providing human-readable descriptions for each
      service-tag.

      Example:  C: a002 LISTPWSERVICES
                S: a002 PWSERVICE "all" "Passphrase used for all
                services"
                S: a002 PWSERVICE "mail" "Passphrase used for all mail-
                related services"
                S: a002 PWSERVICE "IMAP" "IMAP-specific passphrase"
                S: a002 PWSERVICE "POP3" "POP3-specific passphrase"
                S: a002 OK "ListPWServices Complete"

5.3. PWSERVICE Intermediate Response

   Data:       service-tag
               human-readable service description

      The PWSERVICE response identifies a service-tag and associates a
      human-readable string with the service-tag.  The human-readable
      description MAY be presented to the user.  The service-tag MUST be
      treated as an opaque string, useful only within the context of the
      current session, to be handed back to the server in a CHANGEPW
      command.

      The human-readable description MUST be in the current session
      language, as set via the AP LANG command.  If no language has been
      set, the descriptions MUST be in the registered language
      "i-default" [CHARSET-LANG-POLICY], intended for an international
      audience.

5.4. CHANGEPW Command

   Arguments:  userid or NIL
               service list
               new-passphrase

   Data:       none

   Result:     OK - passphrase changed
               NO - passphrase unacceptable or insufficient
               authorization
               BAD - command unknown, arguments invalid, negotiated
               security layer unacceptable for passphrase changes

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

               (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 passphrase for the indicated user
      (or, if NIL, for the userid used in authentication) for the
      supplied services to the new passphrase.

      This MUST NOT change the user's passphrase for any other services
      not associated with the service-tags supplied in the service list.
      Users SHOULD be able to figure out exactly which passphrases are
      being changed from the textual description supplied with each
      service-tag.

      The server MAY perform arbitrary validation of the passphrase; if
      the passphrase 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 passphrase 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 passphrase 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 passphrase 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 passphrase is the user's plaintext
      passphrase.

      Example:  C: a003 CHANGEPW NIL ("IMAP" "POP3") "blurdybloop"
                S: a003 OK "Passphrase changed"

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

6.   Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
   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 service-list SP new-passphrase

   command         =/ "LISTPWSERVICES"

   new-passphrase  = string

   response        =/ "PWSERVICE" SP service-tag SP service-descrip

   service-descrip = string-utf8
                   ; must be in the current language

   service-list    = '(' service-tag *(SP service-tag) ')'

   service-tag     = 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 passphrase is a very delicate operation.  Servers
   and clients MUST insist on appropriate authentication, session
   integrity and privacy for passphrase changes.

   In particular:

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

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

      Clients MUST NOT attempt to change a user's passphrase 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 passphrases 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).

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.

Earhart                                                         [Page 7]

Internet DRAFT         Passphrase Change Protocol           January 1998

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

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

   [CHARSET-LANG-POLICY] Alvestrand, H., "IETF Policy on Character Sets
   and Languages", work in progress.

   [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.

      <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/rfc2222.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 8]

---

From: Chris Newman <[email-masked]>
Date: Wed, 07 Jan 1998 15:22:12 -0800 (PST)

> mechanism-specific thing to transfer the passphrase, which quickly becomes

A few comments:

(1) You are duplicating earlier work.  See draft-newman-pwchange-00.txt.
It's far from done, but there's a lot of work behind it.

(2)  I'm not sure a password change protocol should be based on AP -- it
needs to be as simple as possible so it can be given a complete security
analysis.

(3) Encrypting the whole session is not the right option, because it
either can't be exported or is worthless for protecting a passphrase.  If
you encrypt *just* the old & new passphrase then it should be exportable
even with real encryption.

(4) Unless you mandate TLS or a SASL mechanism with a security layer,
there's no way this can get standardized when it passes the new passphrase
in the clear.

(5) You haven't defined any error codes.  There are a number of important
ones.

		- Chris

---

From: Rob Earhart <[email-masked]>
Date: Thu, 8 Jan 1998 12:06:25 -0500 (EST)

> It's far from done, but there's a lot of work behind it.

  Ah - okay.  (Sorry...)

> needs to be as simple as possible so it can be given a complete security

  All AP does is provide a framing mechanism; there really aren't any
security issues other than those associated with using SASL over TCP,
which I believe are reasonably well understood.  Furthermore, I think that
by seperating the command syntax from the protocol semantics, the protocol
is clearer and easier to understand (I'm amused that, even with all the
redundency, the draft I proposed is half the length of
draft-newman-pwchange-00.txt). 

> even with real encryption.

  I find this argument specious, unless you've got a statement from the US
government that such a scheme would be exportable (which wouldn't make any
sense, but that hasn't exactly stopped the government before).

  I fail to see the distinction between encrypting just the passphrase,
and encrypting the entire session, when the connection only provides the
ability to change one's passphrase.

  Furthermore, I fail to see (from the government's angle) the safety in
allowing the export of software which only encrypts the passphrase;
there's little reason why the passphrase, being an essentially arbitrary
blob of data determined by the user, couldn't be used to communicate
information which the government would like to see.

  If one's permitted, the other ought to be permitted.  (And again - it
wouldn't surprise me to discover otherwise, but I'd like to see an
official statement to that effect...) 

  In addition, I think it's probably best to keep the OK/NO response
private; I'm not certain that it matters, but as an attacker, I'd like to
know when my target's passphrase has changed.

> there's no way this can get standardized when it passes the new passphrase

  The proposal I made specifies several times that session privacy MUST be
used; therefore, a conforming implementation must not send the passphrase
in the clear.  Mandating TLS or a SASL mechanism will greatly increase
interoperability, but I didn't see that as being as important in this
draft; the important part is that session privacy MUST be used. 

> (5) You haven't defined any error codes.  There are a number of important

  Reasonable; specific error codes for the different failure modes
wouldn't be hard to add...

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 10:58:21 -0800 (PST)

> draft-newman-pwchange-00.txt). 

AP includes the ability to have multiple commands in progress and
unsolicited notifications.  While this is useful in things like IMAP or
ACAP, it's unnecessary complexity when changing passphrases.

I will note that draft-newman-pwchange-00.txt is shorter than your AP
spec, let alone the combination of your AP spec and your pwchange spec.
In addition, your pwchange spec is missing the error codes which are a
significant part of the length of draft-newman-pwchange-00.txt.

> sense, but that hasn't exactly stopped the government before).

The government doesn't care about authentication -- only encryption of
data.  Therefore encryption which can't be used for anything but
authentication is exportable in binary form.

> ability to change one's passphrase.

Protocols need to be extensible.  Passphrases don't.  There's also lots of
arbitrary text communicated from the server to the client (error
messages) which has to be configurable on the server.  If you went to a
protocol with no configurable messages, then encrypting the entire
protocol work (but it wouldn't be AP-based).

> draft; the important part is that session privacy MUST be used. 

Not good enough -- if you mandate privacy, you have to mandate at least
one way of providing it.  If you mandate TLS, then the protocol is rather
over-complicated and can't be deployed for a while (until the SSL
toolkits are upgraded).  If you mandate a SASL security layer, that means
it will only work with a very limited set of mechanisms.

		- Chris

---

From: Rob Earhart <[email-masked]>
Date: Thu, 8 Jan 1998 15:50:24 -0500 (EST)

> ACAP, it's unnecessary complexity when changing passphrases.

  ... and TCP includes features like two sides simultaneously initiating
active connections to each other and urgent bytes, which're probably
overboard for the simple task of changing passphrases.  Nevertheless, I
think we can agree that TCP is a useful protocol layer (and note that
there's no reason why either side in an AP session needs to support
multiple commands in progress, and unsolicited notifications can be
ignored.)

  AP just sweeps all the syntax nonsense under the rug, providing a
fairly clean way of encapsulating commands which seems to work in the real
world.  I don't mind not using it - especially since you've already got a
draft out - but I disagree with your reasoning, and honestly think it's a
superior technical solution.

> significant part of the length of draft-newman-pwchange-00.txt.

  I honestly think you've gone overboard with error codes; the level of
detail brought to mind the infamous "Recipient has died" code.  In my
opinion (reinforced from earlier conversations with you and John G.
Myers), response codes should be minimal, dealing with things which the
client can actually do something about (REFER is a great example of this),
and anything else should be encapsulated in text returned to the user.

> authentication is exportable in binary form.

  Yes... but in this case, you're encrypting data.  True, the data will be
used (theoretically) for authentication, but the passphrase could also be
used for secrets ("meet in the old hideout at midnight"). 

> protocol work (but it wouldn't be AP-based).

  You've definitely lost me, here.

  The protocol needs to be extensible; I'm not sure why this prevents the
protocol from being encrypted.

  If you're allowed to ship a product that encrypts the passphrase (which
could be used to transmit sensitive data, but is only supposed to be used
for transmission of authentication information), why aren't you allowed to
ship a product that encrypts the entire protocol session, as long as you
don't allow any other functionality to be used with encryption?  In both
cases, that encryption's only used for the transmission of authentication
information; either both are exportable, or neither is.  (I'd bet that
neither is.)

> one way of providing it.

  No.  Unfortunately, this is a situation in which compatibility can not
be maintained.  Any mechanism we mandate may be broken in the future.  We
can not require servers to accept some mechanism for the sake of older
clients; all we can do is have the server advertise what it's willing to
use, and have clients attempt to do the best they can.

  We can have short-term interoperability; we can not get long-term
interoperability.  Clients have to be able to say, "Sorry, the server
doesn't permit the use of any mechanisms we know about; please upgrade."

  It's futile to mandate a security layer that servers must accept, but I
don't think it's futile to mandate that, whatever mechanism a server
*does* accept, that it must support session privacy. 

  )Rob

---

From: Steve Hole <[email-masked]>
Date: Thu, 8 Jan 1998 15:06:12 -0700

> ability to change one's passphrase.

If you are encrypting the entire session, then you are free to pass whatever 
data you would like over the connection with no way for big brother to verify 
that it at least pretends to be protocol X.   The entire protocol will have 
variable, non-verifiable data lengths that could very easily hold relatively 
large encoded messages containing the floorplan of the Pentagon.

While you could decide to use 1000 character passwords, any encrypted item of 
this size in a password change protocol that exposed all but the passwords 
would be suspect.   In other words, it is possible to pass data rather than 
legitimate passwords, it is much easier to detect that someone is doing so and 
much harder to mask.

This has always been the jist of the "authentication OK, channel protection 
BAD" argument used by the US Government spooks.   It is reasonable -- hardly.  
It is what it is though.

---  
Steve

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 14:04:13 -0800 (PST)

> *does* accept, that it must support session privacy. 

The IESG has made a clear statement on this issue with respect to the TLS
standardization.  The TLS WG was told they had to require implementation
of a particular cipher suite.

It works like this: the mandatory to implement mechanism is the minimum
level of protection you can expect to work.  If you have no mandatory to
implement mechanism, then the minimum level is none (poppassd in this
instance).

In the future, it may not be desirable to use the mandatory to implement
mechanism, but it will be the best available that works.

		- Chris

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 14 Jan 1998 10:13:10 -0800

It seems to me there a transition problem using UTF8 in SASL. For example
if I set my password to something in greek using an app that supports UTF8,
and then try to login from an app that doesn't support UTF8 (most today) I
will never be able to login. In addition adding UTF8 support for SASL on
platforms that don't support it will be rather difficult. I believe there's
also an issue with fonts and input methods for particular characters, which
probably can never be solved universally.

About the best solution I can think of for this is to recommend that the
user be given a warning when they change their password to something that
is beyond US-ASCII to the effect that they will only be able to login from
clients that support Unicode.

Anyone thought further about this issue (or is my incomplete understanding
of Unicode showing)?

LL

---

From: Chris Newman <[email-masked]>
Date: Wed, 14 Jan 1998 11:55:21 -0800 (PST)

> Anyone thought further about this issue (or is my incomplete understanding

Yup, your conclusion sounds right.  If characters with the high bit set
are present, they are interpreted in UTF-8.  But use of characters outside
the printable US-ASCII range is discouraged. 

It's important to state how characters with the high bit set are
interpreted, otherwise there will never be interoperable i18n in user 
names and passphrases.

The server code I write will explicitly reject 8-bit
user/passphrase strings which fail to meet UTF-8 syntax requirements.
Otherwise, clients might be sloppy and use localized character sets.

		- Chris

---

From: Mark Wahl <[email-masked]>
Date: Wed, 14 Jan 1998 14:46:32 -0600

> Otherwise, clients might be sloppy and use localized character sets.

As LDAPv3 (RFC 2251-2256) is derived from X.500, there is currently no 
requirement that a password value be in UTF-8.  The octetStringMatch used
for comparing passwords does a byte-by-byte matching.  Passwords may be 
assigned to system services and devices which are not human-readable
strings, but simply blobs of data.

The token "UTF" did not appear in RFC 2195 or RFC 2222.  If these documents
were not updated to REQUIRE that passwords be UTF-8 encoded, then I would be
concerned that implementations of SASL mechanisms such as CRAM-MD5 and 
sucessors which restricted passwords this way would not be interoperable in
the application of SASL in LDAPv3.

If an RFC updating 2222 were to mandate the UTF-8 encodings of passphrases,
then this would likely require minor changes to protocols being based on SASL.
I am not averse to requring UTF-8 in the documents, but would wish to ensure 
that protocol designers are kept informed on the planned evolution of SASL. 
(Hopefully soon there will be a new draft update to 2195 which also addresses 
 the space in username problem.)

LDAPv3 Distinguished names, BTW, are written in UTF-8 when the components are 
strings.

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 09:34:15 -0800 (PST)

> the application of SASL in LDAPv3.

In addition, I wouldn't want to make a non-backwards compatible change to
RFC 2222 which would require a recycle at proposed status.

This is a bit of a mess, becuase right now if you use non-ASCII characters
in usernames/passphrases, they simply won't work unless both ends happen
to have the same localized character set.

I will note that all the SASL mechanisms I'm working on will require UTF-8
for user identities and passphrases.

Anyone have ideas of how to deal with this on the standards front?

Perhaps the draft standard revision can simply encourage profiles and
mechanisms to require UTF-8 for human readable strings associated with
SASL?

CRAM-MD5 currently doesn't specify the charset used.  That needs to be
fixed.

>  the space in username problem.)

While I'm sure we could easily document a bunch of interoperable 2195
implementations (we have two independent interoperable implementations
in-house -- one in C and one in Pascal :-), it can't really be moved to
draft status until SASL moves to draft status.  I've sent proposed text
for the space in username problem to the document editors for 2195, but
it's probably not worth a new RFC until SASL can move forward to draft
status. 

		- Chris

---

From: Mark Wahl <[email-masked]>
Date: Thu, 15 Jan 1998 19:07:41 -0600

I am not sure that requiring UTF-8 for passphrases would necessarily belong 
in the SASL definition itself, given that not all mechanisms use passphrases.
However, I think its document might suggest the use of UTF-8 when passphrases
are used, w/o requiring it to recycle to PS, since this suggestion does not 
affect existing deployed/documented mechanisms.  

Were the CRAM-MD5 and other documents to require UTF-8 for name and password, 
then they would need to recycle.

---

From: [email-masked] (John Myers)
Date: Mon, 26 Jan 1998 11:11:56 -0800

Harald Tveit Alvestrand wrote:
> 
> At 14:03 23.01.98 -0800, John Gardiner Myers wrote:
> >We should crib from the charset policy.  How about:
> >
> >All mechanisms MUST identify, for all character data, which charset
> >is in use.  Any field containing an authorization id MUST encode that
> >field using the UTF-8 charset [UTF-8].  Other fields containing text
> >SHOULD encode that text using the UTF-8 charset.
> >
> >This standard does not itself require mechanism implementations to be
> >able to generate or accept arbitrary UTF-8 characters.
> >
> 
> seems OK with me - except that I want to clarify that this is for the
> case where an "authorization ID" is text.

The intent is that when the "authorization ID" exists, it is always
text.  The main SASL document does need more clarification about the
authorization ID and its use.

> And: we DO have a requirement to ACCEPT arbitrary UTF-8 characters, at
> least to the point where you can say authoritatively that this authid
> does NOT match any valid authid; "blowing up is not acceptable".

This standard does not itself require mechanism implementations to be
able to generate or grant access to identities containing arbitrary
UTF-8 characters.

---

From: "Robert J. DuWors" <[email-masked]>
Date: Thu, 01 Jan 1998 20:15:18 -0500

C: CHANGEPW CRAM-MD5

--Rob DuWors

---

From: Chris Newman <[email-masked]>
Date: Mon, 05 Jan 1998 12:09:50 -0800 (PST)

- Chris

---

From: Rob Earhart <[email-masked]>
Date: Tue, 6 Jan 1998 16:51:03 -0500 (EST)

)Rob

Status of this Memo

Abstract

Earhart                                                         [Page 1]


1.   Introduction

3.   Protocol Overview

Earhart                                                         [Page 2]


4.   Link Level

5.1. PCP Response

   Data:       none

   Arguments:  none

Earhart                                                         [Page 3]


   Data:       service-tag

5.4. CHANGEPW Command

   Arguments:  userid or NIL
               service list
               new-passphrase

   Data:       none

Earhart                                                         [Page 4]


Earhart                                                         [Page 5]


6.   Formal Syntax

   capability      =/ "PCP"

   new-passphrase  = string

   service-tag     = string

   userid          = string / NIL

   In particular:

Earhart                                                         [Page 6]


8.   Copyright

9.   References

Earhart                                                         [Page 7]


10.  Author's Address

   Robert H. Earhart
   Carnegie Mellon
   5000 Forbes Ave.

   Email: [email-masked]

Expires July 1998

Earhart                                                         [Page 8]

---

From: Chris Newman <[email-masked]>
Date: Wed, 07 Jan 1998 15:22:12 -0800 (PST)

A few comments:

		- Chris

---

From: Rob Earhart <[email-masked]>
Date: Thu, 8 Jan 1998 12:06:25 -0500 (EST)

Ah - okay.  (Sorry...)

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 10:58:21 -0800 (PST)

- Chris

---

From: Rob Earhart <[email-masked]>
Date: Thu, 8 Jan 1998 15:50:24 -0500 (EST)

)Rob

---

From: Steve Hole <[email-masked]>
Date: Thu, 8 Jan 1998 15:06:12 -0700

---  
Steve

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 14:04:13 -0800 (PST)

- Chris

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 14 Jan 1998 10:13:10 -0800

LL

---

From: Chris Newman <[email-masked]>
Date: Wed, 14 Jan 1998 11:55:21 -0800 (PST)

- Chris

---

From: Mark Wahl <[email-masked]>
Date: Wed, 14 Jan 1998 14:46:32 -0600

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 09:34:15 -0800 (PST)

- Chris

---

From: Mark Wahl <[email-masked]>
Date: Thu, 15 Jan 1998 19:07:41 -0600

---

From: [email-masked] (John Myers)
Date: Mon, 26 Jan 1998 11:11:56 -0800