Subject: OK to send e-mail?

From: [email-masked]
Date: Sat, 31 Jan 1998 07:20:07 -0500 (EST)

OK to send an e-mail to [email-masked]? 

Date: Sat, 31 Jan 1998 07:20:07 -0500 (EST)
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: OK to send e-mail?
Sender: [email-masked]

OK to send an e-mail to [email-masked]? 

From: Steve Hole <[email-masked]>
Date: Wed, 28 Jan 1998 13:34:33 -0700
To: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: key generation from passphrase, UTF-8
Cc: [email-masked]
Sender: [email-masked]

On Wed, 28 Jan 1998 15:46:52 +0100 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>   (2) remove leading and trailing white space
>    characters; (3) replace one or more contiguous white space characters
>    by a single space (ASCII or UTF-8 0x20); (4) convert all letters to
>    lower case and replace sequences of characters and non-spacing
>    accents with a single character, where possible. A minimum length of
>    16 key characters (after applying the transformation) should be
>    enforced by the application, while applications must allow up to 256
>    characters of input.

I don't know about anyone else, but this seems like a horribly bad
idea to me.   Because you have translated into 10646, how do you determine
what is uppercase and whitespace?   Also removing this information will
make the space easier to search in a dictionary attack -- a little counter
productive I would think.   In fact, if I found out that and algorithm 
was mangling my carefully selected password in such a way that it made
it easier to brute force, I would be quite upset.

Cheers.

---  
Steve

From: "Larry Osterman (Exchange)" <[email-masked]>
To: "'Chris Newman'" <[email-masked]>, Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: RE: key generation from passphrase, UTF-8
Date: Wed, 28 Jan 1998 10:10:36 -0800
Sender: [email-masked]

Doesn't this canonicalization also mean that dictionary attacks are
significantly easier?  After all this removes multiple spaces and upper
case letters from the keyspace.  Yes there is a 16 character recommended
minimum key length, but since the new key space only has lower case
characters and punctuation characters in it, it's significantly smaller
than the original keyspace

Larry Osterman
Via Exchange 5.5 on Larryo-Laptop.dns.microsoft.com.
Please notify the sender of any difficulties.

-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Wednesday, January 28, 1998 9:50 AM
To: Harald Tveit Alvestrand
Cc: [email-masked]
Subject: Re: key generation from passphrase, UTF-8

On Wed, 28 Jan 1998, Harald Tveit Alvestrand wrote:
>    the Unicode space characters table. The transformation consists of
>    the following steps: (1) convert the input string to the ISO 10646
>    character set, using the UTF-8 encoding as specified in Annex P to
>    ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO
>    8859-1 characters do);

This is the only part I agree with.  I'd also add that use of NUL is
forbidden and use of non-printing characters is discouraged.

>    (2) remove leading and trailing white space
>    characters; (3) replace one or more contiguous white space
characters
>    by a single space (ASCII or UTF-8 0x20); (4) convert all letters to
>    lower case and replace sequences of characters and non-spacing
>    accents with a single character, where possible. A minimum length
of
>    16 key characters (after applying the transformation) should be
>    enforced by the application, while applications must allow up to
256
>    characters of input.

These are all bad ideas, IMHO.  When you go to 10646, it's very hard to
determine if something is a spacing character or a lower/upper case
letter.  What happens when a new character is added with a critical
property you don't know about?  In addition, multiple spaces and mixed
case are good techniques to make a pass phrase harder to guess and to
defeat dictionary attacks.

Finally, this may not be implementable without using Unicode in addition
to 10646 -- I'm not sure 10646 lists spacing and case properties of
characters.

		- Chris

Date: Wed, 28 Jan 1998 09:50:25 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: key generation from passphrase, UTF-8
To: Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 28 Jan 1998, Harald Tveit Alvestrand wrote:
>    the Unicode space characters table. The transformation consists of
>    the following steps: (1) convert the input string to the ISO 10646
>    character set, using the UTF-8 encoding as specified in Annex P to
>    ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO
>    8859-1 characters do);

