Subject: CRAM-MD5 implementation limits for <user>

From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Date: Wed, 23 Apr 2003 17:11:25 -0600

The Plain draft specifies that implementations must support at least 255
octets for the <auth*id> and <passwd> elements. Should we do the same
for <user> in CRAM-MD5?

--lyndon

From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
To: [email-masked]
Subject: CRAM-MD5 implementation limits for <user>
Organization: The Frobozz Magic Homing Pigeon Company
Date: Wed, 23 Apr 2003 17:11:25 -0600
Sender: [email-masked]

The Plain draft specifies that implementations must support at least 255
octets for the <auth*id> and <passwd> elements. Should we do the same
for <user> in CRAM-MD5?

--lyndon

Date: Sun, 20 Apr 2003 00:12:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Chris Newman <[email-masked]>
CC: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: SASL API: should sasl_errdetail be human readable or deprecated?
Sender: [email-masked]

Chris Newman wrote:

> When I added the sasl_errdetail call to the SASL API, my intent was that it
> would provide human readable strings intended for IMAP NO and POP -ERR style
> text response messages, and suitable for display to end-users.
>
> The current API spec is too imprecise about the purpose of that function:
>   <http://www.ietf.org/internet-drafts/draft-newman-sasl-c-api-01.txt>
>
> Given there is already a logging callback in the SASL API, I would argue that
> sasl_errdetail serves no purpose unless it is intended for end-user
> consumption.  However, the CMU implementation generates cryptic error strings
> which are not suitable for end-user consumption and which leak security
> sensitive information (like the distinction between user not found and bad
> password).
>
> That leaves us a choice:
>
> 1. Clarify that sasl_errdetail is intended to return error strings suitable to
> be passed back over protocol and presented to an end-user.  This would require
> clarification to the spec and some changes to the CMU implementation.  I am
> willing to propose the code changes to CMU if there is consensus for this
> option.
>
> 2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error
> codes as the only way to determine what text messages to pass back to the
> end-user.  Use the logging callback for all detailed error logging.
>
> I propose option 1 as the correct choice.  My theory is that attempting to
> enumerate all errors which require different behaviors on the client side is a
> tractable problem, but attempting to enumerate all errors which are useful to
> inform the user is not a tractable problem and thus a text string to pass back
> to the user is important.
>
> If there are no objections, I will propose changes to the API spec to Alexey
> and changes to the CMU implementation to Rob.

I agree with this proposal (and just finished updating the document).

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on 2831 Confidentiality Protection
From: Sam Hartman <[email-masked]>
Date: Mon, 14 Apr 2003 18:03:14 -0400
Sender: [email-masked]

>>>>> "glenn" == glenn engel <[email-masked]> writes:

    glenn> From the information on the SASL website it appears to me
    glenn> that 2831 is currently 'under revision', hence my
    glenn> suggestion to allow use of ESP as an option for encoding
    glenn> the integrity and confidentiality protection.  This could
    glenn> easily be done by simply specifying an 'encoding' field in
    glenn> much the same way the ciper is specified.  If the intent is
    glenn> to only 'tweak' technical errors then this suggestion is
    glenn> clearly too late.

The intent is certainly to avoid breaking backward compatibility.

Chris's comments suggest that introducing a different encoding for
newer ciphers would be unpopular, presumably because it would
introduce implementation complexity and increase the complexity of the
spec.

So, yes, it looks like people believe this change is not worth making,
although they agree in an ideal world reuse of technology would be
good.

Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-sasl-rfc2831
Date: Fri, 11 Apr 2003 15:40:30 -0700
From: "Paul Leach" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0043_01C30040.AFC2EC00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> 
> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, April 09, 2003 12:25 PM
> To: Alexey Melnikov
> Cc: [email-masked]
> 
> 
> >>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:
> 
> 
>     Alexey> === I am not sure whether the last paragraph belongs to
>     Alexey> this document, or whether it should be moved to the SASL
>     Alexey> document or profile documents.  Personally, I would hate
>     Alexey> to update each profile document with this text.
> 
> I think that this goes in the base spec.
> 
> 
> I'll think about text for the man-in-the-middle case.  I'm 
> not really sure what we want to happen.
> 
> We could recommend that people always mandate integrity 
> protection or confidentiality, but doing so would create 
> interoperability problems.

That's not necessary, as long as both sides only offer or agree to
mechanisms that meet their minimum security requirements. I.e., it's not
great but not fatal that they don't always agree on the strongest
mechanism.

Also, using integrity protection on confidentiality does nothing to
prevent attacks on QOP, cipher, etc, negotiations.

> We could recommend that people not use digest-md5, but we 
> should have something to recommend instead.
> 
> 
> 

------=_NextPart_000_0043_01C30040.AFC2EC00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0043_01C30040.AFC2EC00--

From: [email-masked]
To: [email-masked]
Subject: RE: Comments on 2831 Confidentiality Protection
Date: Fri, 11 Apr 2003 15:07:05 -0700
Sender: [email-masked]

>From the information on the SASL website it appears to me that 2831 is currently 'under revision', hence my suggestion to allow use of ESP as an option for encoding the integrity and confidentiality protection.  This could easily be done by simply specifying an 'encoding' field in much the same way the ciper is specified.  If the intent is to only 'tweak' technical errors then this suggestion is clearly too late. 

