Subject: Comment on draft-ietf-cat-sasl-gssapi-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Apr 2001 10:36:18 -0600

1).

>4.    SPNEGO
...
>   Since SASL is capable of negotiating amongst GSSAPI mechansims, the
Typo: mechanisms
>   only reason for a server or client to support the "GSS-SPNEGO"
>   mechanism is to allow a policy of only using mechanisms below a
>   certain strength if those mechanism's negotiation is protected.  In
>   such a case, a client or server would only want to negotiate those
>   weaker mechnisms through SPNEGO.  In any case, there is no down-
Typo: mechanisms
>   negotiation security consideration with using the strongest
mechanism
>   and set of options the implementation supports, so for
>   interoperability that mechanism and set of options MUST be
negotiable
>   without using the "GSS-SPNEGO" mechanism.

2).

> 5.    Base32 encoding
...
>   Special processing is performed if fewer than 40 bits are available
...
>   the data is performed using the "=" character.  Since all base32
>   input is an integral number of octets, only the following cases can
>   arise: (1) the final quantum of encoding input is an integral
>   multiple of 40 bits; here, the final unit of encoded output will be
>   an integral multiple of 4 characters with no "=" padding, (2) the
"multiple of 8 characters"?

>   final quantum of encoding input is exactly 8 bits; here, the final
>   unit of encoded output will be two characters followed by six "="
>   padding characters, (3) the final quantum of encoding input is
>   exactly 16 bits; here, the final unit of encoded output will be four

>   characters followed by four "=" padding characters, (4) the final
>   quantum of encoding input is exactly 24 bits; here, the final unit
of
>   encoded output will be five characters followed by five"=" padding
"will be five characters followed by *three* "=""

>   characters, or (5) the final quantum of encoding input is exactly 32

>   bits; here, the final unit of encoded output will be seven
characters
>   followed by one "=" padding character.
>
>   Because it is used only for padding at the end of the data, the
>   occurrence of any "=" characters may be taken as evidence that the
>   end of the data has been reached (without truncation in transit).
No
>   such assurance is possible, however, when the number of octets
>   transmitted was a multiple of three and no "=" characters are
was a multiple of eight?

>   present.
>
>   Any characters outside of the base32 alphabet are to be ignored in
>   base32-encoded data.

I don't recall whether I've asked this question before, but I don't
understand the intention of the last sentence.
A generator MUST never generate text containing characters outside of
base32 alphabet. Any parser must not crash when parsing invalid input,
this is the question of quality of implementation.

3).

>6.1.  Client side of authentication protocol exchange
>
>   The client calls GSS_Init_sec_context, passing in
...
>   the fully qualified host name of the server.  If the client will be
>   requesting a security layer, it MUST also supply to the
>   GSS_Init_sec_context a mutual_req_flag of TRUE, a
replay_det_req_flag
>   of TRUE,

Your forgot sequencing flag ;-) [sequence_req_flag].

> and an integ_req_flag of TRUE.  If the client will be
>   requesting a security layer providing confidentiality protection, it

>   MUST also supply to the GSS_Init_sec_context a conf_req_flag of
TRUE.

As I wrote earlier, something like the following will completely satisfy
me:

"The client MAY specify other context service indicator flags".

4).

> 6.2.  Server side of authentication protocol exchange
...
>   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
...
>   output_message to the client in a challenge.  The server must then
>   pass the resulting response to GSS_Unwrap and interpret the first
>   octet of resulting cleartext as the bit-mask for the selected
>   security layer, the second through fourth octets as the netowrk byte

Typo: network
>   order maximum size output_message to send to the client, and the
>   remaining octets as the authorization identity.  The server must

Otherwise the document looks good :-).

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
All opinions are mine only, not of the TSA/ACI!
__________________________________________

---

From: Tony Hansen <[email-masked]>
Date: Mon, 30 Apr 2001 10:32:35 -0400

> this is the question of quality of implementation.

It means a generator is free to introduce other characters that make the
output more transportable, such as newlines and other white space.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Mon, 30 Apr 2001 10:32:35 -0400

Tony Hansen
	[email-masked]

Date: Mon, 30 Apr 2001 10:32:35 -0400
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comment on draft-ietf-cat-sasl-gssapi-04.txt
Sender: [email-masked]

	Tony Hansen
	[email-masked]

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-myers-saslrev-01.txt
Date: Mon, 30 Apr 2001 07:06:12 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: J. Myers
	Filename	: draft-myers-saslrev-01.txt
	Pages		: 14
	Date		: 27-Apr-01
	
SASL provides a method for adding authentication support with an
optional security layer to connection-based protocols.  It also
describes a structure for authentication mechanisms.  The result is
an abstraction layer between protocols and authentication mechanisms
such that any SASL-compatible authentication mechanism can be used
with any SASL-compatible protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-myers-saslrev-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-myers-saslrev-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-myers-saslrev-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-myers-saslrev-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-myers-saslrev-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 29 Apr 2001 10:36:18 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: Comment on draft-ietf-cat-sasl-gssapi-04.txt
Sender: [email-masked]

1).

...
Typo: mechanisms
Typo: mechanisms
mechanism
negotiable

2).

...
...

of

characters
No
was a multiple of eight?

3).

...
replay_det_req_flag

TRUE.

4).

...
...

Typo: network

Date: Wed, 25 Apr 2001 20:34:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: SASL GSSAPI to IETF Last Call
Sender: [email-masked]

John Gardiner Myers wrote:

> Alexey Melnikov wrote:
> > GSSAPI-KERBEROS probably list only one OID (new one).
>
> GSSAPI-KERBEROS lists both OIDs.

Ok.

> [skipped]
> > You are right. Can you add the following sentence than:
> > "Client willing to perform mutual authentication MUST pass GSS_C_MUTUAL_FLAG flag
> > to gss_init_sec_context call".
>
> That particular statement is vacuous.  I added statements requiring the
> client to pass additional flags corresponding to the security layers it
> will be requesting.

A sentence saying that "other flags MAY be specified" will make me happy.

> [skipped]

> > After looking through GSSAPI spec: GSS_C_REPLAY_FLAG & GSS_C_SEQUENCE_FLAG are
> > always discussed together, but a particular implementation may decide to implement
> > any one of them (or both).
> > I suggest that both client and server specify both flags when calling
> > gss_init_sec_context/gss_accept_sec_context.
>
> I don't see the need to mandate replay_det_req_flag.

Because some GSSAPI implementations support only replay detection, but not sequencing.

Alexey

Date: Wed, 25 Apr 2001 20:26:52 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Comments about draft-myers-saslrev-00.txt
Sender: [email-masked]

