Subject: RE: Use of authorization identity

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 19 May 2001 08:59:37 +1000

At 04:13 PM 5/17/01 -0700, John Brezak wrote:
>In the case of LDAP that is UTF-8 for all of the authentication
>mechanisms. I'm looking at the protocol definitions, not the
>implementations.
>
>I guess I'm thinking that SASL provides a level of abstraction for
>applications to be able to use a collection of authentication mechanisms
>without the application having to know about the mechanisms. Clearly
>this isn't the case.

if i understood it correctly, John is arguing the following case:

1. any datum defined in a SASL mechanism that is to be used between the 
SASL client/server and its couterpart is supposed to be fully described, in 
terms of how it's encoded and should be interpreted, by the SASL mechanism.

2. the authorization-id, is an entity that is included in all mechanisms 
because it's defined in the SASL specs.  hence although some mechanisms do 
not, directly, make use of this entity they have to include it in their 
specifications (of the exchanges between client and server).

3. as soon as the authorization-id information has to be communicated to a 
module (proxy or otherwise), external to the SASL mechanism, the 
implementor of a mechanism has to know (a) what type this entity is; eg. 
string, numeric, octet-string, etc... and (b) how to encode/decode it; eg. 
length followed by bytes, utf-8 characters preceded by their length, 
der-encoded stream, etc...

4. even if this information is defined/specified by a SASL profile, and 
because more than one profile may use the same SASL mechanism, (a) the 
problem of interpreting such information remains, and (b) the designer of a 
SASL mechanism, as long as information similar in function/purpose to the 
authorization-id have not been fully specified in the SASL specs 
themselves, has the onus of doing it in the mechanism specification.

if i got it right so far i believe it makes more sense to fully specify 
this in the SASL specs rather than every time, and potentially with 
multiple forms/options, in mechanisms and profiles.  the disadvantage of 
imposing one way of encoding such information, and the cost of translating 
it to another form, is in my opinion a lesser evil.

a utf-8 character-sequence preceded by a one-octet designating the count of 
following characters would be appropriate for string literals.  or if the 
objective is to allow for more than just string literals, a big-endian 
octet-sequence preceded by a one-octet length should do the job.  in both 
cases the implied limit is 255 octets of meaningful data.

cheers;
rsn

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2001 3:47 PM
> > To: [email-masked]; John Brezak
> > Subject: RE: Use of authorization identity
> >
> >
> > Excerpts From "John Brezak" <[email-masked]>: Message
> > >What is that "known encoding"?
> >
> > Whatever your SASL library defines it as.
> >
> > -Tim
> >
> >
> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 May 2001 18:33:00 -0700

At 03:59 PM 5/18/01, Raif S. Naffah wrote:
>a utf-8 character-sequence preceded by a one-octet designating the count of following characters would be appropriate for string literals.  or if the objective is to allow for more than just string literals, a big-endian octet-sequence preceded by a one-octet length should do the job.  in both cases the implied limit is 255 octets of meaningful data.

Are we now redesigning SASL?

RFC 2222 did not restrict the encoding nor form of an authorization
identity.  It implicitly defers the form to profiles and encoding
to mechanisms.  While it might be appropriate to say that mechanisms
which provide a means to transfer authorization identities SHOULD
be capable of transfer authorization identities of any form and
that if a restrictive encoding is required that an escaping
method SHOULD be provided to allow the transfer of authorization
identities which contain octets outside those allowed by the
encoding.

SASL is designed to support authentication methods which may be
developed independently of their SASL mechanism.  Placing
restrictions upon what encoding mechanisms can support restricts
the kinds of methods for which mechanisms can be developed for.

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 19 May 2001 13:31:17 +1000

At 06:33 PM 5/18/01 -0700, Kurt D. Zeilenga wrote:
> >a utf-8 character-sequence preceded by a one-octet designating the count 
> of following characters would be appropriate for string literals.  or if 
> the objective is to allow for more than just string literals, a 
> big-endian octet-sequence preceded by a one-octet length should do the 
> job.  in both cases the implied limit is 255 octets of meaningful data.
>

the above paragraph offers a possible alternative to address an ambiguity 
in how authorization-id, and similar data, should be handled.  it is a 
consequence of a logical reasoning detailed in the message that included 
it.  now, if that reasoning is correct, we are then faced with the task of 
finding the best solution to address the problem.  on the other hand if 
it's flawed, then showing where it errs would be appreciated.

>to mechanisms.

and this is where the problem lies.  the problem is not how the 
authorization-id is to travel on the wire, rather how a mechanism 
(implementation) is to interpret it when set externally by a software 
module (proxy, protocol, or otherwise) from one end and hand it over on the 
other end to the external software module peer.

RFC2222 does not even say if the authorizxation-id is a string or 
otherwise.  it only states that it's the responsibility of a protocol to 
define how an authroization-id is to be "interpreted."

if now for example we have a mechanism M, and two protocoles P1 and P2 that 
use the same mechanism, but both specify the form of the authorization-id 
differently, say E1 for P1 and E2 for P2, then an implementor of M has, in 
order to have his/her implementation use-able by both P1 and P2, to provide 
methods such as: getAuthorizationIDasE1(), getAuthorizationIDasE2() and 
similar setxxx(...) methods.

Even if an implementor provides set and get methods for all known forms of 
authorization-id described by known profiles at the time, this won't 
garrantee the mechanism's suitability for a new profile that defines a 
different form for authorization identities.

>   While it might be appropriate to say that mechanisms

again, the problem is not how to transfer the information, but how to pass 
it to/from a mechanism.  it's iomportant to note too, that a mechanism has 
sometimes to "construct" an authorization identity from its own data if the 
information was not supplied to it in the first place.

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

     (last sentence in first paragraph of page 4 in RFC2222)

>the kinds of methods for which mechanisms can be developed for.

if those restrictions as you call it ensure inter-operability between (a) 
different implementations of mechanisms on one hand, and (b) different 
profiles and mechanisms, on the other, then they are beneficial and should 
be considered.

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 May 2001 22:14:19 -0700

At 08:31 PM 5/18/01, Raif S. Naffah wrote:
>and this is where the problem lies.  the problem is not how the authorization-id is to travel on the wire, rather how a mechanism (implementation) is to interpret it when set externally by a software module (proxy, protocol, or otherwise) from one end and hand it over on the other end to the external software module peer.

A mechanism (implementation) should not interpret it.  It should
just transfer it.  The profile implementation should interpret it.

>RFC2222 does not even say if the authorizxation-id is a string or otherwise.

which implies that it's arbitrary data.

>it only states that it's the responsibility of a protocol to define how an authroization-id is to be "interpreted."

Yes!  To SASL and its mechanisms, the authorization identity is
just a BLOB.

>if now for example we have a mechanism M, and two protocoles P1 and P2 that use the same mechanism, but both specify the form of the authorization-id differently, say E1 for P1 and E2 for P2, then an implementor of M has, in order to have his/her implementation use-able by both P1 and P2, to provide methods such as: getAuthorizationIDasE1(), getAuthorizationIDasE2() and similar setxxx(...) methods.

No.  E1 and E2 should be viewed by the mechanism implementation
as arbitrary octet strings which are encoded for transfer in M
as defined in M's specification.  If M doesn't support transfer
of arbitrary octet strings, then it might not be possible to
encode E1 or E2 for that transfer by that mechanism.  If a
mechanism cannot transfer arbitrary authorization identities,
then it's applicability is limited.

I believe it appropriate to say mechanisms SHOULD be capable
of transferring arbitrary authorization identity octet strings.
Many already do (EXTERNAL, GSSAPI, DIGEST-MD5).  If we fix
anything, we should fix mechanisms which cannot transfer
arbitrary authorization identities.

>Even if an implementor provides set and get methods for all known forms of authorization-id described by known profiles at the time,

An SASL API should support transfer of arbitrary authorization
identities as defined by each profile.  Only one get and one set
method required.

>this won't garrantee the mechanism's suitability for a new profile that defines a different form for authorization identities.

Any mechanism which places restricts upon the authorization
identities it can transfer limits its applicability.  A
mechanism which supports transfer of arbitrary authorization
identities can support any form defined by a profile.

>again, the problem is not how to transfer the information, but how to pass it to/from a mechanism.

Then it's not SASL's problem.   But I note that this really not
a problem, just an implementation issue which is easily resolved
by proper software layering.

>it's iomportant to note too, that a mechanism has sometimes to "construct" an authorization identity from its own data if the information was not supplied to it in the first place.

The "server" derives the authorization identity.  And as
authorization identities are profile specific, that derivation
should be done above the SASL software layer as this cannot
be done without knowledge of the profile's requirements.

>if those restrictions as you call it ensure inter-operability between (a) different implementations of mechanisms on one hand, and (b) different profiles and mechanisms, on the other, then they are beneficial and should be considered.

While I would like to see all mechanisms support transfer of
authorization identities of arbitrary form, unfortunately some
don't.  Restricting the mechanisms which do support transfer
of authorization identities of arbitrary form does not fix
anything, it only breaks those profiles who's form doesn't
fit into the restriction.

The best thing RFC2222bis can do is to encourage development
of mechanisms that can transfer whatever authorization identity
forms profiles specify.

        Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 17:24:40 -0700