--
Glenn

> >
> >I just stumbled across the rfc Wednesday.  When was the last call ?
> 
> December 1998.
> 
> >It "would have been" nice
> 
> Lot's of things "would have been" nice.
> 
> We need to focus on resolving clear technical errors and omissions.
> 
> Kurt 
> 

Date: Fri, 11 Apr 2003 13:35:16 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Comments on 2831 Confidentiality Protection
Cc: [email-masked]
Sender: [email-masked]

At 09:42 AM 4/11/2003, [email-masked] wrote:
>> The correct time to make this comment was prior to the 
>> publication of RFC 2831 
>> -- that's the purpose of the last call period.
>
>I just stumbled across the rfc Wednesday.  When was the last call ?

December 1998.

>It "would have been" nice

Lot's of things "would have been" nice.

We need to focus on resolving clear technical errors and omissions.

Kurt 

From: [email-masked]
To: [email-masked]
Subject: RE: Comments on 2831 Confidentiality Protection
Date: Fri, 11 Apr 2003 09:42:51 -0700
Sender: [email-masked]

> 
> The correct time to make this comment was prior to the 
> publication of RFC 2831 
> -- that's the purpose of the last call period.

I just stumbled across the rfc Wednesday.  When was the last call ?  It "would have been" nice to utilize ESP encoding as it addresses other encryption/auth algorithms and would provide a framework for re-using existing IPSEC code in conjunction with SASL.  A new draft of ESP includes policy on how to deal with high speed connections where the sequence number can roll over as well as providing protection from traffic flow analysis. 

By combining the simplicity of Digest Authentication in 2831 and it's nice way of defining keys with ESP a really nice combination would result.

--
Glenn

Date: Thu, 10 Apr 2003 12:13:59 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Comments on 2831 Confidentiality Protection
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The correct time to make this comment was prior to the publication of RFC 2831 
-- that's the purpose of the last call period.

While consistency across the Internet suite is aesthetically attractive and I 
would have supported this proposal prior to the publication and deployment of 
RFC 2831, I must oppose this proposal now.  There are a number of deployed 
implementations of RFC 2831, so backwards compatibility and interoperability 
with the running code would trump the majority of aesthetic and minor technical 
points.

Now if it were determined that the way RC4 is specified in RFC 2831 has a fatal 
security flaw and can not be fixed without breaking interoperability, then your 
proposal would merit consideration.  But I have yet to hear such a 
determination.

                - Chris

begin  quotation by [email-masked] on 2003/4/10 11:23 -0700:

>
> I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes
> the cipher of the message as well as a catenated HMAC.   This requires
> decryption of the entire message before authentication can be done.
> RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical
> encoding.  One notable difference is that ESP defines the HMAC to be done on
> the encrypted contents so that the message can be authenticated without the
> potentially costly cipher being done  (another form of denial of protection
> against denial of service,  replay or man in the middle attacks). Since the
> form of the message is so close to ESP, I would suggest utilizing the exact
> packet format as defined in RFC2406.  This RFC includes the sequence number,
> padding, authentication and encryption techniques to assemble a packet with
> only slight differences to what 2831 specifies.  See section 2 of the
> rfc2406.
> I would suggest specifying that the Confidentiality Protection for rfc2831
> payload be constructed as described in RFC2406.  For purposes of rfc2831, the
> SPI and next header fields could be defined as zeros.
> As an enhancement consider the following - sInce rfc2831 is connection
> oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP
> was instead used as the communication medium then the rfc2831 dialog could
> still be done pretty much as defined with the addition of an SPI argument
> returned to the client.
>
> --
> Glenn
>
> [email-masked] / Agilent Laboratories / NN7N / 425-335-2066
>

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Comments on 2831 Confidentiality Protection
Date: Thu, 10 Apr 2003 11:23:15 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FF8E.406176BE"

------_=_NextPart_001_01C2FF8E.406176BE
Content-Type: text/plain;
	charset="iso-8859-1"

I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC.   This requires decryption of the entire message before authentication can be done.
 
RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding.  One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done  (another form of denial of protection against denial of service,  replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406.  This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies.  See section 2 of the rfc2406.
 
I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406.  For purposes of rfc2831, the SPI and next header fields could be defined as zeros.  
 
As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client.

--
Glenn

[email-masked] / Agilent Laboratories / NN7N / 425-335-2066

------_=_NextPart_001_01C2FF8E.406176BE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=323010018-10042003><FONT face=Arial>I noticed that the 
confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the 
message as well as a catenated HMAC.&nbsp;&nbsp; This requires decryption of the 
entire message before authentication can be done.</FONT></SPAN></DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial>RFC2406 (Encapsulating 
Security Payload&nbsp;for IPSEC) defines a nearly identical encoding.&nbsp; One 
notable difference is that&nbsp;ESP defines the HMAC to be done on the encrypted 
contents so that the message can be authenticated without the potentially costly 
cipher being done &nbsp;(another form of denial of protection against denial of 
service, &nbsp;replay or man in the middle attacks). Since the form of the 
message is so close to ESP, I would suggest utilizing the exact packet format as 
defined in RFC2406.&nbsp; This RFC includes the sequence number, padding, 
authentication and encryption techniques to assemble a packet with only slight 
differences to what 2831 specifies.&nbsp; See section 2 of the 
rfc2406.</FONT></SPAN></DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial>I would suggest specifying 
that the Confidentiality Protection for rfc2831 payload be constructed as 
described in RFC2406.&nbsp; For purposes of rfc2831, the SPI and next header 
fields could be defined as zeros.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=323010018-10042003><FONT face=Arial>As an enhancement consider 
the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC 
is 'implied' by the connection.&nbsp; If UDP was instead used as the 
communication medium then the rfc2831 dialog could still be done pretty much as 
defined with the addition of an SPI argument returned to the 
client.</FONT></SPAN></DIV>
<P><FONT face=Arial>--<BR><FONT face="Comic Sans MS" color=#00ff00><EM><FONT 
color=#000000>Glenn</FONT><BR></EM></FONT><BR>[email-masked] / Agilent 
Laboratories / NN7N / 425-335-2066</FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C2FF8E.406176BE--

------=_NextPartTM-000-9d68b00c-f492-4731-b914-86f64caabae5--

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-rfc2831
From: Sam Hartman <[email-masked]>
Date: Wed, 09 Apr 2003 15:25:01 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> === I am not sure whether the last paragraph belongs to
    Alexey> this document, or whether it should be moved to the SASL
    Alexey> document or profile documents.  Personally, I would hate
    Alexey> to update each profile document with this text.

I think that this goes in the base spec.

I'll think about text for the man-in-the-middle case.  I'm not really
sure what we want to happen.

We could recommend that people always mandate integrity protection or
confidentiality, but doing so would create interoperability problems.
We could recommend that people not use digest-md5, but we should have
something to recommend instead.

Date: Tue, 08 Apr 2003 21:01:48 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-rfc2831
Sender: [email-masked]

Sam Hartman wrote:

> >>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:
>
>     Alexey> We have to be clear that for the protocols that use the
>     Alexey> same format for authentication and authorization ids,
>     Alexey> "authzid" is in UTF-8 and MUST NOT be converted to
>     Alexey> ISO-8859-1 as username/password are.
>
> No, authz ID is in whatever format the application says it is.  All
> the base spec seems to say is that it is a string.
>
> I would recommend replacing the text I complained about with something
> that says "The authorization identifier MUST NOT be converted to ISO
> 8859-1 by this mechanism even if the authentication identifier is
> converted for compatibility."

Ok, I've mostly fixed this.

The new text in 2.1.2 looks like:

authzid

The "authorization ID" directive is optional. If present, and the
authenticating user has sufficient privilege, and the server supports it,
then after authentication the server will use this identity for making all
accesses and access checks. If the client specifies it, and the server
does not support it, then the response-value calculated on the server will
not match the one calculated on the client and authentication will fail.

The authorization identifier MUST NOT be converted to ISO 8859-1 even if
the authentication identifier ("username") is
converted for compatibility as directed by "charset" directive.

The server SHOULD verify the correctness of an authzid. For example, an
IMAP [RFC 3501] server will prepare the received authzid using the
"SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep].
If preparation of the authzid fails or results in an empty string, the
server MUST fail the authentication exchange.

===
I am not sure whether the last paragraph belongs to this document, or
whether it should be moved to the SASL document or profile documents.
Personally, I would hate to update each profile document with this text.

>     >> The security discussion seems inadequate.
>
>     Alexey> Suggestions?
>
> I specifically meant the security discussion of the QOP stuff, BTW.

>>3.6  Man in the Middle

...

>>A possible man-in-the-middle attack would be to substitute a weaker qop
>>scheme for the one(s) sent by the server; the server will not be able to

>>detect this attack. For this reason, the client should always use the
>>strongest scheme that it understands from the choices offered, and
>>should never choose a scheme that does not meet its minimum
>>requirements.

Can you suggest any specific changes to this text?

Cheers,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

Date: Tue, 08 Apr 2003 14:26:59 -0700
From: Chris Newman <[email-masked]>
Subject: SASL API: should sasl_errdetail be human readable or deprecated?
To: Alexey Melnikov <[email-masked]>, Rob Siemborski <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

When I added the sasl_errdetail call to the SASL API, my intent was that it 
would provide human readable strings intended for IMAP NO and POP -ERR style 
text response messages, and suitable for display to end-users.

The current API spec is too imprecise about the purpose of that function:
  <http://www.ietf.org/internet-drafts/draft-newman-sasl-c-api-01.txt>

Given there is already a logging callback in the SASL API, I would argue that 
sasl_errdetail serves no purpose unless it is intended for end-user 
consumption.  However, the CMU implementation generates cryptic error strings 
which are not suitable for end-user consumption and which leak security 
sensitive information (like the distinction between user not found and bad 
password).

That leaves us a choice:

1. Clarify that sasl_errdetail is intended to return error strings suitable to 
be passed back over protocol and presented to an end-user.  This would require 
clarification to the spec and some changes to the CMU implementation.  I am 
willing to propose the code changes to CMU if there is consensus for this 
option.

2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error 
codes as the only way to determine what text messages to pass back to the 
end-user.  Use the logging callback for all detailed error logging.

I propose option 1 as the correct choice.  My theory is that attempting to 
enumerate all errors which require different behaviors on the client side is a 
tractable problem, but attempting to enumerate all errors which are useful to 
inform the user is not a tractable problem and thus a text string to pass back 
to the user is important.

If there are no objections, I will propose changes to the API spec to Alexey 
and changes to the CMU implementation to Rob.

                - Chris

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-rfc2831
From: Sam Hartman <[email-masked]>
Date: Mon, 07 Apr 2003 13:39:20 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> We have to be clear that for the protocols that use the
    Alexey> same format for authentication and authorization ids,
    Alexey> "authzid" is in UTF-8 and MUST NOT be converted to
    Alexey> ISO-8859-1 as username/password are.

No, authz ID is in whatever format the application says it is.  All
the base spec seems to say is that it is a string.

I would recommend replacing the text I complained about with something
that says "The authorization identifier MUST NOT be converted to ISO
8859-1 by this mechanism even if the authentication identifier is
converted for compatibility."

    >> The security discussion seems inadequate.

    Alexey> Suggestions?

I specifically meant the security discussion of the QOP stuff, BTW.

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: Sam Hartman <[email-masked]>
Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms
Date: Sun, 6 Apr 2003 10:23:33 +1000
Cc: SASL <[email-masked]>
Sender: [email-masked]

On Saturday 05 April 2003 07:11, Sam Hartman wrote:
> >>>>> "Raif" == Raif S Naffah <[email-masked]> writes:
>
>     Raif> would a sequence of bytes preceded by their count (one
>     Raif> additional byte) be enough?
>
> I don't understand your question.  For a sasl mechanism, I think
> limiting authorization identifiers to 255 bytes would be overly
> restrictive.
>
> For an application profile, sequence of bytes would be an
> underspecified authorization identifier.

the adoption of StringPrep, within the specifications of a SASL 
Mechanism, solves the question of required (canonical) transformations 
for authentication IDs (uersnames) and passwords.  this is because as 
you pointed out --in your last email, and i totally overlooked-- these 
entities are acquired by the mechanism itself and hence are not within 
the scope of the Profile.

the authorization ID on the other hand, is not acquired by the 
Mechanism; at least this is my understanding/interpretation of last 
para in section 4.1 of draft-myers-saslrev-02.txt, which echoes another 
para in section 3 of RFC-2222:

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

in other words, a Profile hands over an authorization ID (or a callback 
mechanism to receive it), which it (the Mechanism) then transmits to 
the peer.  my question is on the encoding of this entity as seen by the 
Mechanism, at that interface point.

draft-myers-saslrev-02, section 4.2 reflects discussions we had in this 
group about this token (authorization ID).  it proposes:

   "An authorization identity is a string of zero or more ISO 10646
   [ISO-10646] coded characters.  The NULL (U+0000) character is not
   permitted in authorization identities."

my question is about reaching a consensus on a choice and wording for 
how this entity is passed between the Mechanism and the Profile.  if a 
string of iso-10646 w/o nulls is not an acceptable option would an 
octet sequence with a length octet be one.  if neither are, what other 
alternatives are there.

cheers;
rsn

Date: Sat, 05 Apr 2003 14:43:07 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
CC: SASL <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: authentication and authorization identities, and passwords in SASL  Mechanisms
Sender: [email-masked]

Keith Burdis wrote:

> Seriously, this looks to be a reasonable specification for usernames and
> passwords. Is there any reason why all mechanisms shouldn't use at least this
> set of restrictions?

IMHO, all new mechanisms should use the same stringprep profile.

> Why for example, would anonymous use a less restrictive
> profile?

This is required for backward compatibility, as ANONYMOUS allowed for arbitrary
text to be passed.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

Date: Sat, 05 Apr 2003 14:47:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: My concerns about a SRP SASL mechanism
Sender: [email-masked]

Sam Hartman wrote:

> Here's roughly what would need to happen to turn a SASL mechanism into
> a standards track GSSAPI mechanism
>
> 1) You need to use the GSSAPI initial context token format.  this
>    means you need to include an OID and a bit of header at the
>    beginning of the authentication messages.
>
> 2)  You need to assign an OID to your mechanism.
>
> 3) You may need to think about name formats for principal names a bit.
>
> 4) There may be some issues involving out-of-order delivery of
>    messages you need to think about.
>
> 5) You should organize the document so it will be clear both to people
>    implementing as a SASL mechanism and as a GSSAPI mechanism.