John Gardiner Myers wrote:

> Alexey Melnikov wrote:
> > 3). I think the existence of 6.2. (Server returns success with
> > additional data) and 6.3. (Multiple authentications) should be mentioned
> > in section 5, because people will use section 5 as a checklist:
>
> I'd really rather not go there.  Any implementation checklist needs to
> include all of section 6.  Section 5 should only mention things which
> affect the definition of protocol profiles.

But section 6 *does* affect a protocol profile.

> > 1). I remember there was a discussion during some IETF meeting about
> > adding initial server challenge (for example, CRAM-MD5 can take
> > advantage of that).
>
> This is a difficult change, as there are already two other optimizations
> optional to protocol profiles.  I'd prefer to just say we have enough.

Understood.

> [skipped]

> > 3). SASL spec should say how SASL security layer interacts with TLS
> > encryption. If SASL allows, for example, to negotiate DIGEST-MD5
> > confidentiality on top of TLS encryption (or other way around) then the
> > document should specify in which order they should be encoded/decoded.
>
> I disagree that we should specify this.  We can only get it wrong.
> Without additional wording, the ordering is obvious from the layering.

One of the reasons I've asked was because BEEP explicitly prohibits that.

Alexey

To: IETF-Announce: ;
Cc: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-04.txt
Date: Wed, 25 Apr 2001 07:14:48 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.

	Title		: SASL GSSAPI mechanisms
	Author(s)	: J. Myers
	Filename	: draft-ietf-cat-sasl-gssapi-04.txt
	Pages		: 13
	Date		: 24-Apr-01
	
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols.  This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-cat-sasl-gssapi-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-cat-sasl-gssapi-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Comments about draft-myers-saslrev-00.txt
Date: Tue, 24 Apr 2001 17:14:57 -0700
Organization: Netscape Communications Corporation
Lines: 93
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msB17437175FEA9B9E0B183853
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> 3). I think the existence of 6.2. (Server returns success with
> additional data) and 6.3. (Multiple authentications) should be mentioned
> in section 5, because people will use section 5 as a checklist:

I'd really rather not go there.  Any implementation checklist needs to
include all of section 6.  Section 5 should only mention things which
affect the definition of protocol profiles.

> 1). I remember there was a discussion during some IETF meeting about
> adding initial server challenge (for example, CRAM-MD5 can take
> advantage of that).

This is a difficult change, as there are already two other optimizations
optional to protocol profiles.  I'd prefer to just say we have enough.

> 2). DIGEST-MD5 has various number of authentication steps. Either SASL
> spec should explicitly allow that or DIGEST-MD5 spec should define 2
> separate mechanisms.

What exactly would you change?  I believe the spec already allows the
behavior of DIGEST-MD5.  Section 4.1 permits a server mechanism to
indicate successful completion after any authentication command or
client response.

The one issue I see is that 4.1 doesn't allow for the possibility of
returning additional data with successful completion.  I will clarify
this.

> 3). SASL spec should say how SASL security layer interacts with TLS
> encryption. If SASL allows, for example, to negotiate DIGEST-MD5
> confidentiality on top of TLS encryption (or other way around) then the
> document should specify in which order they should be encoded/decoded.

I disagree that we should specify this.  We can only get it wrong. 
Without additional wording, the ordering is obvious from the layering.
--------------msB17437175FEA9B9E0B183853
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msB17437175FEA9B9E0B183853--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: EXTERNAL security considerations
Date: Tue, 24 Apr 2001 16:33:38 -0700
Organization: Netscape Communications Corporation
Lines: 75
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms47A708235DC2849D61CEDEF3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> If EXTERNAL were detailed in another document, that document
> would have a section detailing security considerations
> related to the specification, implementation, and use of the
> mechanism.

Such a section would simply note "The EXTERNAL mechanism provides no
security protection; it is vulnerable to spoofing by either client or
server, active attack, and eavesdropping.  It should only be used when
such external security mechanisms are present and have sufficient
strength."  The section would then refer to the security considerations
section of the base SASL spec.

I will add the quoted text to base SASL spec.

Security considerations are best when they are in the form recommended
by section 9 of RFC 2316.  Each consideration should clearly state the
set of threats it addresses.
--------------ms47A708235DC2849D61CEDEF3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms47A708235DC2849D61CEDEF3--

Date: Tue, 24 Apr 2001 22:23:13 +1000
To: "Paul Leach" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: RE: SRP and SM2
Cc: "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 03:38 PM 4/22/01 -0700, Paul Leach wrote:
> >
> > As noted in section 7.4 of the SM2 draft, the "subsequent
> > authentication" described in RFC 2831 maps nicely on to the
> > SM2 exchange.  I suggest removing section 2.2 of RFC 2831 in
> > favour of SM2.
>
>Since there are many existing implementations of RFC 2831, why not
>rewrite SM2 to reuse the fast reconnect mechanism of RFC 2831 instead of
>telling everyone to drop it and switch to a different mechanism.

because SM2 is intended to be independent of any specific underlying 
mechanism.  while i can see how the fast reconnect mechanism of 2831 can be 
mapped to the SM2 session re-use, i fail to see the same for a mechanism 
such as SRP.

again as Keith noted, it should not be impossible to amend SRP --or for 
that matter any non-trivial SASL mechanism-- to improve its performance 
if/when it offers a confidentiality service.  the aim of SM2 is to do that, 
in a generic way, for all SASL mechanisms, including 2831 if its authors so 
desire.

>I think there should be compelling technical reasons to intruduce a
>change. 2831 in its current form is a mandatory to implement mechanism
>for LDAP, for example.
>
>Paul

cheers;
rsn

content-class: urn:content-classes:message
Subject: RE: SRP and SM2
Date: Sun, 22 Apr 2001 15:38:41 -0700
From: "Paul Leach" <[email-masked]>
To: "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> 
> As noted in section 7.4 of the SM2 draft, the "subsequent 
> authentication" described in RFC 2831 maps nicely on to the 
> SM2 exchange.  I suggest removing section 2.2 of RFC 2831 in 
> favour of SM2.

Since there are many existing implementations of RFC 2831, why not
rewrite SM2 to reuse the fast reconnect mechanism of RFC 2831 instead of
telling everyone to drop it and switch to a different mechanism.

I think there should be compelling technical reasons to intruduce a
change. 2831 in its current form is a mandatory to implement mechanism
for LDAP, for example.

Paul