> terms of how it's encoded and should be interpreted, by the SASL mechanism.

The encoding of data transferred between the client and the server is
defined by the SASL mechanism only.  Where the interpretation of data is
defined depends on its scope.  Data that are specific to a mechanism
(e.g. a challenge) have their interpretation defined by the SASL
mechanism.  Data that are specific to a profile are defined in the
profile and data that are specific to SASL are defined in the SASL
specification.

> specifications (of the exchanges between client and server).

Correct.  While some mechanisms omit mention of an authorization id in
their specification, for purposes of the base SASL specification they
always transmit an authorization id of the empty string.

> der-encoded stream, etc...

The interpretation of the authorization ID is multi-layered.  The base
type and interpretation of the authorization is (intended to be) defined
in the SASL specification.  Protocol profiles are then permitted to
further constrain authorization IDs, applying additional
protocol-specific semantics.  Finally, an implementation (site) will
apply even more constraints, assigning particular identifiers to
particular entities (usually people).

People seem to be confusing data with the encoding of that data.  The
number that is the lowest prime is not the same thing as the
representation of that number in decimal.

If SASL needed to transmit from client to server an integer vaule, say a
"bananna id", it need only specify that a bananna id is, say, an integer
value between 0 and 5928139.  It is then up to each SASL mechanism to
specify how that integer value is to be encoded for transfer: some would
use ASCII decimal encoding, others a fixed binary field in network byte
order, others would use ASN.1 BER.  SASL library implementations would
similarly need to specify how this value is represented across
programming API boundaries.

Similarly, it is sufficient for the SASL specification to specify that
the authorization id is a character string (with restrictions on the
characters permitted in the string).  It is the domain of SASL
mechanisms and implementations to define how such strings are encoded
across their boundaries.  While C APIs may prefer UTF-8, Java APIs will
prefer UTF-16.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 17:45:53 -0700

>identity.  It implicitly defers the form to profiles and encoding

RFC 2222 specifies the behavior of "an authorization identity of the
empty string".  This requirement to be able to represent the empty
string at least implies that it is a string of some sort.

> Yes!  To SASL and its mechanisms, the authorization identity is

A blob (or octet string) is incapable of carrying character data without
a specification of what the charset is.  Where do you propose this
specification be?

> arbitrary authorization identities.

DIGEST-MD5 is not capable of transferring arbitrary authorization
identity octet strings.  It is only capable of transferring
authorization identities that it can encode in UTF-8.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 May 2001 20:51:44 -0500

>a specification of what the charset is.  Where do you propose this

In the profile of the protocol.

>authorization identities that it can encode in UTF-8.

DIGEST-MD5 provides an escaping mechanism...

LDAPv3's profile allows arbitrary UTF-8, including NUL, in
the Authorization ID.  If NULs are present when DIGEST-MD5
is the mechanism, these NULs must be escaped.

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 19:22:19 -0700

> DIGEST-MD5 provides an escaping mechanism...

That mechanism is not capable of transferring arbitrary octet strings. 
How would you propose transferring a string containing a single 0xFF
octet?  The only way I can think of that conforms to the DIGEST-MD5
specification is to represent that octet as the U+00FF character and
then encode that character in UTF-8, resulting in 0xC3 0xBF.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 May 2001 22:05:00 -0500

>That mechanism is not capable of transferring arbitrary octet strings. 

I stand corrected.  I could have sworn that DIGEST-MD5 allowed
hex escaped values.  It seems you can only escape ASCII characters
in the range 0-127.  That is "\" followed by a zero octet is allowed.

>octet?

Hex escaping (as used in many other UTF-8 encodings):
        authzid="\ff"

>The only way I can think of that conforms to the DIGEST-MD5

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 23 May 2001 20:27:31 +1000

At 05:24 PM 5/22/01 -0700, John Gardiner Myers wrote:
>...

if this is the case, then there are no garranties that 2 different 
implementations can inter-operate: consider the case of a mechanism client 
in C and a mechanism server in Java!

the only solution i can see for interoperability of mechanisms is that the 
authorization-id be defined as a "possibly null octet-sequence."

cheers;
rsn

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 30 May 2001 16:25:57 -0700

> in C and a mechanism server in Java!

Nonsense.  Mechanism clients communicate with mechanism servers through
protocol, not through API boundaries.  The encoding over protocol would
be specified by the particular mechanism's specification (the mechanism
token then being further encoded over the protocol by the protocol
profile.)

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 30 May 2001 17:02:18 -0700

I believe the following are the changes necessary for each of the
proposed solutions to the authorization id problem:

Authorization ids are character strings:

* Add to SASL section 4.2 a specification that the authorization
identity is a character string.  NUL characters not permitted.

* Make SASL requirement 5.5 optional to the protocol profile.

Authorization ids are octet strings:

* Revert additions to SASL-GSSAPI and EXTERNAL, removing the
specification that the authorization id is in UTF-8.

* Extend DIGEST-MD5, OTP, SECURID, and PLAIN to carry non-UTF-8
authorization
ids.  OTP, SECURID, and PLAIN will likely remain incapable of carrying 0
octets in authorization ids.

* Add to the POP, IMAP, ACAP, etc. protocol profiles a specification
that the authorization ID is in UTF-8.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 May 2001 19:51:01 +1000

At 04:25 PM 5/30/01 -0700, John Gardiner Myers wrote:

>protocol, not through API boundaries....

of course.  but this is not the issue.  the issue, is how a protocole 
passes the contents of the authorization-id to a mechanism.

to wit, consider the case of Protocole P1 that uses mechanism M, and 
another Protocole P2 that uses the same mechanism; ie. M.  furthermore, P1 
mandates the use of UTF-8 as the encoding of its authorization-id, while 
P2, mandates ASCII.  since mechanisms have to provide, on one side of a 
communication channel an authorization-id, they should accept such a value 
from the other side at some time during their life-time; probably at their 
instantiation/start of a session.

now how does the API for such a mechanism look like?

should it be UTF-8, ASCII, both?  remember, we cannot just say it's a 
"string" since a C string does not mean the same thing as a Java string for 
example.  which also means that P1 cannot use inter-changeably a C 
implementation of M with a Java one (eg. through CORBA/IDL).

it's for this reason that i am arguing for a clear text in the 
specifications that state that Mechanisms should handle authorization-ids 
as possibly null octet sequences.

does this make sense?

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 May 2001 18:33:00 -0700

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 19 May 2001 13:31:17 +1000

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 May 2001 22:14:19 -0700

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 17:24:40 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 17:45:53 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 May 2001 20:51:44 -0500

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 22 May 2001 19:22:19 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 May 2001 22:05:00 -0500

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 23 May 2001 20:27:31 +1000

cheers;
rsn

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 30 May 2001 16:25:57 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 30 May 2001 17:02:18 -0700

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 May 2001 19:51:01 +1000

does this make sense?

cheers;
rsn

Date: Thu, 31 May 2001 19:51:01 +1000
To: John Gardiner Myers <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

does this make sense?

cheers;
rsn

Date: Wed, 30 May 2001 17:02:18 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

* Add to the POP, IMAP, ACAP, etc. protocol profiles a specification
that the authorization ID is in UTF-8.
--------------msBF9F97544D2C0D73FA79F416
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

--------------msBF9F97544D2C0D73FA79F416--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Wed, 30 May 2001 16:25:57 -0700
Organization: Netscape Communications Corporation
Lines: 67
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Nonsense.  Mechanism clients communicate with mechanism servers through
protocol, not through API boundaries.  The encoding over protocol would
be specified by the particular mechanism's specification (the mechanism
token then being further encoded over the protocol by the protocol
profile.)
--------------ms67AA6ECA6B1E64E1B7B3618B
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

--------------ms67AA6ECA6B1E64E1B7B3618B--

From: "Bill Tangren" <[email-masked]>
Organization: U.S. Naval Observatory
To: [email-masked]
Date: Fri, 25 May 2001 11:10:00 -0400
Subject: compiler errors
Reply-to: [email-masked]
Sender: [email-masked]

I get errors when I compile (do a make) 

Warning: This library needs some functionality provided by -ldes ...

I then get three errors, and the make stops at that point. I have seen 
this problem stated twice in your archives, but I have not seen any 
response to those questions posted. Please help.

Bill Tangren

Date: Wed, 23 May 2001 20:27:31 +1000
To: John Gardiner Myers <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

cheers;
rsn

Date: Tue, 22 May 2001 22:05:00 -0500
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

>then encode that character in UTF-8, resulting in 0xC3 0xBF.

Date: Tue, 22 May 2001 19:22:19 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

That mechanism is not capable of transferring arbitrary octet strings. 
How would you propose transferring a string containing a single 0xFF
octet?  The only way I can think of that conforms to the DIGEST-MD5
specification is to represent that octet as the U+00FF character and
then encode that character in UTF-8, resulting in 0xC3 0xBF.
--------------msB69343C2C7BB0590DD07C2CA
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

--------------msB69343C2C7BB0590DD07C2CA--

Date: Tue, 22 May 2001 20:51:44 -0500
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