Sam, do you volunteer to write a paragraph that describes a binary
representation for the GSSAPI header?
If you (or somebody else) do this, we would be done with this discussion.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: My concerns about a SRP SASL mechanism
From: Sam Hartman <[email-masked]>
Date: Sat, 05 Apr 2003 09:55:56 -0500
Sender: [email-masked]

[I tried to make this clear at the working group meeting, but it
didn't really make it into the minutes.  The SRP mechanism is out of
scope for this working group, so I am not acting as chair in this
discussion.  I am acting as an interested party.  Should this
specification ever become a work item of this working group, I'll find
someone else to argue this position so I can be an effective chair.]

,
>>>>> "Keith" == Keith Burdis <[email-masked]> writes:

    Keith> On Friday 04 Apr 2003 21:08, Sam Hartman wrote:
    >> I've been asked to clarify my objections to an SRP SASL
    >> mechanism.
    >> 
    >> The basic objection is that mechanism designers should write
    >> GSSAPI mechanisms not SASL mechanisms unless they have a good
    >> reason to do otherwise.

    Keith> I have no problem with the GSS-API, but it is far from
    Keith> simple. Compare the 85 pages in RFC 2078 with the 16 pages
    Keith> in RFC 2222.

I think comparing the page counts is a significantly misleading
complexity metric.  I believe that the complexity of a simple GSSAPI
mechanism is not significantly more than the complexity of a simple
SASL mechanism with a security layer.  There are certainly GSSAPI
mechanisms that are more complex than non-GSSAPI SASL mechanisms, but
this is not required.

    Keith> The basic question is: why should mechanism designers
    Keith> bother with the complexity of GSS-API when they can design
    Keith> much simpler SASL mechanisms? 