This is the only part I agree with.  I'd also add that use of NUL is
forbidden and use of non-printing characters is discouraged.

>    (2) remove leading and trailing white space
>    characters; (3) replace one or more contiguous white space characters
>    by a single space (ASCII or UTF-8 0x20); (4) convert all letters to
>    lower case and replace sequences of characters and non-spacing
>    accents with a single character, where possible. A minimum length of
>    16 key characters (after applying the transformation) should be
>    enforced by the application, while applications must allow up to 256
>    characters of input.

These are all bad ideas, IMHO.  When you go to 10646, it's very hard to
determine if something is a spacing character or a lower/upper case
letter.  What happens when a new character is added with a critical
property you don't know about?  In addition, multiple spaces and mixed
case are good techniques to make a pass phrase harder to guess and to
defeat dictionary attacks.

Finally, this may not be implementable without using Unicode in addition
to 10646 -- I'm not sure 10646 lists spacing and case properties of
characters.

		- Chris

Date: Wed, 28 Jan 1998 15:46:52 +0100
To: [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: key generation from passphrase, UTF-8
Sender: [email-masked]

I stumbled across the enclosed text in RFC 1890.
Is this something we need to take into consideration in SASL
(as in "bless, curse or negotiate")?

                      Harald

   The pass phrase typed by the user is transformed to a canonical form
   before applying the hash algorithm. For that purpose, we define
   return, tab, or vertical tab as well as all characters contained in
   the Unicode space characters table. The transformation consists of
   the following steps: (1) convert the input string to the ISO 10646
   character set, using the UTF-8 encoding as specified in Annex P to
   ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO
   8859-1 characters do); (2) remove leading and trailing white space
   characters; (3) replace one or more contiguous white space characters
   by a single space (ASCII or UTF-8 0x20); (4) convert all letters to
   lower case and replace sequences of characters and non-spacing
   accents with a single character, where possible. A minimum length of
   16 key characters (after applying the transformation) should be
   enforced by the application, while applications must allow up to 256
   characters of input.

NOTE: New Email address: [email-masked]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Call for volunteers: Moving SASL to draft status (fwd)
Date: Mon, 26 Jan 1998 11:32:27 -0800
Organization: Netscape Communications Corporation
Lines: 27
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Steve Hole wrote:
>
> Hang on a minute.   The issue is that a client and server GSSAPI will
> not interoperate if they implement different underlying mechanisms.  If
> so then: (1) this will probably not happen often in practise because
> the authentication infrastructure an organization uses is usually controlled
> by the organization and 

I'm not sure this is entirely true.  Organizations may control their
infrastructure, but they don't necessarily control what is included in
the deployed software.

> (2) if it does happen, then authentication fails for a
> valid reason.

Let's take an example: the client supports both Kerberos v5 under GSSAPI
and Kerberos v5 under SNEGO under GSSAPI.  The server is older and
supports Kerberos v5 under GSSAPI, but doesn't support SNEGO.

If the organization has a Kerberos V5 infrastructure set up, the client
can still send either Kerberos v5 under GSSAPI or Kerberos v5 under
SNEGO under GSSAPI.  If it sends the latter, authentication fails, but
this is not due to any policy reason.

The client can always fall back, but this was true before we put in
server advertisement of SASL mechanisms anyway.  We've simply gotten rid
of the benefit of having servers advertise available mechanisms.

Date: Mon, 26 Jan 1998 11:11:56 -0800
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: SASL & UTF8
Sender: [email-masked]

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.

Date: Fri, 16 Jan 1998 10:21:39 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Call for volunteers: Moving SASL to draft status (fwd)
To: Simon Spero <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

[recipient list trimmed]

On Fri, 16 Jan 1998, Simon Spero wrote:
> I've actually heard requests for a raw K5 profile cloned as much as
> possible from the K4 one.