Kurt

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Tue, 22 May 2001 17:45:53 -0700
Organization: Netscape Communications Corporation
Lines: 82
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

DIGEST-MD5 is not capable of transferring arbitrary authorization
identity octet strings.  It is only capable of transferring
authorization identities that it can encode in UTF-8.
--------------msCD1DB3C6B42F87ED307DAF23
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

--------------msCD1DB3C6B42F87ED307DAF23--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Tue, 22 May 2001 17:24:40 -0700
Organization: Netscape Communications Corporation
Lines: 116
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Similarly, it is sufficient for the SASL specification to specify that
the authorization id is a character string (with restrictions on the
characters permitted in the string).  It is the domain of SASL
mechanisms and implementations to define how such strings are encoded
across their boundaries.  While C APIs may prefer UTF-8, Java APIs will
prefer UTF-16.
--------------ms2E364D3027BA982049CCD91F
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

--------------ms2E364D3027BA982049CCD91F--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Tue, 22 May 2001 16:35:15 -0700
Organization: Netscape Communications Corporation
Lines: 114
NNTP-Posting-Host: 192.18.126.70
To: "Kurt D. Zeilenga" <[email-masked]>
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

"Kurt D. Zeilenga" wrote:
> >I did intend to have the authorization identity be a character string,
> >with NUL characters prohibited.
> 
> That may have been the intent, but RFC 2222 notes places no
> restriction upon authorization identities passed by mechanisms
> nor any restrictions upon form specified by the profile.

Clearly we have an open issue.
 
> Even adding a NUL restriction could break things as EXTERNAL,
> S/KEY, and GSSAPI (as defined in RFC 2222) allowed arbitrary
> authorization identities to be passed via SASL.

Do you know of any implementations which would be broken by the addition
of such a restriction?
 
> It seems that the latest I-D attempts to restrict authorization
> identities to UTF-8.  It says nothing about NUL characters
> and nothing about how to support encoding of the profile
> specific authorization identities.

The latest I-D was written with the same assumption that the
authorization identity was a character string.  It added a specification
of the charset used by the EXTERNAL mechanism, resolving an omission in
the original specification.

> Such restrictions are new to the I-D.  We should be very
> careful here to 1) avoid breaking things that work and 2)
> avoid adding new features which would cause this specification
> to have to reissued at Proposed.

Restricting the authorization id to a string and prohibiting NUL
characters is not adding a new feature.  If anything, it is removing a
feature that has been demonstrated to be noninteroperable.

> Now, we can argue until we're blue in the face about what
> should have been.  The questions for today is:
>         Does the lack of an authorization identity encoding
>         restriction upon authorization identities break SASL?
> 
> I content the answer is no.  SASL is not broken, it doesn't
> need to be fixed.

I disagree.  There exist widely deployed SASL mechanisms and
implementations which are incapable of carrying non-character-string
authorization identities.  Implementations which expect to use
non-character-string authorization identities will fail to interoperate
with such mechanisms and implementations.

A specification which permits two conforming implementations to fail to
interoperate (when such noninteroperation is not required by policy) is
broken.

> You can take this an objection to adding a UTF-8 restriction
> upon authorization identities in general or to EXTERNAL (as
> in the current SASL I-D).
--------------ms64389566A2788611A3E36726
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

--------------ms64389566A2788611A3E36726--

Date: Fri, 18 May 2001 22:14:19 -0700
To: "Raif S. Naffah" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: "John Brezak" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

        Kurt

Date: Sat, 19 May 2001 13:31:17 +1000
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: "John Brezak" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

cheers;
rsn

> >>> Whatever your SASL library defines it as.

Date: Fri, 18 May 2001 18:33:00 -0700
To: "Raif S. Naffah" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: "John Brezak" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Kurt

>>> Whatever your SASL library defines it as.

Date: Sat, 19 May 2001 08:59:37 +1000
To: "John Brezak" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

cheers;
rsn

> > Whatever your SASL library defines it as.

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Thu, 17 May 2001 16:13:28 -0700
From: "John Brezak" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> Whatever your SASL library defines it as.

Date: Thu, 17 May 2001 19:09:41 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

At 05:53 PM 5/17/01, John Gardiner Myers wrote:
>> For another protocol authzIds could be DER
>> encoded distinguished names.  In any case, each mechanism has
>> differing requirements on how authzIds need to be encoded.
>
>I did intend to have the authorization identity be a character string,
>with NUL characters prohibited.

That may have been the intent, but RFC 2222 notes places no
restriction upon authorization identities passed by mechanisms
nor any restrictions upon form specified by the profile.

Even adding a NUL restriction could break things as EXTERNAL,
S/KEY, and GSSAPI (as defined in RFC 2222) allowed arbitrary
authorization identities to be passed via SASL.

It seems that the latest I-D attempts to restrict authorization
identities to UTF-8.  It says nothing about NUL characters
and nothing about how to support encoding of the profile
specific authorization identities.

Such restrictions are new to the I-D.  We should be very
careful here to 1) avoid breaking things that work and 2)
avoid adding new features which would cause this specification
to have to reissued at Proposed.

>That assumption is made by the SASL libraries I am familiar with.

While that may be true, that's their limitation, not a general
limitation.  I know of multiple independently developed LDAP
implementations supporting SASL external with authorization
identities which can legally contain zero-valued octets.  (I
don't think anyone uses ids containing zero-valued octets in
their deployments, but these implementations do support it).

Now, we can argue until we're blue in the face about what
should have been.  The questions for today is:
        Does the lack of an authorization identity encoding
        restriction upon authorization identities break SASL?

I content the answer is no.  SASL is not broken, it doesn't
need to be fixed.
        
You can take this an objection to adding a UTF-8 restriction
upon authorization identities in general or to EXTERNAL (as
in the current SASL I-D).

Kurt

Date: Thu, 17 May 2001 19:23:02 -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:
> > A sentence saying that "other flags MAY be specified" will make me happy.
>
> I added a second paragraph to section 6:
>
> The implementation MAY set any GSSAPI flags or arguments not mentioned
> in htis specification as is necessary for the implementation ot enforce

"this"

> its security policy.

Great.

> > Because some GSSAPI implementations support only replay detection, but not sequencing.
>
> Really?  Which ones?  Sequencing is trival to implement on top of
> integrity protection.  It's far easier than replay detection.

I've double checked with GSSAPI author and he said that sequencing is supposed to be
superset of replay detection. So I withdraw my objection.

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
I don't represent the opinion of TSA/ACI!
__________________________________________

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Thu, 17 May 2001 17:53:39 -0700
Organization: Netscape Communications Corporation
Lines: 83
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

"Kurt D. Zeilenga" wrote:
> For another protocol authzIds could be DER
> encoded distinguished names.  In any case, each mechanism has
> differing requirements on how authzIds need to be encoded.

I did intend to have the authorization identity be a character string,
with NUL characters prohibited.  That assumption is made by the SASL
libraries I am familiar with.

The character encoding scheme used for transmitting this character
string is entirely in the domain of the mechanism.  Some may find UTF-8
more convenient, some may prefer UTF-16-be, some may require more
complex encodings.  DIGEST-MD5, for example, will use either ISO-8859-1
or UTF-8, depending on circumstances.  In a SASL implementation, it is
the job of the SASL mechanism code to convert from the
mechansim-specific encoding to the SASL implementation's canonical form,
just like it is the mechanism code's job to represent the authentication
identity in the SASL implementation's canonical form.

There is a limit to how far any standard can specify the interpretation
of an authorization identity, as an authorization identity (or "userid")
is fundamentally implementation-defined.

Similarly, a proxying policy, being a policy, is
implementation-defined.  It is a perfectly valid policy to prohibit all
users from proxying to any other users.
--------------msCA5D1E357C505D3F316E86E6
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

--------------msCA5D1E357C505D3F316E86E6--

Date: Thu, 17 May 2001 17:13:45 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: "Tim Martin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 03:12 PM 5/17/01, John Brezak wrote:
>I see that RFC-2829 specifies that authz_id names are to be UTF-8.

That's for LDAP.  For another protocol authzIds could be DER
encoded distinguished names.  In any case, each mechanism has
differing requirements on how authzIds need to be encoded.
So, for example, when a client wants to specify some authzId
(which should be in form described in the appropriate
profile), the API encodes it as necessary for that mechanism.
For mechanisms which transfer the authzId as an octet string
(such as RFC 2222 - EXTERNAL), no encoding is necessary.  For
mechanisms (such as RFC2831 - DIGEST-MD5) which transfer the
authzId in some restricted encoding (such as a subset of UTF-8),
then the authzId provided by the application must be reencoded
as needed.  For example, if the LDAPv3 authzId was
        dn:CN=Joe,O="FOO BAR"

then the DIGEST-MD5 authzId field would look like:
        authzid="dn:CN=Joe,O=\22FOO BAR\22"

The biggest authzid problem I see currently is mechanisms
overly restricting the encoding.  For example, some mechanisms
restrict the authzid to "visible" UTF-8 and provide no
escaping mechanism.  This disallows valid (per the profile's
authorization identity form) from being transferred by the
mechanism.  Each mechanism should define the algorithm to
encode an arbitrary data containing the profile specific
authzid.

Kurt

