Subject: CRAM-MD5: definition of user

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 22 Nov 2001 10:16:52 -0700

In the grammar I defined <user> as a sequence of OCTETs. At issue is
the inclusion of NUL in the set of octets that make up the <user>.
In London we discussed including NUL, but there was no consensus
about whether this was a good thing or a bad thing.

There are two questions that need to be answered before we can
decide if using OCTET is appropriate:

1) Are there implementations that actively use NUL in
   CRAM-MD5 user names?

2) Are there implementations that would fail catestrophically
   if presented with a NUL in a user name?

--lyndon

To: [email-masked]
Subject: CRAM-MD5: definition of user
Organization: ACI Worldwide - Advanced Technology Group
Date: Thu, 22 Nov 2001 10:16:52 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

In the grammar I defined <user> as a sequence of OCTETs. At issue is
the inclusion of NUL in the set of octets that make up the <user>.
In London we discussed including NUL, but there was no consensus
about whether this was a good thing or a bad thing.

There are two questions that need to be answered before we can
decide if using OCTET is appropriate:

1) Are there implementations that actively use NUL in
   CRAM-MD5 user names?

2) Are there implementations that would fail catestrophically
   if presented with a NUL in a user name?

--lyndon

To: [email-masked]
Subject: draft-nerenberg-sasl-crammd5-00.txt
Organization: ACI Worldwide - Advanced Technology Group
Date: Tue, 20 Nov 2001 12:49:49 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

The initial version of the SASL CRAM-MD5 mechanism draft is
now available from the I-D repositories as

	draft-nerenberg-sasl-crammd5-00.txt

I have a couple of issues that I'll bring up in seperate
messages.

--lyndon

From: "Gordon Mohr" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Favored Base32 Alphabet?
Date: Thu, 15 Nov 2001 16:51:50 -0800
Sender: [email-masked]