Date: Sun, 22 Apr 2001 23:15:36 +0200
From: Keith Burdis <[email-masked]>
To: [email-masked]
Subject: Re: SRP and SM2
Mail-Followup-To: Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon 2001-03-26 (17:20), Chris Newman wrote:
> I think SRP fills a useful niche.  Relative to DIGEST-MD5, it trades speed 
> and management flexability for a significant improvement in wire and 
> server-side security.

What management flexibility tradeoffs are there in using SRP over
DIGEST-MD5?
 
> However, Jeff Schiller has made it quite clear that slow PK-based 
> algorithms (like SRP) need a fast restart mechanism before they're suitable 
> for the standards track.  If I understand the proposal correct, SM2 is the 
> fast-restart mechanism to go with SRP and thus SM2 needs to go to the 
> standards track before or at the same time that SRP does.  If we only look 
> at one of the two in the WG, it needs to be SM2 since that could have a 
> broader scope than just SRP.

You are correct. The slowest part of the SRP exchange is the generation of
the ephemeral keypairs by the client and the server. Using SRP with SM2
eliminates the need for new keypairs to be generated when a session is
reused, which leads to large speed improvements. I agree that a way to reuse
SRP sessions is definitely necessary before SRP can progress further.

SM2 is generally useful as a means of reusing sessions for any SASL
mechanism. However if it is not available as a standards track document then
something similar will have to be added to the SRP specification. The
downside of this is that we will have a different way of doing session reuse
for DIGEST-MD5 and SRP, and any new mechanisms will also have to specify a
means of reusing their sessions.

One possibility is to add SM2 to RFC 2222, but I doubt that anyone will like
that idea :-)

As noted in section 7.4 of the SM2 draft, the "subsequent authentication"
described in RFC 2831 maps nicely on to the SM2 exchange.  I suggest
removing section 2.2 of RFC 2831 in favour of SM2.

Comments?

> 		- Chris

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

Date: Thu, 19 Apr 2001 15:56:00 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Comments about draft-myers-saslrev-00.txt
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms3A5144ECB840AC72DCE189B3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> I was referencing the version you've sent in email message.

That has been superseded by the version in the internet-drafts
repository.
--------------ms3A5144ECB840AC72DCE189B3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms3A5144ECB840AC72DCE189B3--

Date: Thu, 19 Apr 2001 16:33:31 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Comments about draft-myers-saslrev-00.txt
Sender: [email-masked]

John Gardiner Myers wrote:

> Alexey Melnikov wrote:
> > >   describes how a protocol specifies such a command, defines several
> > ------------------------------------------------------------------^
> > only EXTERNAL left, this should be "a mechanism"
>
> That text does not appear in draft-myers-saslrev-00.txt.  Are you sure
> you're reviewing the right document?

I was referencing the version you've sent in email message.

Alexey

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Comments about draft-myers-saslrev-00.txt
Date: Thu, 19 Apr 2001 14:58:39 -0700
Organization: Netscape Communications Corporation
Lines: 64
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA67AF024AF6C4BB4020CFA82
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> >   describes how a protocol specifies such a command, defines several
> ------------------------------------------------------------------^
> only EXTERNAL left, this should be "a mechanism"

That text does not appear in draft-myers-saslrev-00.txt.  Are you sure
you're reviewing the right document?
--------------msA67AF024AF6C4BB4020CFA82
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msA67AF024AF6C4BB4020CFA82--

Date: Wed, 18 Apr 2001 22:38:12 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: Comments about draft-myers-saslrev-00.txt
Sender: [email-masked]

Mostly editorial stuff:

1).
>1.    Abstract
>
>   This document describes a method for adding authentication support
to
>   connection-based protocols.  To use this specification, a protocol
>   includes a command for identifying and authenticating a user to a
>   server and for optionally negotiating protection of subsequent
>   protocol interactions.  If its use is negotiated, a security layer
is
>   inserted between the protocol and the connection.  This document
>   describes how a protocol specifies such a command, defines several
------------------------------------------------------------------^
only EXTERNAL left, this should be "a mechanism"
>   mechanisms for use by the command, and defines the protocol used for

>   carrying a negotiated security layer over the connection.

2).
>4.3.  Security layers
[skipped]
>   The length of the security encoded data buffer must be no
>   larger than the maximum size that was either defined in the
mechanism
>   specification or negotiated by the other side during the
>   authentication protocol exchange.

Implementers warning: Several implementations don't check whether size
of encoded SASL block exceed their maximum acceptable block size.

3). I think the existence of 6.2. (Server returns success with
additional data) and 6.3. (Multiple authentications) should be mentioned
in section 5, because people will use section 5 as a checklist:

"Protocol profile SHOULD allow server to return additional data with
success (see section 6.2)."
  and
"Unless specified by protocol profile, multiple authentications are not
allowed (see section 6.3)"

4).
>7.    Registration procedures
>
>   Registration of a SASL mechanism is done by filling in the template
>   in section 7.4 and sending it in to [email-masked].  IANA has the
right
>   to reject obviously bogus registrations, but will perform no review
>   of clams made in the registration form.
-------^ claims?

More substantial comments:

1). I remember there was a discussion during some IETF meeting about
adding initial server challenge (for example, CRAM-MD5 can take
advantage of that).

2). DIGEST-MD5 has various number of authentication steps. Either SASL
spec should explicitly allow that or DIGEST-MD5 spec should define 2
separate mechanisms.

3). SASL spec should say how SASL security layer interacts with TLS
encryption. If SASL allows, for example, to negotiate DIGEST-MD5
confidentiality on top of TLS encryption (or other way around) then the
document should specify in which order they should be encoded/decoded.

Alexey

Date: Wed, 18 Apr 2001 18:26:29 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: EXTERNAL security considerations
Cc: [email-masked]
Sender: [email-masked]

If EXTERNAL were detailed in another document, that document
would have a section detailing security considerations
related to the specification, implementation, and use of the
mechanism.  Like ANONYMOUS and PLAIN, there are quite a number
of significant considerations to note (as you yourself have
noted in this thread).  In some cases, they may be quite
obvious to you and I, but we should not assume they are obvious
to all.

>We could put a statement similar to the requirement in RFC 2595 section
>6 that implementations MUST NOT use PLAIN unless a strong encryption
>layer is active or the implementation really wants to.

Such would address my primary concern.

Kurt

Date: Wed, 18 Apr 2001 18:08:27 -0700
From: John Gardiner Myers <[email-masked]>
Subject: CRAM-MD5: spaces in userids
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msEC3BE021EF23A7BCF14752C1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There have been reports of CRAM-MD5 server implementations which do not
correctly handle user names containing spaces.  The document should
mention that user names may contain spaces and server-side parsers need
to treat the last space as the separator between user name and digest.
--------------msEC3BE021EF23A7BCF14752C1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msEC3BE021EF23A7BCF14752C1--