First, I  don't think there is that much more complexity involved.

But my primary concern is that review and specification of a
technology for multiple protocols is much more expensive than taking
the work up front to specify the technology for a framework.
Specifying SRP for all the other protocols that use GSSAPI would take
more time than doing a SRP GSSAPI mechanism rather than a SASL
mechanism.  Even if we could reuse significant ideas from the SASL
mechanism, doing the work to compare and contrast the results of all
the SRP specifications against each other making sure that they worked
well together and that there were not bugs introduced as ideas were
copied would be significantly greater than the cost of specifying a
GSSAPI mechanism now.

The only way specifying a SASL mechanism makes sense is if we hope
never to have to do the work of specifying a GSSAPI mechanism later or
to specify SRP for other protocols that support both GSSAPI and other
authentication technology.  There are two reasons this might be the
case.  The first is that SRP might not get enough deployment to matter
for those protocols.  The second is that SRP is somehow uniquely
suited to applications that use SASL but not to current and future
protocols that use GSS.

If SRP is not going to get enough deployment for future work, then we
shouldn't even bother with the SASL mechanism.  Specification review
effort is very expensive and we're all fairly busy as is.

I can't think of a reason why SRP would be more suited to email,
directory access, etc than say file sharing or remote login.  If you
can then I'll certainly reconsider.

    Keith> The reason that SASL came
    Keith> about was because alternatives like the GSS-API were too
    Keith> complicated.

I think the complexity being complained about was mostly on the
application side--GSSAPI is hard to integrate into a protocol.  I
don't think the same complexities really exist on the  mechanism side.

SASL was also important because there exist SASL mechanisms that do
not have enough features to be GSS mechanisms.

    Keith> I agree that an SRP GSS-API mechanism [1] would be great to
    Keith> have, but that is no reason not to have an SRP SASL
    Keith> mechanism. 

I think it is.  First, I think the costs of doing both an SRP GSS
mechanism and an SRP SASL mechanism are significantly higher than the
costs of the GSS mechanism alone.  Second, having multiple ways to use
SRP in the same protocol will confuse site administrators and users
and make configuration more complex.

    >> If SRP is useful, then people will want to use it with other
    >> protocols and so we should try to make sure it is useful with
    >> all those protocols.  The IETF is busy and reviewing security
    >> documents takes time.  So we should find the solution that
    >> involves minimizing review within the IETF while maximizing the
    >> number of situations where the technology is useful.

    Keith> It sounds to me like you are saying that we should not have
    Keith> any other SASL mechanisms other than the SASL GSS-API
    Keith> mechanism. If so, then what is the point of SASL? Is it
    Keith> then just a wrapper for GSS-API?

I think the point of SASL is to be a convenient way to add
authentication to applications.  It happens to encapsulate a lot of
the GSS complexity that will be the same for all applications.  It
also provides for mechanisms that are too weak to be GSS mechanisms.

Applications should use SASL if they can live within its constraints.
Except in some special cases mechanisms should be designed for GSS.
    >> 2) GSSAPI libraries are hard to deal with and multi-mechanism
    >> GSSAPI support is weak
    >> 
    >> There is no requirement that you use a GSSAPI library or even
    >> the GSSAPI within your program to implement a SASL GSSAPI
    >> mechanism.  You simply need to have a compatible wire encoding,
    >> but you can actually implement the mechanism the same as you
    >> would implement other SASL mechanisms if you find that an
    >> easier implementation choice.

    Keith> It is not really the same as other SASL mechanisms, because
    Keith> there is extra "baggage" included.

A few extra bytes at the beginning of the context tokens doesn't seem
unacceptable.

    >> Here's roughly what would need to happen to turn a SASL
    >> mechanism into a standards track GSSAPI mechanism
    >> 
    >> 1) You need to use the GSSAPI initial context token format.
    >> this means you need to include an OID and a bit of header at
    >> the beginning of the authentication messages.

    Keith> It also means we have to deal with ASN.1:

False.  The GSSAPI spec defines the context token header both in terms
of ASN.1 and in terms of raw bytes.  It explicitly states that the raw
bytes definition is authoritative.