[re-CCed to [email-masked]; originally sent...
To: "Simon Josefsson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]> ]

Thanks for the update, Simon -- it's a useful collection/naming of
the alphabets in use.

However, I notice that you haven't listed a Base32 alphabet that
was proposed in a number of the internationalized-domain-name (IDN)
ascii-compatible-encoding (ACE) drafts. This alphabet is the 
"Canonical" alphabet, without the letters 'L' and 'O' -- thus 
reaching '8' and '9' at the end.

Though not adopted by the IDN efforts, this alphabet struck me
as the most sensible choice for identifiers which might be
human transcibed, in whole or in fragments, and so my company
is using it in our current system. 

There's still time for us to change without too much pain, and 
I'm more interested in global convergence on a preferred 
alphabet, than any tiny advantages one or the other has.

So, what I'd really like is a clear statement in your draft 
that a particular alphabet is "preferred" for future protocol 
work, and that "Base32", when used alone, should be presumed
to mean a particular alphabet. Terming one alphabet the
"Canonical" alphabet almost does the trick; an explicit statement
that IETF documents are presumed to use this alphabet would
be even better.

One other comment: Since people often search for "Base32" and
"Base64" (no spaces), it would be helpful for these tokens
to appear in the draft/RFC text as well, to make sure it comes up
in search results.

- Gordon
____________________
Gordon Mohr, gojomo@
bitzi.com, Bitzi CTO
_ http://bitzi.com _

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Gordon Mohr" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 14, 2001 11:02 AM
Subject: Re: Favored Base32 Alphabet?

> "Gordon Mohr" <[email-masked]> writes:
> 
> > There are multiple Base32 alphabets floating about
> > in Internet-Drafts. For example,
> ...
> 
> This discussion contained some good points, I hope the updates version
> of this document includes them.  In particular, I've added a "URL and
> Filename safe" base64 alphabet, which seem to be used in certain
> places.  Comments welcome, my hope is to send this off to the IESG
> secretariat, to request RFC publication, before the end of the year
> (unless I hear something regarding the not-yet-formed SASL WG, which
> have expressed interest).
> 
> http://www.ietf.org/internet-drafts/draft-josefsson-base-encoding-03.txt
> 
> 

To: "Gordon Mohr" <[email-masked]>
Cc: <[email-masked]>, [email-masked]
Subject: Re: Favored Base32 Alphabet?
From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Nov 2001 20:02:21 +0100
Lines: 15
Sender: [email-masked]

"Gordon Mohr" <[email-masked]> writes:

> There are multiple Base32 alphabets floating about
> in Internet-Drafts. For example,
...

This discussion contained some good points, I hope the updates version
of this document includes them.  In particular, I've added a "URL and
Filename safe" base64 alphabet, which seem to be used in certain
places.  Comments welcome, my hope is to send this off to the IESG
secretariat, to request RFC publication, before the end of the year
(unless I hear something regarding the not-yet-formed SASL WG, which
have expressed interest).

http://www.ietf.org/internet-drafts/draft-josefsson-base-encoding-03.txt

Date: Sat, 10 Nov 2001 11:37:13 +1100
To: SASL WG <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: draft-naffah-cat-sasl-sm2-01.txt
Cc: Keith Burdis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

hi there,

David and I are pleased to announce the release of a new version of the SRP 
SM2 mechanism draft.

appendix B lists the changes introduced since the last draft.  these are:

* Changed SHOULD to MUST in Section 4.6.
* Added the Unsigned Integer type in Section 4.
* Added TTL indication in protocol exchange.
* Updated the examples to use the new SASL-SRP draft (#5).
* Updated the references.

in terms of code, Keith and I have just released version 0.8.10 of the 
cryptix SASL library (<http://sourceforge.net/projects/cryptix-sasl/>) 
which includes Java implementations of the latest SASL SRP and SM2 
mechanisms, as well as others, using Weltman's latest proposed API 
--draft-weltman-java-sasl-05.txt.

comments are welcome + cheers;
rsn

Date: Fri, 09 Nov 2001 10:57:38 -0800
From: Chris Newman <[email-masked]>
Subject: Re: OTP and C API
To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>, Rob Siemborski <[email-masked]>
Sender: [email-masked]

--On Friday, November 9, 2001 8:58 -0500 Ken Murchison <[email-masked]> 
wrote:
> So _none_ of this info should be echoed?  Can you give me an example of
> when NOECHOPROMPT would be used?  Do you agree that ECHOPROMPT is the
> correct callback for a OTP implementation?

NOECHOPROMPT means don't display what the user types (e.g. as with a 
regular password).  ECHOPROMPT means display what the user typed. 
ECHOPROMPT should be used with one-time passwords.

> Aren't the prompt and defresult taken care of by sasl_interact_t?

What do you mean by taken care of?  The API supports two approaches to 
getting data from the user, one returns with an error and you have to fill 
in sasl_interact_t (useful for event-driven programming), the other is 
callback based (simpler for threaded programming).  They need to have 
equivalent parameters.

> Why
> are they present in this callback, but not in sasl_getsimple_t or
> sasl_getsecret_t?

Becuase getsimple/getsecret are simpler calls.  Make the common case 
simple, make the uncommon case possible.

		- Chris

Date: Fri, 09 Nov 2001 08:58:20 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Chris Newman <[email-masked]>
CC: SASL mailing list <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: OTP and C API
Sender: [email-masked]

Chris Newman wrote:
> 
> --On Thursday, November 8, 2001 14:51 -0500 Ken Murchison <[email-masked]>
> wrote:
> > Is this a valid use of a sasl_chalprompt_t as described in the C API?
> 
> Yes, that's what it was intended for.

Great.

> > If so, what is the difference between SASL_CB_ECHOPROMPT and
> > SASL_CB_NOECHOPROMPT?  Does the latter mean that the challenge and/or
> > prompt and/or response is should not echoed?
> 
> Correct.

So _none_ of this info should be echoed?  Can you give me an example of
when NOECHOPROMPT would be used?  Do you agree that ECHOPROMPT is the
correct callback for a OTP implementation?

> > What is the purpose of the undocumented 'prompt' and 'defresult' params
> > in sasl_chalprompt_t?  Are these just leftover foo that were never
> > cleaned up?
> 
> It works like this:
> 
>       Challenge
> 
> prompt: ______________
>            defresult
> 
> Challenge is displayed up front.  Prompt appears before the user input
> field, and defresult is what goes in the user input field if the user just
> hits return with no input.

Aren't the prompt and defresult taken care of by sasl_interact_t?  Why
are they present in this callback, but not in sasl_getsimple_t or
sasl_getsecret_t?

Thanks,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 08 Nov 2001 14:01:18 -0800
From: Chris Newman <[email-masked]>
Subject: Re: OTP and C API
To: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Cc: Rob Siemborski <[email-masked]>
Sender: [email-masked]

--On Thursday, November 8, 2001 14:51 -0500 Ken Murchison <[email-masked]> 
wrote:
> Is this a valid use of a sasl_chalprompt_t as described in the C API?

Yes, that's what it was intended for.

> If so, what is the difference between SASL_CB_ECHOPROMPT and
> SASL_CB_NOECHOPROMPT?  Does the latter mean that the challenge and/or
> prompt and/or response is should not echoed?

Correct.

> What is the purpose of the undocumented 'prompt' and 'defresult' params
> in sasl_chalprompt_t?  Are these just leftover foo that were never
> cleaned up?

It works like this:

      Challenge

prompt: ______________
           defresult

Challenge is displayed up front.  Prompt appears before the user input 
field, and defresult is what goes in the user input field if the user just 
hits return with no input.

		- Chris

Date: Thu, 08 Nov 2001 14:51:12 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
CC: Chris Newman <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: OTP and C API
Sender: [email-masked]

Folks,

This is kind of a hybrid specification/API/implementation question, but
I think it is fair game for this list.

I'm in the process of implementing OTP support in CMU SASL.  RFC2444
states:

"Clients SHOULD support display of the OTP challenge to the user and
entry of an OTP in multi-word format.  Clients MAY also support direct
entry of the pass phrase and compute the "hex" or "word" response."

Rob Siemborski (CMU SASLv2 implementor) and I decided upon the following
design in the client-side of the SASL library for supporting both of
these options:

- If the application provides an _optional_ SASL_CB_ECHOPROMPT callback,
use this to display the server challenge and accept the one-time
password.

- Otherwise, use the _required_ SASL_CB_PASS callback to accept the
secret pass-phrase and generate the correct response internally.

My questions are these:

Is this a valid use of a sasl_chalprompt_t as described in the C API?

If so, what is the difference between SASL_CB_ECHOPROMPT and
SASL_CB_NOECHOPROMPT?  Does the latter mean that the challenge and/or
prompt and/or response is should not echoed?

What is the purpose of the undocumented 'prompt' and 'defresult' params
in sasl_chalprompt_t?  Are these just leftover foo that were never
cleaned up?

Thanks,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Sun, 4 Nov 2001 20:58:54 +0200
From: Keith Burdis <[email-masked]>
To: SASL WG <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>, Thomas Wu <[email-masked]>, [email-masked], [email-masked]
Subject: draft-burdis-cat-srp-sasl-05
Mail-Followup-To: Keith Burdis <[email-masked]>, SASL WG <[email-masked]>, Stephen Farrell <[email-masked]>, =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>, Thomas Wu <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Greetings

Raif and I are pleased to announce that we've released a new version of the
SRP SASL mechanism draft for comment. Here is the list of changes since the
previous version:

 - Added element size limits and changed SHOULD to MUST in Section 3.7.
      
 - Added "mandatory" and "maxbuffersize" options, and changed SHOULD, SHOULD
   NOT to MUST and MUST NOT in Section 4.2.
	     
 - The salt s is now sent with N and g.  The rationale is to make the
   exchanges, as well as the ordering of their elements, closer to [RFC-
   2945].
		       
 - Made sending the server evidence M2 conditional upon activation of
   Confidentiality Protection security service.  Now, the server MUST only
   send M2 if Confidentiality Protection is not activated, and MUST NOT if
   it is.
				    
 - Changed the order of elements when computing both M1 (client's evidence)
   and M2 (server's evidence) to reflect the informal SRP convention, which
   is to place any "extra" data for the hash at the end.
						 
 - Added a new section, "Replay detection sequence number counters" (Section
   7.3), that describes how these counters are used to provide replay
   detection.
							   
 - Added a new section, "SASL Profile Considerations," (Section 7.4) where
   various SASL profile related issues are covered.
								  
 - Updated the list of contributors.
								      
 - Changed the references to use symbolic names instead of numbers.

The one change that may need to be explained further is that of not sending
M2 when confidentiality protection has been negotiated. The reason for doing
this is to avoid an extra round trip when it is not needed. If
confidentatiality protection is active then the client can use the first
message it receives from the server in the security layer to determine
whether or not the server knows the session key. Additionally, if the server
does not know the session key, then it will not be able to decrypt any
messages sent by the client.

We would like to thank Stephen Farrell, Magnus Nyström and Thomas Wu for the
feedback that they provided on the previous draft. Many of the
clarifications and improvements can be attributed to their questions and
suggestions.

As always, comments are welcome.

  - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---