Date: Wed, 18 Apr 2001 18:03:38 -0700
From: John Gardiner Myers <[email-masked]>
Subject: CRAM-MD5: specify the UTF-8 charset
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms8DCB3AE5FD7F139751019A9A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

CRAM-MD5 does not specify the charset used for the user name or shared
secret.  It should specify that they are both encoded in UTF-8.
--------------ms8DCB3AE5FD7F139751019A9A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms8DCB3AE5FD7F139751019A9A--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: EXTERNAL security considerations
Date: Wed, 18 Apr 2001 16:00:51 -0700
Organization: Netscape Communications Corporation
Lines: 139
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msFA25B72BB2BBA1C1939B0DF6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> I'm concerned that a box-in-the-middle could get a client to
> use EXTERNAL to believe it has authenticated to the intended
> server when it hasn't.  This could lead to the client then
> attempting operations which would be exposed to the
> box-in-the-middle.  The bottom line is that the client needs
> to be very careful of its use of EXTERNAL.

This problem is not specific to EXTERNAL--it also applies to CRAM-MD5
and any other mechanism which does not support mutual authentication. 
This is the attack that mutual authentication is designed to defend
against.

This all boils down to the fact that implementations need to determine
the security policy and then enforce it.  Clients that need to protect
against such attacks need to have a security policy that requires mutual
authentication.  As with integrity and confidentiality protection,
enforcing the security policy means prohibiting the use of mechanisms
which do not provide the required protections unless those protections
are provided by some service external to SASL.

For additional security considerations, the only thing I can think of
doing is to try to list a taxonomy of security features that
implementations may want to consider when choosing mechanisms.  Such a
list could never be exhaustive and I don't think it belongs in this
document.  The only other thing we could state is that EXTERNAL does not
itself provide any security protection; this point is obvious.

> I want to:
>         a) REQUIRE authentication (verification of information to
>           establish identity claimed),

We perhaps have different definitions of "authentication."  To me,
authentication is using information to associate a non empty set of
identities (usually with one primary identity) with a communication
peer.  Authentication by assertion (peer sends a message claiming peer
has identity X), while extremely weak, is still authentication.  The
ANONYMOUS mechanism uses this.

Once you bring in the word "verification," you are in the realm of
threat models and risk analysis.  You can't just talk about
verification, you have to talk about resistance to particular types of
attacks.

The IETF has identified particular types of attacks as being of special
concern: eavesdropping and replay.  All protocols must adequately
protect against such attacks.  man-in-the-middle attacks are not in this
set.

>         b) RECOMMEND easily spoofed information not be used.
> 
> The rational[e] is that EXTERNAL is an authentication mechanism
> and we should recommend reasonable secure uses of that mechanisms.
> That does not mean that it cannot be implemented or used contrary to
> these requirements.

We currently recommend use of EXTERNAL with TLS and IPsec, which are
reasonably secure.

We could put a statement similar to the requirement in RFC 2595 section
6 that implementations MUST NOT use PLAIN unless a strong encryption
layer is active or the implementation really wants to.  Such a statement
would be more likely to call attention to the possibility than to
discourage its use.

> Well, I note that many issues are left to profiles.  Including
> which mechanisms to mandate and/or recommended, how to manage
> authentication and authorization identities, etc.  The tenet
> is not pure.

These issues are entirely in the profile/implementation's area.  The
requirement for protocols to select and mandate particular mechanisms is
an IETF-wide policy.  The mechanisms themselves need not know about such
mandates.  They only need to know the security policy, which can be
given to them in a mechanism independent form.

Similarly, mechanisms only need to provide the authentication and
authorization identities.  It is up to the profile/implementation to
provide policy and interpretation.  In the SASL library APIs I've seen,
this separates well: the server provides the mechanism code with
callbacks for canonicalizing authenticaiton and authorization ids and
for applying the site's proxy authentication/access policy.
--------------msFA25B72BB2BBA1C1939B0DF6
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msFA25B72BB2BBA1C1939B0DF6--

Date: Tue, 17 Apr 2001 19:42:25 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzId in draft-myers-saslrev-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 06:50 PM 4/17/01, John Gardiner Myers wrote:

>I propose appending to the previous reword of section 4.2:
>
>As a client might not have the same information as the server,
>clients SHOULD NOT themselves try to derive authorization identities
>from auhentication identities when clients could instead transmit an
>authorization identity of the empty string.

This and your previous reword of 4.2 would adequately
address my concerns.

Date: Tue, 17 Apr 2001 19:02:29 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: EXTERNAL security considerations
Cc: [email-masked]
Sender: [email-masked]

At 06:27 PM 4/17/01, John Gardiner Myers wrote:
>"Kurt D. Zeilenga" wrote:
>> That is, the information used must be verified though
>> some external authentication process.  The information
>> should not be easily spoofed, such as the client's
>> IP address, the DNS name found by reverse lookup, or
>> information obtained from services operating at this
>> IP address (such as an RFC1413) authentication service.
>
>Even easily spoofed information can qualify as "authentication
>information".  Several merchants use things such as taxpayer ID numbers,
>phone numbers, and billing addresses as authentication information.
>
>You seem to be trying to impose some sort of minimum strength
>requirement for the information to be used by EXTERNAL.  What is the
>rationale for such a requirement?

I want to:
        a) REQUIRE authentication (verification of information to
          establish identity claimed),
        b) RECOMMEND easily spoofed information not be used.

The rational is that EXTERNAL is an authentication mechanism
and we should recommend reasonable secure uses of that mechanisms.
That does not mean that it cannot be implemented or used contrary to
these requirements.

>If a site believes that IP-based authentication in a particular
>situation conforms to their security policy, EXTERNAL would be the
>obvious SASL mechanism to use.  Why should the SASL specification
>prohibit this?  If SASL does prohibit this, would that have any chance
>of affecting the behavior of the site? 

My intent was not to prohibit this, but to recommend against
such uses.  As we design for the Internet, such recommendat

>> I actually suggest EXTERNAL be limited provided by other
>> means established by the application protocol profile.
>
>I can't parse the sentence.  The mechanism should be independent of the
>protocol profile, this is a fundamental tenet of SASL.

Well, I note that many issues are left to profiles.  Including
which mechanisms to mandate and/or recommended, how to manage
authentication and authorization identities, etc.  The tenet
is not pure.

>IPsec, for
>example, is unlikely to be mentioned in any protocol profile.
>
>> Without this, then it would be necessary to state additional
>> considerations in regards to the client's use of EXTERNAL.
>> In particular, the client cannot assume the source of
>> information used by server.
>
>Why would additional considerations be needed?  What are the problems?