You could choose to use ASN.1 if you like, or you could just emit the
context token header for your mechanism, listing it as raw bytes in
your specification.

    >> 4) There may be some issues involving out-of-order delivery of
    >> messages you need to think about.

    Keith> In the authentication exchange or in the security layer?

security layer.

    Keith> [1]
    Keith> http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt

From: Keith Burdis <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: My concerns about a SRP SASL mechanism
Date: Sat, 5 Apr 2003 01:17:02 +0000
Sender: [email-masked]

On Friday 04 Apr 2003 21:08, Sam Hartman wrote:
> I've been asked to clarify my objections to an SRP SASL mechanism.
>
> The basic objection is that mechanism designers should write GSSAPI
> mechanisms not SASL mechanisms unless they have a good reason to do
> otherwise.

I have no problem with the GSS-API, but it is far from simple. Compare the 85 
pages in RFC 2078 with the 16 pages in RFC 2222. 

The basic question is: why should mechanism designers bother with the 
complexity of GSS-API when they can design much simpler SASL mechanisms? The 
reason that SASL came about was because alternatives like the GSS-API were 
too complicated.

I agree that an SRP GSS-API mechanism [1] would be great to have, but that is 
no reason not to have an SRP SASL mechanism. In our opinion trying to merge 
the two is not a good idea.

> If the SRP mechanism was a GSSAPI mechanism then it could be used
>    unmodified within SSH, NFS V4 and other protocols that support
>    GSSAPI for security within the IETF and within other areas.  It
>    could also be used with all the protocols that use SASL.

Quite true.

> If SRP is useful, then people will want to use it with other protocols
> and so we should try to make sure it is useful with all those
> protocols.  The IETF is busy and reviewing security documents takes
> time.  So we should find the solution that involves minimizing review
> within the IETF while maximizing the number of situations where the
> technology is useful.

It sounds to me like you are saying that we should not have any other SASL 
mechanisms other than the SASL GSS-API mechanism. If so, then what is the 
point of SASL? Is it then just a wrapper for GSS-API?

> Here are some objections I can see to writing the SRP SASL mechanism
> in the form of a GSSAPI mechanism:
>
> 1)  We're almost done with the existing draft.
>
>     Up until now the document has not received significant review
>     within the IETF.  It has not been a work product of a working
>     group  and has not been last called before.  When a document is
>     submitted to the IETF for the standards track, the IETF receives
>     change control and needs the opportunity to  make (potentially
>     significant) changes to the document.

It is not the product of a working group because someone decided that it 
wasn't appropriate due to problems with US patents. It has however been 
discussed on this mailing list on and off for four years. We have no problem 
with making any changes to the document as long as we feel they are 
justified. The current document is very different to the orginal version and 
has benefited significantly from feedback received.

> 2)  GSSAPI  libraries are hard to deal with and multi-mechanism GSSAPI
>     support is weak
>
>     There is no requirement that you use a GSSAPI library or even  the
>     GSSAPI within your program to implement a SASL GSSAPI mechanism.
>     You simply need to  have a compatible wire encoding, but you can
>     actually implement the mechanism the same as you would implement
>     other SASL mechanisms if you find that an easier implementation
>     choice.

It is not really the same as other SASL mechanisms, because there is extra 
"baggage" included.

> Here's roughly what would need to happen to turn a SASL mechanism into
> a standards track GSSAPI mechanism
>
> 1) You need to use the GSSAPI initial context token format.  this
>    means you need to include an OID and a bit of header at the
>    beginning of the authentication messages.

It also means we have to deal with ASN.1:

   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
        thisMech OBJECT IDENTIFIER,
        innerContextToken ANY DEFINED BY thisMech
      }

This is meaningful for GSS-API, but from an SASL mechanism perspective, this 
means that we have a bunch of garbage bytes at the beginning of our exchange.

> 2)  You need to assign an OID to your mechanism.

Ok.

> 3) You may need to think about name formats for principal names a bit.

We don't put any restrictions on name formats, only encodings.

> 4) There may be some issues involving out-of-order delivery of
>    messages you need to think about.

In the authentication exchange or in the security layer?

> 5) You should organize the document so it will be clear both to people
>    implementing as a SASL mechanism and as a GSSAPI mechanism.

The whole point of SASL is that it is simple. Each of the points above adds 
complexity to the mechanism. I am not completely dismissing the idea, but I 
am not convinced that this complexity is justified in the context of what 
SASL is trying to achieve - simple authentication.

  - Keith

[1] http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt

To: [email-masked]
Cc: SASL <[email-masked]>
Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms
From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2003 16:11:56 -0500
Sender: [email-masked]

>>>>> "Raif" == Raif S Naffah <[email-masked]> writes:

    Raif> would a sequence of bytes preceded by their count (one
    Raif> additional byte) be enough?

I don't understand your question.  For a sasl mechanism, I think
limiting authorization identifiers to 255 bytes would be overly
restrictive.

For an application profile, sequence of bytes would be an
underspecified authorization identifier.

To: [email-masked]
Subject: My concerns about a SRP SASL mechanism
Date: Fri,  4 Apr 2003 16:08:46 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

I've been asked to clarify my objections to an SRP SASL mechanism.

The basic objection is that mechanism designers should write GSSAPI
mechanisms not SASL mechanisms unless they have a good reason to do
otherwise.