>> From: Tim Martin [mailto:[email-masked]] 
>> Sent: Thursday, May 17, 2001 2:57 PM
>> To: John Brezak; [email-masked]
>> >I disagree. If the point is for the application to not have 
>> to know how 
>> >to deal with different authentication mechanisms, why should the 
>> >application have to know what character encoding the 
>> authz_id is ing to 
>> >be in based on what authentication mechanism is selected?
>> 
>> The SASL library knows about the specific mechanism encodings and 
>> can convert the authzid's to a known encoding before asking the 
>> application "can <authid> proxy as <authzid>?"
>> 
>> -Tim
>> 
>> 
>> 

From: [email-masked]
Date: Thu, 17 May 2001 16:57:15 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: RE: Use of authorization identity
Sender: [email-masked]

Excerpts From "John Brezak" <[email-masked]>:
Message
>without the application having to know about the mechanisms. Clearly

I think you're missing a level of abstraction. Typically you have a layer between the application and the mechanisms that has knowledge of how specific mechanisms work. This layer can present a uniform view to the application. In the case of the authzid it can convert the string from whatever form the mechanism used to utf8 when passing the string to the application.

-Tim

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Thu, 17 May 2001 15:12:13 -0700
From: "John Brezak" <[email-masked]>
To: "Tim Martin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I see that RFC-2829 specifies that authz_id names are to be UTF-8.

> From: Tim Martin [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2001 2:57 PM
> To: John Brezak; [email-masked]
> >I disagree. If the point is for the application to not have 
> to know how 
> >to deal with different authentication mechanisms, why should the 
> >application have to know what character encoding the 
> authz_id is ing to 
> >be in based on what authentication mechanism is selected?
> 
> The SASL library knows about the specific mechanism encodings and 
> can convert the authzid's to a known encoding before asking the 
> application "can <authid> proxy as <authzid>?"
> 
> -Tim
> 
> 
> 

From: [email-masked]
Date: Thu, 17 May 2001 15:46:47 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: RE: Use of authorization identity
Sender: [email-masked]

Excerpts From "John Brezak" <[email-masked]>:
Message

-Tim

Date: Thu, 17 May 2001 14:57:08 -0700
From: Tim Martin <[email-masked]>
Subject: RE: Use of authorization identity
To: [email-masked], [email-masked]
Sender: [email-masked]

Excerpts From "John Brezak" <[email-masked]>:
Message
>I disagree. If the point is for the application to not have to know
>how to deal with different authentication mechanisms, why should the
>application have to know what character encoding the authz_id is ing
>to be in based on what authentication mechanism is selected?

The SASL library knows about the specific mechanism encodings and 
can convert the authzid's to a known encoding before asking the 
application "can <authid> proxy as <authzid>?"

-Tim

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Wed, 16 May 2001 22:50:17 -0700
From: "John Brezak" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "Tony Hansen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 8:35 PM
> To: John Brezak
> Cc: Tony Hansen; [email-masked]
> At 05:55 PM 5/16/01, John Brezak wrote:
> >Is the description of the intended use a requirement?
> 
> In general, no.
> 
> >In this case do
> >all applications that are to employ SASL authentication required to 
> >support proxy?
> 
> A profile MUST specify how to interpret an authorization 
> identity asserted using the proxy mechanism.  However, a 
> profile need not mandate that all implementations of that 
> profile support the proxy mechanism.  If a profile however 
> does mandate such, then all applications implementing that 
> profile MUST implement it.

So something like this language needs to be in the SASL I-D passing the
requirement to application profiles describing the use of SASL.

> 
> >If so, then how is proxy to be used in existing applications 
> that are 
> >using SASL - LDAP, IMAP?
> 
> For LDAPv3, SASL proxy is to be used as described in RFC 
> 2829. For other protocols, it's to be used as described by 
> their SASL profiles.

I'll have a look at LDAP. Others?

> 
> >I still maintain that the encoding of the authz_id must be 
> independent 
> >of authentication mechanism for an application to be able to 
> make use 
> >of it.
> 
> Currently, the encoding of the authzId is mechanism specific 
> but the form is application protocol specific.  Each 
> mechanism should describe the means for encoding any set of 
> octets representing an authorization identity.  Otherwise, 
> one could not assert a BER encoded X.500(4th edition) 
> distinguished name (if that was what application protocol 
> specified as the form).
> 
> Some mechanisms are capable of transferring the identity as
> an arbitrary string of octets.  Requiring such mechanisms to 
> encode the identity using UTF-8 is unnecessary work.  Other 
> mechanisms may already be limited to UTF-8 and hence it may 
> be appropriate for them to encode the identity into some 
> UTF-8 string.  However, the exact encoding used must take 
> into account restrictions of the mechanisms syntax.  For 
> example, DIGEST-MD5 syntax requires different escaping 
> requirements necessary to support the mechanism.
> 
> I believe it would be unwise at this stage in the 
> standardization of SASL to place new restrictions upon the 
> encoding/forms of identities previously left to mechanisms 
> and/or profiles.

I disagree. If the point is for the application to not have to know
how to deal with different authentication mechanisms, why should the
application have to know what character encoding the authz_id is going
to be in based on what authentication mechanism is selected?

This does not allow new authentication mechanisms to be swapped into
an application with modification of the app. A benefit of SASL is to
make authentication easy and mechanism independent for applications.

> Kurt

Date: Wed, 16 May 2001 20:35:12 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: "Tony Hansen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:55 PM 5/16/01, John Brezak wrote:
>Is the description of the intended use a requirement?

In general, no.

>In this case do
>all applications that are to employ SASL authentication required to
>support proxy?

A profile MUST specify how to interpret an authorization identity
asserted using the proxy mechanism.  However, a profile need not
mandate that all implementations of that profile support the
proxy mechanism.  If a profile however does mandate such, then
all applications implementing that profile MUST implement it.

>If so, then how is proxy to be used in existing applications that are
>using SASL - LDAP, IMAP?

For LDAPv3, SASL proxy is to be used as described in RFC 2829.
For other protocols, it's to be used as described by their
SASL profiles.

>I still maintain that the encoding of the authz_id must be independent
>of authentication mechanism for an application to be able to make use of
>it.

Currently, the encoding of the authzId is mechanism specific
but the form is application protocol specific.  Each mechanism
should describe the means for encoding any set of octets
representing an authorization identity.  Otherwise, one could
not assert a BER encoded X.500(4th edition) distinguished name
(if that was what application protocol specified as the form).

Some mechanisms are capable of transferring the identity as
an arbitrary string of octets.  Requiring such mechanisms to
encode the identity using UTF-8 is unnecessary work.  Other
mechanisms may already be limited to UTF-8 and hence it
may be appropriate for them to encode the identity into some
UTF-8 string.  However, the exact encoding used must take
into account restrictions of the mechanisms syntax.  For
example, DIGEST-MD5 syntax requires different escaping
requirements necessary to support the mechanism.

I believe it would be unwise at this stage in the standardization
of SASL to place new restrictions upon the encoding/forms of
identities previously left to mechanisms and/or profiles.

Kurt

Date: Wed, 16 May 2001 19:31:05 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: <[email-masked]>
Sender: [email-masked]

At 06:28 PM 5/16/01, John Brezak wrote:
>Is there a LDAP SASL profile published that describes how the SASL proxy
>feature is to be used?

The LDAP SASL profile (RFC2251,RFC2829) says how the authorization
identity is to be interpreted.  It does not state how a server is
to determine the validity of the authorization identity assertion.
That an area left to implementations and/or future standardization.

>What about the other SASL applications?

All SASL profiles should specify how to interpret the authorization
identity.  Some may leave everything, including form, to implementations
others may be quite specific not only as to the form but exactly how
the authorization identity assertion is to validated.  (Most take the
former approach).

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Wed, 16 May 2001 17:55:55 -0700
From: "John Brezak" <[email-masked]>
To: "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Is the description of the intended use a requirement? In this case do
all applications that are to employ SASL authentication required to
support proxy?

If so, then how is proxy to be used in existing applications that are
using SASL - LDAP, IMAP?

I still maintain that the encoding of the authz_id must be independent
of authentication mechanism for an application to be able to make use of
it.

> From: Tony Hansen [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 5:39 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Use of authorization identity
> 
> 
> I must forcefully disagree. A statement like "for use by the 
> application protocol" is absolutely useless. If I can't write 
> a client application that uses a protocol feature and know 
> what it's going to do, then the "feature" is instead a 
> misfeature. So SASL MUST give a description of the definition 
> of the field and its intended use.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> John Brezak wrote:
> > 
> > I would suggest that the SASL I-D should not infer any use for the 
> > authz_id for protocols employing SASL. How an application protocol 
> > makes use of the SASL authz_id should be left entirely up to the 
> > application.
> > 
> > Also the encoding should be consistent between all SASL 
> authentication 
> > methods - UTF-8, otherwise the application needs to know too much 
> > about the authentication method used to make use of it.
> > 
> > I would recommend removing any suggest use - like proxy 
> from the I-D 
> > and simply specify that it its use is application define 
> and specify 
> > the encoded format. A generic purpose like "for use by the 
> application 
> > protocol. Also that it is optionally provided by the client.
> > 
> > Is an application using SASL required to utilize the authz_id?
> > 
> > From: Kurt D. Zeilenga [mailto:[email-masked]]
> > Sent: Wednesday, May 16, 2001 8:55 AM
> > To: John Brezak
> > Cc: [email-masked]
> > Subject: Re: Use of authorization identity
> > 
> > At 04:01 PM 5/15/01, John Brezak wrote:
> > 
> > >In the SASL I-D (and RFC2222) there is mention of an authorization 
> > >identity. In the I-D there is clarification of its 
> intended use for 
> > >proxies.
> > >
> > >What errors can should be returned in these cases:
> > >
> > >1) authenticated user is not allowed to operate as the authz id
> > >2) authz id doesn't exist (should you interpret this as the empty 
> > >authz
> > id?)
> > 
> > It's my opinion that both should result in a "bad authorization" 
> > error. Note that each protocol which makes use of SASL has 
> to define 
> > its own mechanism for handling this.  However, I believe it 
> would be 
> > generally inappropriate for a non-existent authzId to be 
> interpreted 
> > as an empty authzid.  Of course, the handling of authzIds 
> is protocol 
> > specific (see item 5 of section 4).
> > 
> > >Or should the SASL protocol just pass this information 
> along to the 
> > >application protocol that would then handle the error cases?
> > 
> > SASL has no means for transferring error information between peers, 
> > that is left to the protocol making use of SASL (see item 3 
> of section 
> > 4).
> > 
> > >But in this case I can't see how the proxy part applies in 
> a general 
> > >sense. The application protocol may not distinguish between an 
> > >authentication identity and authorization identity. It may 
> not even 
> > >be valid in this case.
> > 
> > Well, I would say that SASL provides a framework for one to add 
> > proxying capabilities to protocols (LDAP is an example of a 
> protocol 
> > which made no distinction between these identities until SASL was 
> > added).  It may not make sense to add proxying support and in such 
> > cases one can easily write a SASL profile which says that 
> > authorization identities shall be empty and interpreted as implying 
> > the authorization associated with the authentication identity.  I, 
> > however, would suggest something more like "support for non-empty 
> > authorization identity in this protocol is not defined 
> currently but 
> > may be defined by extension".
> 

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Wed, 16 May 2001 18:28:01 -0700
From: "John Brezak" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Is there a LDAP SASL profile published that describes how the SASL proxy
feature is to be used? What about the other SASL applications?