I'm concerned that a box-in-the-middle could get a client to
use EXTERNAL to believe it has authenticated to the intended
server when it hasn't.  This could lead to the client then
attempting operations which would be exposed to the
box-in-the-middle.  The bottom line is that the client needs
to be very careful of its use of EXTERNAL.

Date: Tue, 17 Apr 2001 18:50:16 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: authzId in draft-myers-saslrev-00.txt
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms66371A67CD24EDD7D2E6AEB9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I propose appending to the previous reword of section 4.2:

As a client might not have the same information as the server,
clients SHOULD NOT themselves try to derive authorization identities
from auhentication identities when clients could instead transmit an
authorization identity of the empty string.
--------------ms66371A67CD24EDD7D2E6AEB9
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms66371A67CD24EDD7D2E6AEB9--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: EXTERNAL security considerations
Date: Tue, 17 Apr 2001 18:27:10 -0700
Organization: Netscape Communications Corporation
Lines: 92
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msFAA2A13635A5B46530A883B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> That is, the information used must be verified though
> some external authentication process.  The information
> should not be easily spoofed, such as the client's
> IP address, the DNS name found by reverse lookup, or
> information obtained from services operating at this
> IP address (such as an RFC1413) authentication service.

Even easily spoofed information can qualify as "authentication
information".  Several merchants use things such as taxpayer ID numbers,
phone numbers, and billing addresses as authentication information.

You seem to be trying to impose some sort of minimum strength
requirement for the information to be used by EXTERNAL.  What is the
rationale for such a requirement?

If a site believes that IP-based authentication in a particular
situation conforms to their security policy, EXTERNAL would be the
obvious SASL mechanism to use.  Why should the SASL specification
prohibit this?  If SASL does prohibit this, would that have any chance
of affecting the behavior of the site? 

> I actually suggest EXTERNAL be limited provided by other
> means established by the application protocol profile.

I can't parse the sentence.  The mechanism should be independent of the
protocol profile, this is a fundamental tenet of SASL.  IPsec, for
example, is unlikely to be mentioned in any protocol profile.

> Without this, then it would be necessary to state additional
> considerations in regards to the client's use of EXTERNAL.
> In particular, the client cannot assume the source of
> information used by server.

Why would additional considerations be needed?  What are the problems?
--------------msFAA2A13635A5B46530A883B1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msFAA2A13635A5B46530A883B1--

Date: Tue, 17 Apr 2001 18:22:30 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzId in draft-myers-saslrev-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 05:53 PM 4/17/01, John Gardiner Myers wrote:
>> I believe section 4.1 and 4.2 conflicts with section 5:
>>    In order to use this specification, a protocol definition
>>    MUST supply the following information:
>>         A specification of how the authorization identity passed
>>       from the client to the server is to be interpreted.
>
>How does this conflict?

Because the previous sections imply that its not up to the
protocol definition.

>> As far as I know, all existing SASL profiles leave authcId to
>> authzId mapping to implementations.
>
>This is inherently an implementation (or site) defined mapping.

Or profile specific.  That is, an application protocol TS
can define how the mapping is to occur if it chooses to.

>Have you seen implementors incorrectly sending non-empty authorization
>ids?

YES!  I see applications authentication user "foo" just stuff
"foo" in the authorization id (unless the client asserted something
different).  An authentication identity "foo" is not necessarily
equivalent to the authorization identity "foo".

>Does the following rewording of section 4.2 address your concern?

I think this goes to a long way to clarifying my concerns.
I still am concerned that clients developers might continue
to believe they can map an authentication identity to
authorization identity in the same manner that a server
does without a priori knowledge of that server's implementation
of said mapping.

>The identity derived from the client's
>authentication credentials is known as the "authentication identity".
>With any mechanism, transmitting an
>authorization identity of the empty string directs the server to derive
>an authorization identity from the client's authentication
>identity.
>
>If the authorization identity transmitted during the authentication
>protocol exchange is not the empty string, this is typically referred
>to as "proxy authentication".  This feature permits agents such as
>proxy servers to authenticate using their own credentials, yet request
>the access privileges of the identity for which they are proxying.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: authzId in draft-myers-saslrev-00.txt
Date: Tue, 17 Apr 2001 17:53:58 -0700
Organization: Netscape Communications Corporation
Lines: 138
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msCC2A7CE76DA9D512BB39CA9F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> First sentence of last paragraph of 4.1:
>    During the authentication protocol exchange, the mechanism performs
>    authentication, transmits an authorization identity (frequently known
>    as a userid) from the client to server, and negotiates the use of a
>    mechanism-specific security layer.
> 
> First paragraph of 4.2:
>    The authorization identity transmitted during the authentication
>    protocol exchange may be different from the identity derived from the
>    client's authentication credentials.  When the two are different,
>    this is typically referred to as "proxy authentication".
> 
> This implies a couple of things which I believe are incorrect.
> First, that the authorization identity is not optional.

With respect to this document, an authorization identity is indeed
always transmitted from the client to the server by the authentication
protocol exchange.  The transmitted authorization identity may be the
empty string and some mechanisms, such as CRAM-MD5, are only capable of
transmitting the empty string.

How a particular mechanism encodes an authorization identity of the
empty string is of no concern to this document.

Trying to distinguish cases of "no authorization identiy" and
"authorization identity of the empty string" is simply asking for
trouble.  DIGEST-MD5 has had interoperability problems caused by the
fact that it provides two different ways to encode an authorization
identity of the empty string.

> Second
> that it may be the same as the authentication identity in the
> same form as the authentication identity.

Indeed it can.  There is no reason to disallow this.  The client may not
even be able to determine what the identity in the user's credentials
is.

> If the client wishes to assert the authorization identity derived
> from the client's authentication credentials, no authorization
> identity SHOULD be provided.  The client MUST NOT assume that
> it can derive an authorization identity from its authentication
> credential to assert which server will recognize as being equivalent
> to the authorization identity which the server might derive from
> the client's authentication credential.

I oppose adding either statement.  The document clearly states how a
client is to assert the auathorization identity derived from the
credentials.

> I believe section 4.1 and 4.2 conflicts with section 5:
>    In order to use this specification, a protocol definition
>    MUST supply the following information:
>         A specification of how the authorization identity passed
>       from the client to the server is to be interpreted.

How does this conflict?

> As far as I know, all existing SASL profiles leave authcId to
> authzId mapping to implementations.

This is inherently an implementation (or site) defined mapping.

Have you seen implementors incorrectly sending non-empty authorization
ids?