If the SRP mechanism was a GSSAPI mechanism then it could be used
   unmodified within SSH, NFS V4 and other protocols that support
   GSSAPI for security within the IETF and within other areas.  It
   could also be used with all the protocols that use SASL.  

If SRP is useful, then people will want to use it with other protocols
and so we should try to make sure it is useful with all those
protocols.  The IETF is busy and reviewing security documents takes
time.  So we should find the solution that involves minimizing review
within the IETF while maximizing the number of situations where the
technology is useful.  

Here are some objections I can see to writing the SRP SASL mechanism
in the form of a GSSAPI mechanism:

1)  We're almost done with the existing draft.

    Up until now the document has not received significant review
    within the IETF.  It has not been a work product of a working
    group  and has not been last called before.  When a document is
    submitted to the IETF for the standards track, the IETF receives
    change control and needs the opportunity to  make (potentially
    significant) changes to the document.

2)  GSSAPI  libraries are hard to deal with and multi-mechanism GSSAPI
    support is weak

    There is no requirement that you use a GSSAPI library or even  the
    GSSAPI within your program to implement a SASL GSSAPI mechanism.
    You simply need to  have a compatible wire encoding, but you can
    actually implement the mechanism the same as you would implement
    other SASL mechanisms if you find that an easier implementation
    choice.

Here's roughly what would need to happen to turn a SASL mechanism into
a standards track GSSAPI mechanism

1) You need to use the GSSAPI initial context token format.  this
   means you need to include an OID and a bit of header at the
   beginning of the authentication messages.

2)  You need to assign an OID to your mechanism.

3) You may need to think about name formats for principal names a bit.

4) There may be some issues involving out-of-order delivery of
   messages you need to think about.

5) You should organize the document so it will be clear both to people
   implementing as a SASL mechanism and as a GSSAPI mechanism.

To: [email-masked]
Cc: [email-masked]
Subject: Minutes for SASL working group at IETF 56
From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2003 14:37:18 -0500
Sender: [email-masked]

Minutes based on notes from Chris Newman and Sam Hartman.

-----
SASL WG IETF 56 San Francisco

1. Base spec -- document editor is non-responsive, will assign new editor.

   Issue: Is security considerations sufficient to meet IESG review?

2. Anonymous
  went through WG last call, will fix issues raised during last call,
  will submit with base spec. Sam  Hartman will send a summary of the
  last call to the working group after reviewing with the editor. 

3.  Plain/saslprep

  The main issue is the stringprep profile. More review is required,
  especially of the profile.

  Issue: SASLprep profile should deal with user@domain-name syntax
  issues.  IN particular many authentication identifiers and
  authorization  identifiers include domain components. We need to be
  aware of any differences between nameprep and saslprep and  avoid
  introducing these differences without good reason.  Nameprep works on
  domain labels, while saslprep works on the string as a whole.
  Applications may mistakenly perform nameprep on input before giving
  it to SASL.

  Issue: Want SASLprep and Kerberos prep to use the same namespace.

  Discussion of authorization  names vs authentication names.  Larry
  Greenfield believes that applications will use the same profile for
  both.  Kurt pointed out that  LDAP is an example of an application
  with significantly different requirements for authorization
  identifiers than authentication identifiers.

3. DIGEST-MD5 issues  Alexey is editor
  draft-ietf-sasl-rfc2831bis
  three open issues:
  1. Whether we want to merge AES cipher?
     Postpone selection of mandatory-to-implement and adding AES
     until we have done a security analysis.  Security analysis will
  be posted to the working group list.
  2. Add SASLprep.
  3. then ready for last call.

4. CRAM-MD5 draft   Lyndon is editor
  1. add SASLprep, then done.

5. GSSAPI issues    
  1. Last call the base32 draft, then last call.
  2. An editor needs to be selected.

6. Individual submissions
  Authors of SRP document want to last call it.
    Issue: Sam Hartman believes it should have structure which
  included an OID in front so it could be used as a GSSAPI mechanism. 

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: Sam Hartman <[email-masked]>
Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms
Date: Wed, 2 Apr 2003 09:33:44 +1100
Cc: SASL <[email-masked]>
Sender: [email-masked]

On Wednesday 02 April 2003 02:29, Sam Hartman wrote:
> >>>>> "Raif" == Raif S Naffah <[email-masked]> writes:
> ...
>     Raif> 2. what is the consensus on specifying/handling
>     Raif> authorization identities for transportation on the wire? 
> is Raif> [UNICODE-KC] enough?
>
> ...
> I think we would prefer that application profiles seriously consider
> the use of saslprep for authorization identifiers, but it is not
> right for all environments.

would a sequence of bytes preceded by their count (one additional byte) 
be enough?

cheers;
rsn

From: Keith Burdis <[email-masked]>
Reply-To: [email-masked]
To: SASL <[email-masked]>
Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms
Date: Tue, 1 Apr 2003 20:41:28 +0100
Cc: Sam Hartman <[email-masked]>;, [email-masked]
Sender: [email-masked]

It's a fun document :-) You have things like:

  MONGOLIAN TODO SOFT HYPHEN
  OGHAM SPACE MARK
  ARABIC END OF AYAH
  MUSICAL CONTROL CHARACTERS