There needs to be wording in the I-D stating that the use of the SASL
proxy feature is optional in applications that use SASL and its use is
described outside of the I-D.

I still maintain that the encoding (UTF-8) of the authz_id needs to be
independent of the authentication mechanism.

> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 6:17 PM
> To: John Brezak
> Cc: [email-masked]
> SASL only provides a framework for application protocols to 
> implement authentication and security services.  These 
> services include proxy authorization and data protection. 
> It's up to the application protocol's SASL profile to detail 
> how it makes use of SASL, including how the proxy 
> authorization feature is to used (if at all).  I believe SASL 
> appropriately leaves the form of the authorization identity 
> to the application protocol's SASL profile.  Some application 
> protocols have very specific requirements in this area (such 
> as those of LDAP), others have no specific requirements 
> (BEEP) and hence defer the specification to others.
> 
> Kurt
> 
> 

Date: Wed, 16 May 2001 18:16:36 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: <[email-masked]>
Sender: [email-masked]

SASL only provides a framework for application protocols to
implement authentication and security services.  These services
include proxy authorization and data protection. It's up
to the application protocol's SASL profile to detail how it
makes use of SASL, including how the proxy authorization feature
is to used (if at all).  I believe SASL appropriately leaves
the form of the authorization identity to the application
protocol's SASL profile.  Some application protocols
have very specific requirements in this area (such as those
of LDAP), others have no specific requirements (BEEP) and
hence defer the specification to others.

Kurt

Date: Wed, 16 May 2001 20:38:48 -0400
From: Tony Hansen <[email-masked]>
To: John Brezak <[email-masked]>
CC: [email-masked]
Subject: Re: Use of authorization identity
Sender: [email-masked]

I must forcefully disagree. A statement like "for use by the application
protocol" is absolutely useless. If I can't write a client application
that uses a protocol feature and know what it's going to do, then the
"feature" is instead a misfeature. So SASL MUST give a description of
the definition of the field and its intended use.

	Tony Hansen
	[email-masked]

John Brezak wrote:
> 
> I would suggest that the SASL I-D should not infer any use for the
> authz_id for protocols employing SASL. How an application protocol makes
> use of the SASL authz_id should be left entirely up to the application.
> 
> Also the encoding should be consistent between all SASL authentication
> methods - UTF-8, otherwise the application needs to know too much about
> the authentication method used to make use of it.
> 
> I would recommend removing any suggest use - like proxy from the I-D and
> simply specify that it its use is application define and specify the
> encoded format. A generic purpose like "for use by the application
> protocol. Also that it is optionally provided by the client.
> 
> Is an application using SASL required to utilize the authz_id?
> 
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 8:55 AM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Use of authorization identity
> 
> At 04:01 PM 5/15/01, John Brezak wrote:
> 
> >In the SASL I-D (and RFC2222) there is mention of an authorization
> >identity. In the I-D there is clarification of its intended use for
> >proxies.
> >
> >What errors can should be returned in these cases:
> >
> >1) authenticated user is not allowed to operate as the authz id
> >2) authz id doesn't exist (should you interpret this as the empty authz
> id?)
> 
> It's my opinion that both should result in a "bad authorization" error.
> Note that each protocol which makes use of SASL has to define its own
> mechanism for handling this.  However, I believe it would be generally
> inappropriate for a non-existent authzId to be interpreted as an empty
> authzid.  Of course, the handling of authzIds is protocol specific (see
> item 5 of section 4).
> 
> >Or should the SASL protocol just pass this information along to the
> >application protocol that would then handle the error cases?
> 
> SASL has no means for transferring error information between peers, that
> is left to the protocol making use of SASL (see item 3 of section 4).
> 
> >But in this case I can't see how the proxy part applies in a general
> >sense. The application protocol may not distinguish between an
> >authentication identity and authorization identity. It may not even be
> >valid in this case.
> 
> Well, I would say that SASL provides a framework for one to add proxying
> capabilities to protocols (LDAP is an example of a protocol which made
> no distinction between these identities until SASL was added).  It may
> not make sense to add proxying support and in such cases one can easily
> write a SASL profile which says that authorization identities shall be
> empty and interpreted as implying the authorization associated with the
> authentication identity.  I, however, would suggest something more like
> "support for non-empty authorization identity in this protocol is not
> defined currently but may be defined by extension".

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Wed, 16 May 2001 16:04:27 -0700
From: "John Brezak" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 3:50 PM
> To: John Brezak
> Cc: [email-masked]
> At 02:06 PM 5/16/01, John Brezak wrote:
> >I would suggest that the SASL I-D should not infer any use for the 
> >authz_id for protocols employing SASL.
> 
> It doesn't.  rfc2222 (and this I-D) says the protocol's profile
> provides:
>    5. A specification of how the authorization identity 
> passed from the
>       client to the server is to be interpreted.
> 
> That is, SASL doesn't say how a non-empty authzId is to be 
> interpreted. (SASL does say how an absent/empty authzId is to 
> be interpreted)

It does - it suggests that the application protocol use it for an
identity
that the authenticated user perform the application specific operation
as.

> 
> >How an application protocol makes
> >use of the SASL authz_id should be left entirely up to the 
> application.
> 
> The specification of the application protocol may choose to 
> do so... or it may not.  Examples of both can be found [BEEP 
> and LDAP, respectively].

Does this mean that the proxy in the I-D is not required?

> 
> >Also the encoding should be consistent between all SASL 
> authentication 
> >methods - UTF-8, otherwise the application needs to know too 
> much about 
> >the authentication method used to make use of it.
> 
> Currently SASL itself places no restrictions upon the 
> encoding/form of the authorization identity.  Some mechanisms 
> do.  I would suggest that SASL itself not place restrictions 
> upon the encoding/form of the authorization identity as this 
> would limit the types of mechanisms which SASL can support.
> 
> Obviously if an application protocol and a mechanism have 
> incompatible requirements upon the authzId, they cannot be 
> used together to support authorization proxying.

You need to keep the encoding of the name form consistent between
authentication protocols. Otherwise the application will have to
know what protocol was used in the authentication and apply the
correct format conversion function. If SASL is suppose to abstract
the authentication negotiation process, any outputs from that process
to be used by the application should also be abstracted to a common
encoding form.

> 
> >I would recommend removing any suggest use - like proxy from the I-D 
> >and simply specify that it its use is application define and specify 
> >the encoded format.
> 
> I disagree.  I believe it is every important for the I-D to 
> describe the intended use of the field.  Proxy authorization 
> is the intended use.

I read it as requiring protocols to implement proxy behaviors as
specified
in the SASL I-D.

> 
> >A generic purpose like "for use by the application
> >protocol. Also that it is optionally provided by the client.
> 
> This field is not a meaningless BLOB and application 
> protocols (and applications) should not use it for unintended 
> purposes.  The use of this field is to allow a client to 
> assert an authorization identity different from the 
> authentication identity.