Does the following rewording of section 4.2 address your concern?

The identity derived from the client's
authentication credentials is known as the "authentication identity".
With any mechanism, transmitting an
authorization identity of the empty string directs the server to derive
an authorization identity from the client's authentication
identity.

If the authorization identity transmitted during the authentication
protocol exchange is not the empty string, this is typically referred
to as "proxy authentication".  This feature permits agents such as
proxy servers to authenticate using their own credentials, yet request
the access privileges of the identity for which they are proxying.
--------------msCC2A7CE76DA9D512BB39CA9F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msCC2A7CE76DA9D512BB39CA9F--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: SASL GSSAPI to IETF Last Call
Date: Tue, 17 Apr 2001 17:15:48 -0700
Organization: Netscape Communications Corporation
Lines: 114
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms98F50395585CCDD63039C5DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> GSSAPI-KERBEROS probably list only one OID (new one).

GSSAPI-KERBEROS lists both OIDs.

> > I had (and have) no intent to allow for extensibility here.  You'll note
> > that the corresponding client-to-server message is not extensible.
> 
> Good.

I added a parentetical remark to the document.  I hope it doesn't make
things too confusing.

> Do you want to say anything about canceling GSSAPI exchange (I mean what peer
> should do if it receives cancellation request)?

Not particularly.  This is adequately covered by the GSSAPI spec.  The
description of the exchange is complicated enough as it is, I don't want
to have important interoperability and security points buried by obvious
housekeeping details.

> You are right. Can you add the following sentence than:
> "Client willing to perform mutual authentication MUST pass GSS_C_MUTUAL_FLAG flag
> to gss_init_sec_context call".

That particular statement is vacuous.  I added statements requiring the
client to pass additional flags corresponding to the security layers it
will be requesting.

> Actually you already wrote the paragraph that answer my question. I suggest you
> add something like the following:
> "When authentication exchange is complete both peers SHOULD check whether the
> required protection level was achieved."

I added something to this effect to the document.

> After looking through GSSAPI spec: GSS_C_REPLAY_FLAG & GSS_C_SEQUENCE_FLAG are
> always discussed together, but a particular implementation may decide to implement
> any one of them (or both).
> I suggest that both client and server specify both flags when calling
> gss_init_sec_context/gss_accept_sec_context.

I don't see the need to mandate replay_det_req_flag.

> I think there is a consensus that GSS_C_NO_CHANNEL_BINDINGS should be used.
> Mark Crispin also agrees with that.

Added.

> I suggest you mention that GSS_Wrap_size_limit can be
> used (if available in GSSAPI implementation) to determine what cleartext buffer
> size sender should use in order to produce ciphertext buffer not bigger than
> receiver's maximal buffer.

Added.

Revised document submitted to the I-D editor.
--------------ms98F50395585CCDD63039C5DE
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms98F50395585CCDD63039C5DE--

Date: Sun, 15 Apr 2001 20:50:16 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: EXTERNAL security considerations
Sender: [email-masked]

It seems to me that there some security considerations
which should be noted regarding the EXTERNAL mechanism.

First, I think:
   The server uses information, external to SASL, ...

is a bit too value.  I suggest:
   The server uses authenticated information, external to SASL,

That is, the information used must be verified though
some external authentication process.  The information
should not be easily spoofed, such as the client's
IP address, the DNS name found by reverse lookup, or
information obtained from services operating at this
IP address (such as an RFC1413) authentication service.

I actually suggest EXTERNAL be limited provided by other
means established by the application protocol profile.

Without this, then it would be necessary to state additional
considerations in regards to the client's use of EXTERNAL.
In particular, the client cannot assume the source of
information used by server.

Comments?

Kurt

Date: Sun, 15 Apr 2001 20:23:12 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: authzId in draft-myers-saslrev-00.txt
Sender: [email-masked]

Think we discussed this pre-publication I-D... maybe at IETF#50.
Anyways, just to ensure this issue gets discussed in regards to
the I-D...

There seems to be a bit of work needed regarding authorization identities
in SASL.

First sentence of last paragraph of 4.1:
   During the authentication protocol exchange, the mechanism performs
   authentication, transmits an authorization identity (frequently known
   as a userid) from the client to server, and negotiates the use of a
   mechanism-specific security layer.

First paragraph of 4.2:
   The authorization identity transmitted during the authentication
   protocol exchange may be different from the identity derived from the
   client's authentication credentials.  When the two are different,
   this is typically referred to as "proxy authentication". 

This implies a couple of things which I believe are incorrect.
First, that the authorization identity is not optional.  Second
that it may be the same as the authentication identity in the
same form as the authentication identity.

If the client wishes to assert the authorization identity derived
from the client's authentication credentials, no authorization
identity SHOULD be provided.  The client MUST NOT assume that
it can derive an authorization identity from its authentication
credential to assert which server will recognize as being equivalent
to the authorization identity which the server might derive from
the client's authentication credential.

I believe section 4.1 and 4.2 conflicts with section 5:
   In order to use this specification, a protocol definition
   MUST supply the following information:
	A specification of how the authorization identity passed
      from the client to the server is to be interpreted.

One cases where clients where it clear where the client cannot
derive an equivalent authorization identity from their credential
is when EXTERNAL is used.  The client does know exactly what the
credential is when using EXTERNAL.  It could be a TLS or IPSEC
credential or it could be something completely different (like
say RFC1413 based authentication (I hope not, but)).

A less obvious case is that SASL leaves the form of the authorization
identity AS WELL AS the authentication identity to authorization
identity mapping requirements to the application protocol's SASL
profile.  LDAP's profile specifically says:
   The method by which a server composes and validates an
   authorization identity from the authentication credentials
   supplied by a client is implementation-specific.

Hence, an LDAP client has no reliable means for deriving an
authorization identity from its credential which would be
guaranteed to match what the LDAP server would derive from the
credential.  This would lead to authorization failures.

As far as I know, all existing SASL profiles leave authcId to
authzId mapping to implementations.

I believe the specification needs to be clear that the authorization
identity should not be asserted unless the client wishes to assert
an authorization identity different (not just in form) from its
authentication identity.  In don't believe this clarification will
break anything as rfc2222 is pretty clear that the client may assert
empty to have the server derive the authorization identity from the
authentication identity.  I am not aware of any profile which says
empty authorization identities are disallowed.

Comments?

Kurt

Date: Fri, 6 Apr 2001 07:49:59 -0700 (PDT)
From: =?iso-2022-jp?B?RE1UGyRCNElNfTxUGyhC?= <[email-masked]>
TO: =?iso-2022-jp?B?aWV0Zi1zYXNsQGltYy5vcmc=?= <[email-masked]>
Subject: =?iso-2022-jp?B?RCBtYWdh?=
Sender: [email-masked]