Seriously, this looks to be a reasonable specification for usernames and 
passwords. Is there any reason why all mechanisms shouldn't use at least this 
set of restrictions? Why for example, would anonymous use a less restrictive 
profile?

  - Keith

On Tuesday 01 Apr 2003 17:29, Sam Hartman wrote:
> >>>>> "Raif" == Raif S Naffah <[email-masked]> writes:
>
>     Raif> hello there, can someone calrify the following:
>
>     Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a
>     Raif> needed transformation for authentication identities
>     Raif> (usernames) and passwords, in preference to something like:
>
>     Raif>    MUST be in Unicode Normalization Form KC [UNICODE-KC]
>     Raif> without NUL characters.
>
> Please read the stringprep document; it has a good discussion of the
> elements that go into a stringprep profile and I believe why they are
> needed.  If this is insufficient, please look at old minutes of the
> IDN working group and their archived mailing list.
>
> Note that mechanisms do not need to use the saslprep profile.  They
> need to adopt a stringprep profile that is appropriate for the
> mechanism in question.  For example anonymous uses a much less
> restrictive profile.
>
> Mechanisms using cryptography will tend to need fairly strong
> canonicalization rules to make sure that usernames and passwords typed
> with one set of input methods are handled the same when typed with a
> different set of methods.
>
>     Raif> wouldn't a transformation such as the SASLPrep be part of
>     Raif> the SASL Profile itself rather than the Mechanism(s)?
>
> If by SASL profile, you mean the profile for an application, no.  The
> form of authentication identifiers and other mechanism-specific
> strings such as passwords is entirely a matter for the mechanism.  As
> an example, Kerberos will mandate a particular stringprep profile for
> principals and passwords.  In order for things to work, the SASL
> GSSAPI mechanism for Kerberos must use the same stringprep profile.
>
>
>
>
>     Raif> 2. what is the consensus on specifying/handling
>     Raif> authorization identities for transportation on the wire?  is
>     Raif> [UNICODE-KC] enough?
>
>
>
> The authorization identity is a matter for the application's SASL
> profile.  In many cases, the same constraints will apply to
> authorization identities as authentication identities.  The
> transformation may end up being server-side rather than client-side,
> but will likely still be needed.
>
> I think we would prefer that application profiles seriously consider
> the use of saslprep for authorization identifiers, but it is not right
> for all environments.

To: [email-masked]
Cc: SASL <[email-masked]>
Subject: Re: authentication and authorization identities, and passwords in SASL Mechanisms
From: Sam Hartman <[email-masked]>
Date: Tue, 01 Apr 2003 11:29:56 -0500
Sender: [email-masked]

>>>>> "Raif" == Raif S Naffah <[email-masked]> writes:

    Raif> hello there, can someone calrify the following:

    Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a
    Raif> needed transformation for authentication identities
    Raif> (usernames) and passwords, in preference to something like:

    Raif>    MUST be in Unicode Normalization Form KC [UNICODE-KC]
    Raif> without NUL characters.

Please read the stringprep document; it has a good discussion of the
elements that go into a stringprep profile and I believe why they are
needed.  If this is insufficient, please look at old minutes of the
IDN working group and their archived mailing list.

Note that mechanisms do not need to use the saslprep profile.  They
need to adopt a stringprep profile that is appropriate for the
mechanism in question.  For example anonymous uses a much less
restrictive profile.

Mechanisms using cryptography will tend to need fairly strong
canonicalization rules to make sure that usernames and passwords typed
with one set of input methods are handled the same when typed with a
different set of methods.

    Raif> wouldn't a transformation such as the SASLPrep be part of
    Raif> the SASL Profile itself rather than the Mechanism(s)?

If by SASL profile, you mean the profile for an application, no.  The
form of authentication identifiers and other mechanism-specific
strings such as passwords is entirely a matter for the mechanism.  As
an example, Kerberos will mandate a particular stringprep profile for
principals and passwords.  In order for things to work, the SASL
GSSAPI mechanism for Kerberos must use the same stringprep profile.

    Raif> 2. what is the consensus on specifying/handling
    Raif> authorization identities for transportation on the wire?  is
    Raif> [UNICODE-KC] enough?

The authorization identity is a matter for the application's SASL
profile.  In many cases, the same constraints will apply to
authorization identities as authentication identities.  The
transformation may end up being server-side rather than client-side,
but will likely still be needed.

I think we would prefer that application profiles seriously consider
the use of saslprep for authorization identifiers, but it is not right
for all environments.

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: SASL <[email-masked]>
Subject: authentication and authorization identities, and passwords in SASL Mechanisms
Date: Tue, 1 Apr 2003 21:27:26 +1100
Sender: [email-masked]

hello there,

can someone calrify the following:

1. why does a SASL Mechanism has to mandate SASLPrep as a needed 
transformation for authentication identities (usernames) and passwords, 
in preference to something like:

   MUST be in Unicode Normalization Form KC [UNICODE-KC]
   without NUL characters.

wouldn't a transformation such as the SASLPrep be part of the SASL 
Profile itself rather than the Mechanism(s)?

2. what is the consensus on specifying/handling authorization identities 
for transportation on the wire?  is [UNICODE-KC] enough?

TIA + cheers;
rsn