It is an application defined authz identity. The proxy should be
worded as an example use of such an authz_id, but shouldn't imply
that all applications employing SASL MUST implement a proxy mechanism.

> 
> >Is an application using SASL required to utilize the authz_id?
> 
> No.  A client only needs to assert an authzId when the user 
> desires to take on rights of an authorization identity 
> different from those which the user's authentication identity 
> implies. That is, a client which is not using the proxy 
> feature should specify an empty authzId.

What about protocols that have no notion of an identity split as you
are describing? Does any application using SASL have to now build in
this behavior?

Use of SASL shouldn't require the ability of an application to deal with
this proxy mechanism. What if the application already had its own
"proxy" mechanism?

Date: Wed, 16 May 2001 15:49:56 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Use of authorization identity
Cc: <[email-masked]>
Sender: [email-masked]

At 02:06 PM 5/16/01, John Brezak wrote:
>I would suggest that the SASL I-D should not infer any use for the
>authz_id for protocols employing SASL.

It doesn't.  rfc2222 (and this I-D) says the protocol's profile
provides:
   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

That is, SASL doesn't say how a non-empty authzId is to be interpreted.
(SASL does say how an absent/empty authzId is to be interpreted)

>How an application protocol makes
>use of the SASL authz_id should be left entirely up to the application.

The specification of the application protocol may choose to do
so... or it may not.  Examples of both can be found [BEEP and LDAP,
respectively].

>Also the encoding should be consistent between all SASL authentication
>methods - UTF-8, otherwise the application needs to know too much about
>the authentication method used to make use of it.

Currently SASL itself places no restrictions upon the encoding/form of
the authorization identity.  Some mechanisms do.  I would suggest
that SASL itself not place restrictions upon the encoding/form of the
authorization identity as this would limit the types of mechanisms
which SASL can support.

Obviously if an application protocol and a mechanism have incompatible
requirements upon the authzId, they cannot be used together to support
authorization proxying.

>I would recommend removing any suggest use - like proxy from the I-D and
>simply specify that it its use is application define and specify the
>encoded format.

I disagree.  I believe it is every important for the I-D to describe
the intended use of the field.  Proxy authorization is the intended
use.

>A generic purpose like "for use by the application
>protocol. Also that it is optionally provided by the client.

This field is not a meaningless BLOB and application protocols
(and applications) should not use it for unintended purposes.  The
use of this field is to allow a client to assert an authorization
identity different from the authentication identity.

>Is an application using SASL required to utilize the authz_id?

No.  A client only needs to assert an authzId when the user
desires to take on rights of an authorization identity different
from those which the user's authentication identity implies.
That is, a client which is not using the proxy feature should
specify an empty authzId.

Content-Class: urn:content-classes:message
Subject: RE: Use of authorization identity
Date: Wed, 16 May 2001 14:06:19 -0700
From: "John Brezak" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I would suggest that the SASL I-D should not infer any use for the
authz_id for protocols employing SASL. How an application protocol makes
use of the SASL authz_id should be left entirely up to the application.

Also the encoding should be consistent between all SASL authentication
methods - UTF-8, otherwise the application needs to know too much about
the authentication method used to make use of it.

I would recommend removing any suggest use - like proxy from the I-D and
simply specify that it its use is application define and specify the
encoded format. A generic purpose like "for use by the application
protocol. Also that it is optionally provided by the client.

Is an application using SASL required to utilize the authz_id?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2001 8:55 AM
To: John Brezak
Cc: [email-masked]
Subject: Re: Use of authorization identity

At 04:01 PM 5/15/01, John Brezak wrote:

>In the SASL I-D (and RFC2222) there is mention of an authorization 
>identity. In the I-D there is clarification of its intended use for 
>proxies.
>
>What errors can should be returned in these cases:
>
>1) authenticated user is not allowed to operate as the authz id
>2) authz id doesn't exist (should you interpret this as the empty authz
id?) 

It's my opinion that both should result in a "bad authorization" error.
Note that each protocol which makes use of SASL has to define its own
mechanism for handling this.  However, I believe it would be generally
inappropriate for a non-existent authzId to be interpreted as an empty
authzid.  Of course, the handling of authzIds is protocol specific (see
item 5 of section 4).

>Or should the SASL protocol just pass this information along to the 
>application protocol that would then handle the error cases?

SASL has no means for transferring error information between peers, that
is left to the protocol making use of SASL (see item 3 of section 4).

>But in this case I can't see how the proxy part applies in a general 
>sense. The application protocol may not distinguish between an 
>authentication identity and authorization identity. It may not even be 
>valid in this case.

Well, I would say that SASL provides a framework for one to add proxying
capabilities to protocols (LDAP is an example of a protocol which made
no distinction between these identities until SASL was added).  It may
not make sense to add proxying support and in such cases one can easily
write a SASL profile which says that authorization identities shall be
empty and interpreted as implying the authorization associated with the
authentication identity.  I, however, would suggest something more like
"support for non-empty authorization identity in this protocol is not
defined currently but may be defined by extension".

Date: Wed, 16 May 2001 08:54:49 -0700
To: "John Brezak" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: <[email-masked]>
Sender: [email-masked]

At 04:01 PM 5/15/01, John Brezak wrote:

>In the SASL I-D (and RFC2222) there is mention of an authorization identity. In the I-D there is clarification of its intended use for proxies.
>
>What errors can should be returned in these cases: 
>
>1) authenticated user is not allowed to operate as the authz id 
>2) authz id doesn't exist (should you interpret this as the empty authz id?) 

It's my opinion that both should result in a "bad authorization"
error.  Note that each protocol which makes use of SASL has to
define its own mechanism for handling this.  However, I believe
it would be generally inappropriate for a non-existent authzId to
be interpreted as an empty authzid.  Of course, the handling of
authzIds is protocol specific (see item 5 of section 4).

>Or should the SASL protocol just pass this information along to the application protocol that would then handle the error cases?

SASL has no means for transferring error information between peers,
that is left to the protocol making use of SASL (see item 3 of
section 4).

>But in this case I can't see how the proxy part applies in a general sense. The application protocol may not distinguish between an authentication identity and authorization identity. It may not even be valid in this case.

Well, I would say that SASL provides a framework for one to add
proxying capabilities to protocols (LDAP is an example of a protocol
which made no distinction between these identities until SASL was
added).  It may not make sense to add proxying support and in such
cases one can easily write a SASL profile which says that
authorization identities shall be empty and interpreted as implying
the authorization associated with the authentication identity.  I,
however, would suggest something more like "support for non-empty
authorization identity in this protocol is not defined currently
but may be defined by extension".

Content-Class: urn:content-classes:message
Subject: Use of authorization identity
Date: Tue, 15 May 2001 16:01:55 -0700
From: "John Brezak" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0DD93.09450F5A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

In the SASL I-D (and RFC2222) there is mention of an authorization
identity. In the I-D there is clarification of its intended use for
proxies.

What errors can should be returned in these cases:

1) authenticated user is not allowed to operate as the authz id
2) authz id doesn't exist (should you interpret this as the empty authz
id?)

Or should the SASL protocol just pass this information along to the
application protocol that would then handle the error cases?

But in this case I can't see how the proxy part applies in a general
sense. The application protocol may not distinguish between an
authentication identity and authorization identity. It may not even be
valid in this case.

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-936-2602
One Microsoft Way
Redmond, WA 98052

------_=_NextPart_001_01C0DD93.09450F5A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4688.0">
<TITLE>Use of authorization identity</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">In the SASL I-D (and RFC2222) there is =
mention of an authorization identity. In the I-D there is clarification =
of its intended use for proxies.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What errors can should be returned in =
these cases:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1) authenticated user is not allowed to =
operate as the authz id</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">2) authz id doesn't exist (should you =
interpret this as the empty authz id?)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Or should the SASL protocol just pass =
this information along to the application protocol that would then =
handle the error cases?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But in this case I can't see how the =
proxy part applies in a general sense. The application protocol may not =
distinguish between an authentication identity and authorization =
identity. It may not even be valid in this case.</FONT></P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Tahoma">=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Tahoma">John =
Brezak&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN =
LANG=3D"fr-ca"></SPAN></FONT><SPAN LANG=3D"fr-ca"></SPAN><SPAN =
LANG=3D"fr-ca"> <FONT COLOR=3D"#800000" =
FACE=3D"Wingdings">*</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> </FONT></SPAN><A =
HREF=3D"mailto:[email-masked]"><SPAN LANG=3D"en-us"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Tahoma">mailto:[email-masked]</FONT></U></SPAN></A><SPAN =
LANG=3D"en-us"></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma">Microsoft =
Corporation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"fr-ca"></SPAN><SPAN LANG=3D"fr-ca"></SPAN><SPAN LANG=3D"fr-ca"> =
<FONT COLOR=3D"#800000" FACE=3D"Wingdings">(</FONT><FONT SIZE=3D1 =
FACE=3D"Comic Sans MS"></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Tahoma">425-936-2602</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma">One Microsoft =
Way</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma">Redmond, WA =
98052</FONT></SPAN>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0DD93.09450F5A--

Date: Mon, 14 May 2001 01:22:32 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Simon Josefsson <[email-masked]>, John Gardiner Myers <[email-masked]>
CC: [email-masked], Tony Hansen <[email-masked]>
Subject: Re: base32 in draft-ietf-cat-sasl-gssapi-04.txt
Sender: [email-masked]

Tony Hansen wrote:

> I disagree. It may not be stated properly, but it must be part of the
> definition of a base32 string that it may contain characters other than
> those explicitly part of the base32 alphabet, and that a base32 parser
> must be prepared to deal with such characters.

See my comment below to John's message.

John Gardiner Myers wrote:

> > 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.
>
> The intention is to allow this base32 specification to be reused by
> other protocols needing a case-insensitive encoding.  I copied these
> properties from base64, even though these properties are completely
> irrelevant to SASL's use of base32.

They are not just irrelevant, they harmful for GSSAPI! When client receives
GSSAPI mechanism name from a server it MUST NOT ignore non-base32
characters.
And server MUST never generate such beast.

Simon Josefsson wrote:

> Consider referencing draft-josefsson-base-encoding-02.txt instead for
> aesthetic reasons :-)   E.g., I shouldn't have to read through MIME
> specs in order to learn base64, I shouldn't have to read through
> SASL-GSSAPI definitions in order to learn base32.