$B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B  
  <$B%a!<%k$G9-9p$r<u?.$7$FKh7n(B5000$B1_$+$i(B3$BK|1_$N<}F~(B>
$B!!EPO?@bL@$O!!(Bhttp://www.e-lent.com/~fuu/oll_1.htm$B!!(B

  <$BH>2q0w@)3J0B#D#M9-9p!*0lK|?M$K@kEA$G$-$F(B5000$B1_6<0R$N@kEA8z2L(B>
$B!!?=9~%U%)!<%`!!(Bhttp://www.e-lent.com/~fuu/dmnc-s/dmnc.htm  
$B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B

$BFMA3$N%a!]%k?=$7LuM-$j$^$;$s!#6=L#$NL5$$J}!"5$J,$r32$5$l$?J}$O(B
$B$*<j?t$r$*3]$1$7$F?=$7LuM-$j$^$;$s$,:o=|$r$*4j$$$7$^$9!#(B
$B@?$K>!<j$r?=$7$^$7$F?=$7Lu$"$j$^$;$s$G$7$?!#(B

$B!VD6$*F@>pJs!*!W"-"-"-(B

$B!c!!9-9p(B1$B!!!d(B-----------------------------------------------------------

$B!V?M4V$NK\@-$H%M%C%H%o!<%/%S%8%M%9$NM;9g!W(B
$B$3$N$h$&$J$3$H$K$44X?4!&6=L#$,$*$"$j$G$7$g$&$+!#(B
$B%"!{%k!{7O!"=P2q$$7O$N%5%$%H$G%S%8%M%9$rE83+$7$h$&$H$$$&FbMF$G$9!#(B
$B$44X?4!&6=L#$,$*$"$j$G$7$?$i!"$*;~4V$,$*$"$j$G$7$?$i$40lFI$/$@$5$$!#(B
$B$b$A$m$sL5;k$7$F$$$?$@$$$F$b7k9=$G$9!#(B

$B%M%C%H%o!<%/%S%8%M%9$K$*$$$F!"!V0lHV$N>&:`!W$H8@$C$?$i2?$G$7$g$&$+!)(B
$B7r9/?)IJ!)2=>QIJ!)<cJV$j>&IJ!)!&!&!&$,0lHVNI$$$H$5$l$F$-$^$7$?!#(B
$B$7$+$7!"5f6K$N>&:`$O!|M_K>>&:`!|$G$9!#?)M_!"?gL2M_!"!{M_!*!*(B
$B!{M_$OC/$b$,I,$:;}$C$F$$$k$b$N$G$9!#(B