Since we already have a defined way to do K5 in SASL, it would require a
*strong* justification to create a new one.  If you can convince Jeff
Schiller that it's a good idea to remove GSSAPI from the K5 picture, then
I'll go along.

> BTW, I've done a K4 IMAP-> Cyrus in C; authentication only though for
> legal reasons I'm supposed to do one in java but that may not be done
> before the IETF.

So you did an independent implementation of the SASL KERBEROS_V4
mechanism in an IMAP client and are willing to interoperability test?
(using the Cyrus lib for SASL in the a client wouldn't be independent).

Well it'd be nice to do testing in the IETF terminal room, we may have to
do some over the net later.

		- Chris

Date: Fri, 16 Jan 1998 10:08:05 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Call for volunteers: Moving SASL to draft status
To: Steve Hole <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Fri, 16 Jan 1998, Steve Hole wrote:
> Hmm ... something to think about Chris.   We implement all of the above 
> protocols with the same SASL infrastructure.   I'm sure that most 
> multiprotocol clients will do it that way.  I'm not sure how this 
> "qualifies".

I don't see that as a problem.  The point of testing SASL profiles is to
make sure that if a profile follows the rules it will interoperate.

> Not sure what you mean by EXTERNAL mechanism Chris.   Is this for the 
> "plugin" stuff that we talked about in relationship to the API?   The 
> Simeon clients and servers support 3 more mechanisms not listed here, 
> with a couple of others in experimental development.   How do they fit?

Nope.  The "EXTERNAL" mechanism in section 7.4 of RFC 2222.

> I would recommend splitting each of the mechanism definitions into separate 
> documents, all subsidiary to a framework and mechanism registration document.

I'd like to see KERBEROS_V4 and EXTERNAL remain in the SASL base spec, if
possible.  I don't see how we can keep GSSAPI in the SASL base spec at
draft status since GSSAPI has interoperability problems so it's stuck at
proposed status.

		- Chris

From: Steve Hole <[email-masked]>
Date: Fri, 16 Jan 1998 10:24:07 -0700
To: Chris Newman <[email-masked]>
Subject: Re: Call for volunteers: Moving SASL to draft status
Cc: [email-masked]
Sender: [email-masked]

On Thu, 15 Jan 1998 10:30:01 -0800 (PST) Chris Newman 
<[email-masked]> wrote:

> By IETF procedure, it will be possible to move SASL to draft status in
> April.  In order to make it that soon, we need to complete some work in
> the next 3 months to identify interoperable implementations.  (Personally,
> I'd like to see SASL become the first IETF standard security protocol
> other than APOP). 
> 
> IETF procedure gives the WG chair responsibility to document interoperable
> implementations.  As SASL was an individual submission by John Myers, I'll
> volunteer to document interoperable implementations.
> 
> So what does it mean to have two independent interoperable implementations
> of SASL?
> 
> Here's my concept:
> 
> We need to demonstrate interoperability of SASL profiles (including
> optional portions), SASL mechanisms, SASL authorization identity and SASL 
> security layers.  So we need to identify at least two clients and two
> servers for each of the following which provide interoperable
> authentication via SASL (send me email to volunteer for any of these or
> for any other protocols):
>  * IMAP
>    -> _____ server  [[email-masked]]
>    -> CMU Cyrus server
>    -> CMU Cyrus imtest client
>    -> ESYS Simeon client [[email-masked]]
>  * LDAPv3
>    -> _____ server
>    -> _____ server
>    -> _____ client
>    -> _____ client
>  * ACAP
>    -> CMU Cyrus server
>    -> _____ server  [[email-masked]]
>    -> _____ client  [[email-masked]]
>    -> ESYS Simeon client [[email-masked]] (IMSP now, ACAP in 
                                                development)
   * SMTP
     -> _____ server
     -> _____ server
     -> Esys Simeon Client [[email-masked]]          
     -> _____ client

Hmm ... something to think about Chris.   We implement all of the above 
protocols with the same SASL infrastructure.   I'm sure that most 
multiprotocol clients will do it that way.  I'm not sure how this 
"qualifies".

>  * KERBEROS_V4 mechanism (including security layer)
>    -> _____ server
>    -> CMU Cyrus server
>    -> CMU Cyrus imtest client
>    -> Esys Simeon client [[email-masked]]
>  * CRAM-MD5 mechanism
>    -> _____ server
>    -> _____ server  [[email-masked]]
>    -> _____ client  [[email-masked]]
>    -> Esys Simeon client [[email-masked]]
>  * EXTERNAL mechanism
>    -> _____ server
>    -> _____ server
>    -> _____ client
>    -> _____ client

Not sure what you mean by EXTERNAL mechanism Chris.   Is this for the 
"plugin" stuff that we talked about in relationship to the API?   The 
Simeon clients and servers support 3 more mechanisms not listed here, 
with a couple of others in experimental development.   How do they fit?

> Names in [] are people who intend to participate in an interoperability
> demonstration.  Please volunteer for any of these, including ones which
> already have volunteers!
> 
> I propose we drop the SKEY mechanism from the draft status revision -- it
> should be obsoleted by an OTP mechanism anyway.  I propose we split the
> GSSAPI mechanism into a separate spec, as I think it will be much harder
> to demonstrate interoperable implementations of it due to its complexity.

I mostly concur.   SKEY should be replaced with an OTP version.  
GSSAPI is the most difficult to implement, but not by order of magnitudes 
or anything.   The biggest problem is the differences between GSSAPI v1 and
v2, and implementors playing fast and loose with mandatory GSSAPI 
"extensions".   These are interoperability problems in GSSAPI, not in SASL
though.

I would recommend splitting each of the mechanism definitions into separate 
documents, all subsidiary to a framework and mechanism registration document.

---  
Steve

Date: Fri, 16 Jan 1998 09:58:08 -0500 (EST)
From: Simon Spero <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Discusson List <[email-masked]>, [email-masked]
Subject: re: Call for volunteers: Moving SASL to draft status (fwd)
Sender: [email-masked]

I've actually heard requests for a raw K5 profile cloned as much as
possible from the K4 one.
BTW, I've done a K4 IMAP-> Cyrus in C; authentication only though for
legal reasons I'm supposed to do one in java but that may not be done
before the IETF.

Simon

Now available - The Freddy Hayek Kayak            | "Pass me another elf
Paddle Your Own Canoe! Be Rowed To Surfdom!       | Sergeant- this one's
>From The Taco Institute for Dyslexic Libertarians | split"
  Moments ago I had everything. Now, there's a cow in my nose - La Salla

Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Call for volunteers: Moving SASL to draft status (fwd)
To: Chris Newman <[email-masked]>
cc: IMAP Discusson List <[email-masked]>, [email-masked]
Sender: [email-masked]

Chris -

> (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
> which are specific interoperable profiles of GSSAPI mechanisms.

It would be quite acceptable -- and probably extremely desirable -- to do
this.  I am assuming two things: it allows Kerberos 5 to remain part of the
base SASL specification, and it blesses implementations that implement GSSAPI
only for Kerberos 5.

If you decide to do this, please do so immediately, because I plan to release
an imap-4.1 toolkit with GSSAPI to the world imminently.

From: Mark Wahl <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: Call for volunteers: Moving SASL to draft status 
Date: Thu, 15 Jan 1998 19:09:20 -0600
Sender: [email-masked]

> So we need to identify at least two clients and two
> servers for each of the following which provide interoperable
> authentication via SASL (send me email to volunteer for any of these or
> for any other protocols):

The Critical Angle LDAPv3 Client Library and Standalone Directory Server 
support negotiation via SASL of the CRAM-MD5 mechanism as described for use in 
LDAPv3.  They also support negotiation via SASL of the EXTERNAL mechanism 
when Start TLS has been used to negotiate SSL 3.0 with client authentication. 

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

From: Mark Wahl <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Mark Wahl <[email-masked]>, [email-masked]
Subject: Re: SASL & UTF8 
Date: Thu, 15 Jan 1998 19:07:41 -0600
Sender: [email-masked]

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.

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Call for volunteers: Moving SASL to draft status (fwd)
To: Mark Crispin <[email-masked]>
Cc: IMAP Discusson List <[email-masked]>, [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On the IMAP list Thu, 15 Jan 1998, Mark Crispin wrote:
> I am debugging a GSSAPI SASL mechanism in c-client now.  It will probably be
> in Pine 4.00.  Kerberos 5 is important to us.  So, I have a problem with
> GSSAPI not being in the base specification.

I'd actually like to keep GSSAPI in the base spec, but I don't see that
happening.  The GSSAPI specs themselves are so huge and complex that I
doubt they'll move past proposed anytime in the near future.  Holding SASL
(and by reference IMAP/ACAP/LDAPv3) at proposed status waiting for GSSAPI
to move to draft status is just not reasonable, IMHO. 

Would it be OK with you if we got the draft standard version of SASL and a
recycle at proposed of the GSSAPI mechanism in consecutive RFCs?  That
would allow us to fix any bugs in the GSSAPI mechanism.

> The main problem with the GSSAPI mechanism is that it is inadequately
> specified.  I don't want to say too much yet, since I'm not sure that my
> understanding is 100% correct.

I believe the problem is the basic GSSAPI assumption that the client and
server have the same mechanism "active."  This assumption fails in
practice and thus breaks interoperability.  I can see two ways to fix
this: (1) wait for SNEGO to go proposed and make that part of the GSSAPI
mechanism. (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
which are specific interoperable profiles of GSSAPI mechanisms.

Does this match your understanding?

		- Chris

Date: Thu, 15 Jan 1998 10:30:01 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Call for volunteers: Moving SASL to draft status
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

By IETF procedure, it will be possible to move SASL to draft status in
April.  In order to make it that soon, we need to complete some work in
the next 3 months to identify interoperable implementations.  (Personally,
I'd like to see SASL become the first IETF standard security protocol
other than APOP). 

IETF procedure gives the WG chair responsibility to document interoperable
implementations.  As SASL was an individual submission by John Myers, I'll
volunteer to document interoperable implementations.

So what does it mean to have two independent interoperable implementations
of SASL?

Here's my concept:

We need to demonstrate interoperability of SASL profiles (including
optional portions), SASL mechanisms, SASL authorization identity and SASL 
security layers.  So we need to identify at least two clients and two
servers for each of the following which provide interoperable
authentication via SASL (send me email to volunteer for any of these or
for any other protocols):
 * IMAP
   -> _____ server  [[email-masked]]
   -> CMU Cyrus server
   -> CMU Cyrus imtest client
   -> ESYS Simeon client
 * LDAPv3
   -> _____ server
   -> _____ server
   -> _____ client
   -> _____ client
 * ACAP
   -> CMU Cyrus server
   -> _____ server  [[email-masked]]
   -> _____ client  [[email-masked]]
   -> _____ client
 * KERBEROS_V4 mechanism (including security layer)
   -> _____ server
   -> CMU Cyrus server
   -> CMU Cyrus imtest client
   -> _____ client
 * CRAM-MD5 mechanism
   -> _____ server
   -> _____ server  [[email-masked]]
   -> _____ client  [[email-masked]]
   -> _____ client
 * EXTERNAL mechanism
   -> _____ server
   -> _____ server
   -> _____ client
   -> _____ client

Names in [] are people who intend to participate in an interoperability
demonstration.  Please volunteer for any of these, including ones which
already have volunteers!

I propose we drop the SKEY mechanism from the draft status revision -- it
should be obsoleted by an OTP mechanism anyway.  I propose we split the
GSSAPI mechanism into a separate spec, as I think it will be much harder
to demonstrate interoperable implementations of it due to its complexity.

		- Chris

Date: Thu, 15 Jan 1998 09:34:15 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: SASL & UTF8
To: Mark Wahl <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 14 Jan 1998, Mark Wahl wrote:
> 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.

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.

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

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]>
To: Chris Newman <[email-masked]>
cc: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Cc: Mark Wahl <[email-masked]>
Subject: Re: SASL & UTF8 
Date: Wed, 14 Jan 1998 14:46:32 -0600
Sender: [email-masked]

Chris Newman responds to Laurence Lundblade:

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

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.

Date: Wed, 14 Jan 1998 11:55:21 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: SASL & UTF8
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 14 Jan 1998, Laurence Lundblade wrote:
> 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)?

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

Date: Wed, 14 Jan 1998 10:13:10 -0800
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: SASL & UTF8
Sender: [email-masked]

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

Date: Tue, 13 Jan 1998 12:30:08 -0500
To: Chris Newman <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: regarding draft-myers-smtp-auth-08.txt
Cc: [email-masked]
Sender: [email-masked]

At 12:30 PM 1/8/98 -0800, Chris Newman wrote:
>On Thu, 8 Jan 1998, Jack De Winter wrote:
>> how would we encode that so that it could be passed as an authentication
>> token, seeing as it is perfectly valid according to the RFC822
>> construction rules for addr-spec?
>
>Good question.  I believe the SMTP AUTH spec should be revised to use the
>encoding described in section 5 of RFC 1891.

To be more specific:

5.  Additional parameters for RCPT and MAIL commands

   The extended RCPT and MAIL commands are issued by a client when it
   wishes to request a DSN from the server, under certain conditions,
   for a particular recipient.  The extended RCPT and MAIL commands are
   identical to the RCPT and MAIL commands defined in [1], except that
   one or more of the following parameters appear after the sender or
   recipient address, respectively.  The general syntax for extended
   SMTP commands is defined in [4].

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an emstp-value, they are not recognized as comment delimiters.

   The syntax for "esmtp-value" in [4] does not allow SP, "=", control
   characters, or characters outside the traditional ASCII range of 1-
   127 decimal to be transmitted in an esmtp-value.  Because the ENVID
   and ORCPT parameters may need to convey values outside this range,
   the esmtp-values for these parameters are encoded as "xtext".
   "xtext" is formally defined as follows:

     xtext = *( xchar / hexchar )

     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
          except for "+" and "=".

; "hexchar"s are intended to encode octets that cannot appear
; as ASCII characters within an esmtp-value.

     hexchar = ASCII "+" immediately followed by two upper case
          hexadecimal digits

When encoding an octet sequence as xtext:

+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
  MAY be encoded as itself.  (A CHAR in this range MAY instead be
  encoded as a "hexchar", at the implementor's discretion.)

+ ASCII CHARs that fall outside the range above must be encoded as
  "hexchar".

Is there any reason why we should use this approach instead of the
Quoted-Printable approach?  I know its a difference of whether or
not the character is a % or a +, but just curious.

Also, the 129 character limit, is that 129 characters after or before
any translation to hexchars are applied?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

From: Steve Hole <[email-masked]>
Date: Thu, 8 Jan 1998 15:06:12 -0700
To: [email-masked]
Subject: Re: re: Expiring Passwords
Sender: [email-masked]

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

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

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

Date: Thu, 08 Jan 1998 14:04:13 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Expiring Passwords
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 8 Jan 1998, Rob Earhart wrote:
>   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. 

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

Date: Thu, 8 Jan 1998 15:50:24 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: re: Expiring Passwords
Sender: [email-masked]

On Thu, 8 Jan 1998, Chris Newman wrote:
> 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.

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

> In addition, your pwchange spec is missing the error codes which are a
> 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.

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

  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"). 

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

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

> Not good enough -- if you mandate privacy, you have to mandate at least
> 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

Date: Thu, 08 Jan 1998 12:30:40 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: regarding draft-myers-smtp-auth-08.txt
To: Jack De Winter <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 8 Jan 1998, Jack De Winter wrote:
> how would we encode that so that it could be passed as an authentication
> token, seeing as it is perfectly valid according to the RFC822
> construction rules for addr-spec?

Good question.  I believe the SMTP AUTH spec should be revised to use the
encoding described in section 5 of RFC 1891.

		- Chris

Date: Thu, 08 Jan 1998 15:11:49 -0500
To: [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: regarding draft-myers-smtp-auth-08.txt
Sender: [email-masked]

a quick question regarding the inclusion of the AUTH=addr-spec to
the Mail From line.

My question centres around how to translate any characters that are in
the "not allowed list" (space, '=', and any of the control characters)
to something that can be placed in that line.

If you examine the definition for addr-spec, it boils down mainly to
atoms and words.  With an atom, the '=' is not covered in the specs,
and with the words, it devolves into atoms and quoted strings.

Given an example authentication id such as:

"name=\"Fred Flintstone\""@mynode.com

how would we encode that so that it could be passed as an authentication
token, seeing as it is perfectly valid according to the RFC822
construction rules for addr-spec?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

Date: Thu, 08 Jan 1998 10:58:21 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Expiring Passwords
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 8 Jan 1998, Rob Earhart wrote:
>   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). 

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.

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

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.

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

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

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

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

Date: Thu, 8 Jan 1998 12:06:25 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: re: Expiring Passwords
Sender: [email-masked]

On Wed, 7 Jan 1998, Chris Newman wrote:
> (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.

  Ah - okay.  (Sorry...)

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

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

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

  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.

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

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

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

  )Rob

Date: Thu, 08 Jan 1998 11:54:12 -0500
To: [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: regarding authentication trace information
Sender: [email-masked]

howdy, I just looked for an example of an additional trace header
for authentication information in messages.  I think it was in
Memphis where someone had mentioned that the Received header was
inflexable and any trace information for authentication would have
to be added in a new header.

Does anyone have any recollection of this or of anything that has
been done in this area?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

Date: Wed, 07 Jan 1998 15:22:12 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Expiring Passwords
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Tue, 6 Jan 1998, Rob Earhart wrote:
>   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.

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

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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2147343199-1678144658-884123463=:26325
Content-Type: TEXT/PLAIN; charset=US-ASCII

  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

---2147343199-1678144658-884123463=:26325
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-earhart-pcp-spec-00.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 

---2147343199-1678144658-884123463=:26325--

Date: Mon, 05 Jan 1998 12:09:50 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: re: Expiring Passwords
To: "Robert J. DuWors" <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 1 Jan 1998, Robert J. DuWors wrote:
> 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: John Haxby <[email-masked]>
Date: Mon, 5 Jan 1998 11:20:25 +0000
Subject: Re: Expiring Passwords
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Barry Leiba wrote:
>   On Mon, 29 Dec 97 16:44:07 -0800 Paul Hoffman / IMC wrote:
>   > 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
>
>   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.

Yup.  As we've already seen, if the credential changing mechanism isn't part
of the authentication layer then people will develop their own ad hoc
solutions in response to customer demand.  Sometimes these mechanisms are
good and provide good protection for the new credentials.  Sometimes the
mechanisms are rather weaker than the authentication mechanism and open up
unpleasant new loopholes.  This is self-evident.

What I, personally, would really really like to see is a secure credential
changing mechanism that does not use algorithms that are subject to export
licensing controls.  Everything I've thought of requires use of encryption
which automatically makes it subject to export licensing controls, either US
or UK ones.

--
John Haxby
OpenMail R&D

Date: Thu, 01 Jan 1998 20:15:18 -0500
To: Rob Earhart <[email-masked]>
From: "Robert J. DuWors" <[email-masked]>
Subject: re: Expiring Passwords
Cc: [email-masked]
Sender: [email-masked]

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