This is the exact reasons for most of my complains about base32 in GSSAPI
document.
There is no reason SASL WG can't produce another document (I am pretty sure
that this document will pass Last Call without any problems)

I suggest that we move base32 out of GSSAPI spec. Having base32 in a
separate document has the following advantages:
1). No need to remember that base32 is defined in GSSAPI.
2). Searching for base32 description on IETF websites is easier (even
possible).
3). Other RFCs referencing base32 will not depend on GSSAPI document and its
progress.
4).  There is no confusion about "any character outside base32 is ignored"
rule (actually if GSSAPI states that this rule doesn't apply to GSSAPI
mechanism names, would be great).

__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

To: <[email-masked]>
Subject: Re: Comments on draft-burdis-cat-srp-sasl-04
Date: Wed, 09 May 2001 18:37:42 +0200
From: Keith Burdis <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Quoting [email-masked]:

> Excerpts From Keith Burdis <[email-masked]>:
> Message
> >Hmm. I like the idea of warm and fuzzy users :-) but I am not sure what
> >you mean by "the client and server send nothing for the remaining steps" ?
> 
> The server sends the last piece of data. In most protocol (SMTP for
> instance) the client has to send a blank SASL request after this and
> then the server sends a 235 Authentication successful. Some protocols
> optimise this roundtrip out but for those that don't I think it's
> important to say that the client MUST send an empty request.

Aah I see what you mean. So we should include something like:

"If a protocol using this mechanism allows the server to indicate that 
authentication is successful along with the last piece of data it sends, then 
the server SHOULD do so. However, if the protocol does not allow this then the 
client MUST send an empty request, to which the server will respond with an 
indication that authentication was successful."

> Tim

  - Keith
--
Keith Burdis                        
---

From: "Mitchell" <[email-masked]>
To: [email-masked]
Subject: Business/Employment Opportunity
Date: Tue, 8 May 2001 17:36:35 -1000
Sender: [email-masked]

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884

don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------

ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

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

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.

From: [email-masked]
Date: Tue, 8 May 2001 14:26:34 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-burdis-cat-srp-sasl-04
Sender: [email-masked]

Excerpts From Keith Burdis <[email-masked]>:
Message
>Hmm. I like the idea of warm and fuzzy users :-) but I am not sure what you 
>mean by \"the client and server send nothing for the remaining steps\" ?

The server sends the last piece of data. In most protocol (SMTP for instance) the client has to send a blank SASL request after this and then the server sends a 235 Authentication successful. Some protocols optimise this roundtrip out but for those that don't I think it's important to say that the client MUST send an empty request.

Thanks,
Tim

To: <[email-masked]>
Subject: Re: Comments on draft-burdis-cat-srp-sasl-04
Date: Tue, 08 May 2001 18:41:55 +0200
From: Keith Burdis <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Quoting [email-masked]:

> -There is no way for the server to say \"You must negotiate a security
> layer\" (i.e. you may negotiate a encryption or integrity layer but not
> no layer). I propose adding an option like \"cleartext=false\" to the
> options string.

This is a valid point. However, I think that \"cleartext=false\" would only imply 
that encryption is necessary, since using only integrity protection will still 
involve transmiting cleartext data. Perhaps we could include a \"mandatory\" 
option, so the server could send:

  \"mandatory=integrity,mandatory=confidentiality\"

or just:

  \"mandatory=integrity\"

for example. It doesn\'t make sense for a client to send this option since it is 
only able to choose options that the server makes available. Of course it can 
choose to abort the connection if the server does not offer an option that it 
requires.

> -There is no way for the client and server to negotiate a max buffer
> size for the integrity/encryption layers (DIGEST-MD5, KERBEROS_V4, and
> GSSAPI all have this capability)

This could be handled by a \"maxbuffersize\" option. The server sends its maximum 
buffer size as \"maxbuffersize=???\". The client may send this option with a 
value smaller than or equal to this size. If the client doesn\'t send the option 
then it is assumed that the server\'s maxbuffersize is being used. Of course, 
the specified buffer sizes can not be greater than the maximum sizes already 
specified in the draft. Should we specify a default maxbuffersize that is used 
when the server does not specify this option, or should we make the option 
mandatory? If we specify a default the value then the client could send this 
option with a value less than or equal to the default, even if the server 
doesn\'t send this option. I\'d go for making the option mandatory.

> -What should the server use as it\'s authorization identity if it is the
> same as the authentication identity? Empty string or the authid? There
> should be one right way to do it spelled out in the spec to avoid
> interopability problems.

Agreed. I\'d be inclined to say the client should explicitly state that the 
authorisation identity is the same as the authentication identity, if it wishes 
this to be so.

> -In section 4.5 there is an extra paren at the end of the line
> \"bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )))\"

Okay. We\'ll fix that.

> -There should be a section 4.7 to wrap up the discussion of the
> authentication and give implementors that warm fuzzy feeling that
> they\'re done :) Also, this section should say something about the client
> and server send nothing for the remaining steps.

Hmm. I like the idea of warm and fuzzy users :-) but I am not sure what you 
mean by \"the client and server send nothing for the remaining steps\" ?
After authentication the client and server exchange protocol data, perhaps 
filtered through a security layer. Perhaps stating this wouldn\'t be a bad idea.

> -Section 5.2 gives no details about the wire format of the sequence
> number q. I assume it\'s 4 bytes in network byte order?

Section 2 states \"All data is encoded and sent in network byte order (big-
endian)\". The introduction to section 5 states \"q is a four-octet scalar 
quantity representing a sequence number\". Scalars are described in section 3.1.

> -The last word in 5.3 should be something besides \"exchange\". Maybe
> \"connection\"?

\"connection\" sounds good.
 
> -I found section 5.3 kinda unclear in general. I took me a couple
> readings to realize you re-initialize the hmac with K each time (not
> once in the beggining or something). Some clarification here couldn\'t
> hurt.

It would appear so. In our implementation we initialise the hmac with K once in 
the beginning when we create the security layer (Java input and output streams).

> -Section 5.4 ends with the word \"or\". Presumably this wasn\'t intended.

Indeed it wasn\'t. Well spotted.

> -I think section 6 (the example) would be more useful if it also
> contained the exchange base64 decoded to ascii for easy reading.

Sounds reasonable. Another possibility would be to include an ACAP example, 
like RFC2831 does, since it doesn\'t base64 encode the protocol data.

> Thanks,
> Tim

Thanks very much for your input. One point to note is that the use of options 
as name=value pairs was Tim\'s idea. It has proven to be much better than the 
original bit string I proposed, as can be seen by the flexibility of easily 
adding the above features.

  - Keith
--
Keith Burdis                        
---

To: [email-masked]
Subject: base32 in draft-ietf-cat-sasl-gssapi-04.txt
From: Simon Josefsson <[email-masked]>
Date: 08 May 2001 14:23:22 +0200
Lines: 47
Sender: [email-masked]

All,

two corrections for the base32 padding part of
draft-ietf-cat-sasl-gssapi below, I believe they are correct (?).

Also, if the intent is to provide a generic base32 description, I
think it would be good to include recomendations for often confused
details, such as if padding characters should be treated as
"characters outside of the base32 alphabet" or if they should be
"taken as evidence that the end of the data has been reached", I think
the most error-resistant approach is to treat padding characters as
outside of the base32 alphabet until at the end of the encoded data.
This probably isn't an issue within the scope of this draft, but for
other uses (in noisier environments, e.g. email) these details become
more important.

It has also been suggested that C code might be included to ease
correct implementations, including handling of different padding rules
etc.

Consider referencing draft-josefsson-base-encoding-02.txt instead for
aesthetic reasons :-)   E.g., I shouldn't have to read through MIME
specs in order to learn base64, I shouldn't have to read through
SASL-GSSAPI definitions in order to learn base32.

   Special processing is performed if fewer than 40 bits are available
   at the end of the data being encoded.  A full encoding quantum is
   always completed at the end of a body.  When fewer than 40 input bits
   are available in an input group, zero bits are added (on the right)
   to form an integral number of 5-bit groups.  Padding at the end of
   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