$B3'$5$s$b$4B8$8$N$H$*$j!"%$%s%?!<%M%C%H>e$G0lHV%"%/%;%9?t$NB?$$%5%$%H$O(B
$B%"!{%k!{7O!"=P2q$$7O$N%5%$%H$G$9!#!VNI$$!"0-$$$O$Y$D$H$7$F!W%"%/%;%9?t$N(B
$BB?$$%"!{%k!{!"=P2q$$7O(Betc$B$N%5%$%H$rM;9g$7$?#M#L#M$,%9%?!<%H$7$^$7$?!#(B
$B$9$4$$@*$$$K$J$k$H;W$$$^$9!#$=$7$F$@$l$G$b;22C$N$G$-$k#M#L#M$G$9!#(B
$B8=:_!"1o8NJg=8$,#47n#1F|$+$i%9%?!<%H$7$^$7$?!#(B
$B%a%s%P!<$K$J$C$F0BA4$J%5%$%H$r3Z$7$_$^$7$g$&!*!!<}F~$b(BGet$B!*(B
$B$^$:!"%a%s%P!<$K$J$k$?$a$NF~2q6b$O#1#2!$#0#0#01_$G$9!#(B
$B$=$7$FKh7n$N%*!<%H%7%C%W$O!"$?$C$?$N#3!$#0#0#01_$G$9!#(B
 
$B!VCK@-!"=w@-$rLd$o$:?M4V$NK\@-$H%M%C%H%o!<%/%S%8%M%9$NM;9g$G$9!W(B
$B$3$NOC$rJ9$$$F>P$$E>$2$F$$$^$7$?!#>P$$$J$,$i2T$2$l$P8@$&$3$H$J$7!*(B
$B$b$7!"6=L#$,M-$C$?$i!V%t%!%l%C%H4uK>!W$H$7$F%a!<%k$/$@$5$$!#(B
E$B%a!<%k!!!!!!([email-masked]
HP$B!&(BURL$B!!!!(Bhttp://www.tulip.at-bee.net/pinpoint/varyamazaki.htm

$BD9J8$H$*IU$-9g$$$$$?$@$-$^$7$F$"$j$,$H$&$4$6$$$^$7$?!#(B

=======================================================================

  $B:G8eKx$*FI$_$$$?$@$-@?$KM-Fq$&$4$6$$$^$7$?!#(B

content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5: Family of mechanisms?
Date: Tue, 3 Apr 2001 19:51:29 -0700
From: "Paul Leach" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "Chris Newman" <[email-masked]>, "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Remember, even though I thought it was a good idea, I still said it
should be in _V2_. I'm not in favor of slowing down getting to Draft
Standard.

All I was doing was responding to a comment that (as I read it) said
there was _no_ good reason to use a different hash function. I gave _a_
reason that I thought was consistent with the objective of not having
many options -- that if we didn't do something, a worse option would
come into being. I'm happy to let everyone decide for themselves how
_good_ a reason it is.

But I am going to look into why there are SHA1 options for the hash in
SSL...

Paul

content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5: Family of mechanisms?
Date: Tue, 3 Apr 2001 19:41:51 -0700
From: "Paul Leach" <[email-masked]>
To: "John Gardiner Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes, the US Gov't often doesn't directly participate in IETF, but there
are some of us who do participate who listen to our customers.

BTW: it is many more customers that just the US Gov't. Those other
customers often believe that the reason MD5 isn't FIPS certified is that
there is something wrong with it.

Paul

To: [email-masked]
Subject: Re: DIGEST-MD5: Family of mechanisms? 
Date: Tue, 03 Apr 2001 22:21:43 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

>I'll give one good reason to eventually support a different hash
>function: MD5 is not FIPS certified. And that by itself means that US
>Gov't will be very against it, or at least won't want to use it, and
>will likely cause some other password based protocol to come into
>existence which _isn't_ Digest. Thus frustrating the very thing Chris is
>trying to create: a uniform standard.

Just like to chime in here with my $0.02 about FIPS certification and
my experiences with it:

In general, those FIPS standards apply only to particular
_implementations_ that have gone through the certification process
(which is really lengthy and expensive).  I've only ever seen FIPS used
as a weak justification for not buying a particular product (and
FIPS-certified software crypto implementations are fairly rare).  I
know that occasionally it's applied to really big contract purchases,
but somehow people still manage to buy/use crypto products in the
Government that don't have a FIPS certification (and I really can't
imagine some new protocol coming into place just because MD5 doesn't
have a FIPS certification).  Mostly it's one of the billions of
government regulations that get ignored on a daily basis.

For example: No implementation of That Protocol That Might be Called
SSH is, AFAIK, FIPS-compliant, yet it's used in plenty of places in the
Government.  Same goes for OpenSSL.  I don't think that FIPS
certification or lack thereof should be used as a justification for
changing a protocol, and I agree with Chris that we shouldn't change
the protocol at this stage.

Note that despite my email address, I'm not a government employee, and
I'm not speaking for the government.

--Ken

Date: Tue, 03 Apr 2001 18:34:51 -0700
To: "Paul Leach" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: DIGEST-MD5: Family of mechanisms?
Cc: "Chris Newman" <[email-masked]>, "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:45 PM 4/3/01 -0700, Paul Leach wrote:
>I'll give one good reason to eventually support a different hash
>function: MD5 is not FIPS certified. And that by itself means that US
>Gov't will be very against it, or at least won't want to use it, and
>will likely cause some other password based protocol to come into
>existence which _isn't_ Digest. Thus frustrating the very thing Chris is
>trying to create: a uniform standard.

Well, using that argument, you'd also need to replace HMAC-MD5
as well....

I don't view the US Gov't as being very against MD5 (though
I agree that they might prefer SHA1).  I think one of the
biggest concerns of the gov'ts and other large organizations
with SASL and DIGEST-MD5 is that it hasn't yet reached
Draft Standard status.  I think getting what have to Draft
Standard in a timely fashion will remove a significant
hurdle in making these technologies becoming ubiquitous.

Kurt

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: DIGEST-MD5: Family of mechanisms?
Date: Tue, 03 Apr 2001 18:32:22 -0700
Organization: Netscape Communications Corporation
Lines: 10
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

Paul Leach wrote:
> Whereas if we add SHA-1 as an optional hash function in V2, there will
> be no such pressure.

This would be the tail wagging the dog.  We should not be causing
interoperability problems by introducing gratuitous features to please
irrational presumed cravings of an entity that hasn't even bothered to
participate in the IETF standardization process.

content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5: Family of mechanisms?
Date: Tue, 3 Apr 2001 17:45:44 -0700
From: "Paul Leach" <[email-masked]>
To: "Chris Newman" <[email-masked]>, "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I'll give one good reason to eventually support a different hash
function: MD5 is not FIPS certified. And that by itself means that US
Gov't will be very against it, or at least won't want to use it, and
will likely cause some other password based protocol to come into
existence which _isn't_ Digest. Thus frustrating the very thing Chris is
trying to create: a uniform standard.

Whereas if we add SHA-1 as an optional hash function in V2, there will
be no such pressure. We might even be able to minimize changes to the
spec by only using the low 128 bits of all hash results. But I'd have to
pass that by a crypto expert.

As for AES, recall that it needs more than 128 bits of key, so we'd need
to define some way of creating a bigger one.

Paul

Date: Tue, 03 Apr 2001 18:08:09 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Chris Newman <[email-masked]>
CC: Keith Burdis <[email-masked]>, [email-masked]
Subject: Re: DIGEST-MD5: Family of mechanisms?
Sender: [email-masked]

> It's very important that H(A1) be kept constant, which means "H" can't
> change from MD5.

Ok Chris, I am convinced. The next step, IMHO, is to remove *every reference*
to "H" because it doesn't add any value to the spec and even worse, it makes a
reader believe that there might be several different H functions.

Alexey

Date: Tue, 03 Apr 2001 16:44:07 -0700
From: Chris Newman <[email-masked]>
Subject: Re: DIGEST-MD5: Family of mechanisms?
To: Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

I am strongly opposed to any change in the hash algorithm for DIGEST-MD5. 
The last chance to change the hash function passed when RFC 2069 was 
approved by the IESG.  If you didn't speak up during that last call, too 
bad.

Further, I strongly discourage further creation of equivalent hash-based 
algorithms unless DIGEST-MD5 authentication is found to be fundamentally 
broken due to MD5.  We need _one_ interoperable hash-based mechanism to 
deploy widely.  We've already jerked implementors around with the CRAM-MD5 
-> DIGEST-MD5 shift to the detriment of deployment, so I'd want to see a 
_very_ good reason before doing it at this late stage.

It's very important that H(A1) be kept constant, which means "H" can't 
change from MD5.  People dislike deploying software where user passwords 
are stored in the clear in a database on the server.  People dislike 
shipping software which does so by default.  So the only way I see to 
overcome that deployment barrier is to make H(A1) ubiquitous (yes, H(A1) is 
plaintext equivalent, but only for the user/realm combination, so it's an 
improvement over password in the clear).

I have no objections to adding AES as an optional crypto mechanism.  Since 
the security layer is already an optional feature of DIGEST-MD5, it's much 
safer to tweak.  Given that AES is significantly faster than 3DES and has 
significantly more solid cryptanalysis than RC4, I'd prefer to deprecate 
3DES and RC4 in favor of AES, but to prevent a recycle at proposed we'll 
have to leave 3DES as the MTIM.  The drawback to adding AES, is that we 
have to demo two interoperable implementations prior to moving the 
resulting spec to draft.

		- Chris

Date: Mon, 02 Apr 2001 11:04:10 -0700
To: Joao Gazzoni <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL under OS/390
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

This list is generally used to discuss the SASL technical
specifications themselves and not the peculiarities of any
given implementation.  Your question would likely be more
appropriately addressed on a list specific to Cyrus SASL,
such as <[email-masked]> or even a SuSE
Linux specific forum (see http://www.suse.de/).

Kurt

From: Joao Gazzoni <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SASL under OS/390
Date: Mon, 2 Apr 2001 14:33:24 -0300 
Sender: [email-masked]

> Dear Sir,
> 
> I would like to run SASL APIs (Cyrus IMAP Server) under OS/390 hardware
> (IBM Mainframe, SuSe Linux s390).
> The compile procedure fails with "invalid system type -s390-unknown linux
> gnu".
> Have you a workaround to resolve this problem?
> 
> Thanks,
> 
> João