+  an integral multiple of 8 characters with no "=" padding, (2) the
   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
+  encoded output will be five characters followed by three "=" padding
   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.

From: [email-masked]
Date: Mon, 7 May 2001 17:53:15 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked]
Subject: Comments on draft-burdis-cat-srp-sasl-04
Sender: [email-masked]

-There is no way for the server to say "You must negotiate a security layer" (i.e. you may negotiate a encryption or integrity layer but not no layer). I propose adding an option like "cleartext=false" to the options string.

-There is no way for the client and server to negotiate a max buffer size for the integrity/encryption layers (DIGEST-MD5, KERBEROS_V4, and GSSAPI all have this capability)

-What should the server use as it's authorization identity if it is the same as the authentication identity? Empty string or the authid? There should be one right way to do it spelled out in the spec to avoid interopability problems.

-In section 4.5 there is an extra paren at the end of the line
"bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )))"

-There should be a section 4.7 to wrap up the discussion of the authentication and give implementors that warm fuzzy feeling that they're done :) Also, this section should say something about the client and server send nothing for the remaining steps.

-Section 5.2 gives no details about the wire format of the sequence number q. I assume it's 4 bytes in network byte order?

-The last word in 5.3 should be something besides "exchange". Maybe "connection"?

-I found section 5.3 kinda unclear in general. I took me a couple readings to realize you re-initialize the hmac with K each time (not once in the beggining or something). Some clarification here couldn't hurt.

-Section 5.4 ends with the word "or". Presumably this wasn't intended.

-I think section 6 (the example) would be more useful if it also contained the exchange base64 decoded to ascii for easy reading.

Thanks,
Tim

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Comment on draft-ietf-cat-sasl-gssapi-04.txt
Date: Wed, 02 May 2001 14:16:45 -0700
Organization: Netscape Communications Corporation
Lines: 81
NNTP-Posting-Host: 192.18.126.70
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey Melnikov wrote:
> Typo: mechanisms

Thanks, I ran a spell checker on the document.  I had several places
where I had mistyped "mechanisms".

> "multiple of 8 characters"?

Thanks.  Good catch.

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

The intention is to allow this base32 specification to be reused by
other protocols needing a case-insensitive encoding.  I copied these
properties from base64, even though these properties are completely
irrelevant to SASL's use of base32.

> Your forgot sequencing flag ;-) [sequence_req_flag].

I meant to say sequence_req_flag instead of replay_det_req_flag.
--------------ms0DBC0505FF0F8178E43F9D0D
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

--------------ms0DBC0505FF0F8178E43F9D0D--

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: Wed, 02 May 2001 14:01:12 -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.

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

Alexey Melnikov wrote:
> > 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.

Section 6 affects the implementation of a protocol profile.  It does not
affect the definition of a protocol profile.

> One of the reasons I've asked was because BEEP explicitly prohibits that.
> [having TLS and SASL security layers interact]

It is certainly reasonable for a protocol profile to do this, since the
two provide the same set of services.  TLS on top of SASL is usually
prohibited by protocols prohibiting the starting of TLS after
authentication is complete.  (After authentication, it's already too
late to benefit from TLS anyway.)
--------------ms1B54793130FB62172E4E1511
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

--------------ms1B54793130FB62172E4E1511--

Date: Thu, 03 May 2001 06:52:27 +1000
To: Alexey Melnikov <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP and SM2
Cc: Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:55 AM 5/2/01 -0600, Alexey Melnikov wrote:
>"Raif S. Naffah" wrote:
>
> > 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,
>
>I like the idea behind SM2 (it definitely makes sense and Java API shows a 
>nice
>way to implement SM2-<YYY> assuming the existence of an implementation of
><YYY>).

glad to read that :-)

>However I see the following problem with SM2 document (correct me if I am
>wrong): every mechanism that can be used in reauthentication mode has to
>describe
>  1). Parameters that describe Security Context (they are mechanism dependent)
>  2). Evidence (again mechanism dependent).
>i.e. the specification of SASL mechanism <YYY> must define 1) and 2) in order
>to be used under SM2.

correct (to both points).

>(For example, currently there is no way to implement SM2-GSSAPI, because 
>GSSAPI
>doesn't define what 1) and 2) are). Assuming people agree that SM2 is a good
>idea, this leaves 2 alternatives:
>  1). Whenever a new SASL mechanism is written that can take advantage of
>reauthentication, SM2 spec is updated to include 1). and 2). for this
>mechanism. (IMHO, this is waste of effort)

agree that this would be a waste of effort.

>  2). Put the description of SM2 into SASL spec, or at least publish SM2 
> ASAP as
>an independent RFC. This has to be done *before* any other mechanism starts
>using it. Otherwise we end up rewriting several SASL mechanisms in order to
>include reauthentication support based on SM2.

this option (meaning either one of the two alternatives) makes more sense 
to me.  if anything we (authors of the SM2 draft) can do, can be done to 
facilitate this, we are happy to oblige.

>Comments?
>
> > including 2831 if its authors so desire.

cheers;
rsn

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: Wed, 02 May 2001 13:51:50 -0700
Organization: Netscape Communications Corporation
Lines: 70
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey Melnikov wrote:
> A sentence saying that "other flags MAY be specified" will make me happy.

I added a second paragraph to section 6:

The implementation MAY set any GSSAPI flags or arguments not mentioned
in htis specification as is necessary for the implementation ot enforce
its security policy.

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

Really?  Which ones?  Sequencing is trival to implement on top of
integrity protection.  It's far easier than replay detection.
--------------msB788B089D02D2F5233A1E227
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

--------------msB788B089D02D2F5233A1E227--

Date: Wed, 02 May 2001 00:55:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Raif S. Naffah" <[email-masked]>
CC: Keith Burdis <[email-masked]>, [email-masked]
Subject: Re: SRP and SM2
Sender: [email-masked]

"Raif S. Naffah" wrote:

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

I like the idea behind SM2 (it definitely makes sense and Java API shows a nice
way to implement SM2-<YYY> assuming the existence of an implementation of
<YYY>).
However I see the following problem with SM2 document (correct me if I am
wrong): every mechanism that can be used in reauthentication mode has to
describe
 1). Parameters that describe Security Context (they are mechanism dependent)
 2). Evidence (again mechanism dependent).
i.e. the specification of SASL mechanism <YYY> must define 1) and 2) in order
to be used under SM2.
(For example, currently there is no way to implement SM2-GSSAPI, because GSSAPI
doesn't define what 1) and 2) are). Assuming people agree that SM2 is a good
idea, this leaves 2 alternatives:
 1). Whenever a new SASL mechanism is written that can take advantage of
reauthentication, SM2 spec is updated to include 1). and 2). for this
mechanism. (IMHO, this is waste of effort)
 2). Put the description of SM2 into SASL spec, or at least publish SM2 ASAP as
an independent RFC. This has to be done *before* any other mechanism starts
using it. Otherwise we end up rewriting several SASL mechanisms in order to
include reauthentication support based on SM2.

Comments?

> including 2831 if its authors so desire.

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
I don't represent the opinion of TSA/ACI!
__________________________________________

Date: Wed, 02 May 2001 01:21:59 -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]

I disagree. It may not be stated properly, but it must be part of the
definition of a base32 string that it may contain characters other than
those explicitly part of the base32 alphabet, and that a base32 parser
must be prepared to deal with such characters.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> > > 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.
> >
> > It means a generator is free to introduce other characters that make the
> > output more transportable, such as newlines and other white space.
> >
> 
> I understand that. However it is not the property of base32 (IMHO, it is a
> generic rule) encoding and shouldn't  be in SASL document.

Date: Tue, 01 May 2001 23:15:19 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tony Hansen <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comment on draft-ietf-cat-sasl-gssapi-04.txt
Sender: [email-masked]

> > 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.
>
> It means a generator is free to introduce other characters that make the
> output more transportable, such as newlines and other white space.
>

I understand that. However it is not the property of base32 (IMHO, it is a
generic rule) encoding and shouldn't  be in SASL document.

_________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
I don't represent the opinion of TSA/ACI!
__________________________________________

Date: Tue, 01 May 2001 23:08:54 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Paul Leach <[email-masked]>
CC: Keith Burdis <[email-masked]>, [email-masked]
Subject: Re: SRP and SM2
Sender: [email-masked]

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,

IMHO, the right question to ask is "how many existing implementations of RFC
2831 support reauthentication"? CMU implementation does not. Anybody
supports DIGEST-MD5 reauthentication?

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

As I understand SM2 after reading the document, it is a kind of
"reauthentication framework", higher level SASL mechanism designed to be
used together with other SASL mechanisms (hopefully what I wrote has any
sense in English :-)).

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

If there are no two independent interoperable client/server side
implementations, DIGEST-MD5 can't progress to Draft Standard. If we decide
to move this functionality to SM2, reauthentication will not delay the
advancement of DIGEST and can be done separately.

> Paul

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
I don't represent the opinion of TSA/ACI!
__________________________________________