Subject: Draft minutes

From: [email-masked] (Sam Hartman)
Date: Fri, 25 Jul 2003 16:06:48 -0400 (EDT)

Please send in comments or corrections by next Tuesday.  I will send
in for proceedings shortly after that point.

IETF SASL WG meeting Minutes
==========================

Tuesday 15 July 2003
3:45pm
chairs:    Sam Hartman <[email-masked]> Kurt Zeilenga <[email-masked]>
scribe: Luke Howard <[email-masked]>

2222bis
=======

- Alexei noted that he has published a subsequent revision of
  2222bis; minor editorial issues remain
- Clarification of empty authorization identities 
- Alexei will do a final revision of the document in the first
  week of August after which it can go to last call

saslprep
========

- Sam noted that current belief is that this will meet the needs
  of the Kerberos community
- The saslprep document is to be revised to include informational
  mapping tables but is otherwise ready for last call.  New revision
  is expected shortly after the meeting and the last call will follow
  shortly after it is announced.

DIGEST-MD5
==========

- DIGEST-MD5: Alexei noted that since the last revision he has
  made the following changes:
- Clarifications regarding character sets and authorization vs authentication 
  identities
- reference to saslprep the last revision has been
  updated
- Clarified RC4 cipher state is not reset between
  packets
- merged AES cipher document with this one
- no changes to solve the AES CBC mod attack:
  requested text be contributed once a solution is
  found. 
- The working group decided that AES for digest-md5 will use random IVs
  rather than counter mode.  Counter mode is harder to implement
  correctly.
- Questions from Sam regarding mandatory to implement
  ciphers: what should it be (if one is not already
  required)?
- Sam believes there will be interest in making   RC4  mandatory
  to implement   because it is implemented now;
  there is no security reason to not do so that he 
  was aware of
- Kurt noted a question as to whether security layers
  were mandatory to implement; not wearing his chair
  hat he suggested that at least integrity should be
  mandatory, Alexei noted that many mail clients do
  authentication only
- Chris Newman suggested that layers should not be
  mandatory because we already have TLS; suggest that
  vendors may remove support for DIGEST-MD5 entirely
  due to engineering cost of implementing layers
- Kurt suggested SHOULD implement integrity and that
  security considerations should note that you are
  subject to MITM without TLS or layers
- Noted that CRAM-MD5 is subject to the "evil server" 
  attach which DIGEST-MD5 is not because there is a
  client nonce; also DIGEST-MD5 being compatible with 
  HTTP digest has advantages. ie. there are sufficient
  advantages over CRAM-MD5 in spite of the lack of 
  layers being mandatory to implement
- Sam asked for consensus for deprecating both DES and
  triple DES. There were no objections, nor to taking
  them out of the document. Sam suggested that we note
  in the Security Considerations or Changes Since
  section as to why these were deprecated (preference
  for latter section)

GSSAPI
======

- Sam noted draft was "eaten by the secretariat"
- Plan is to move forward on it -- 00 to appear "soon"

CRAM-MD5
========

- A version with saslprep references is available

SASL Applicability Statement
============================

- Keith Burdis agreed to submit an SASL applicability statement as an
  individual submission.  His document will include comparisons of the
  various sasl mechanisms and their security properties. Sam agreed to
  propose an outline for the document.  The working group will discuss
  rechartering to include this document after the first revision.

To: [email-masked]
Subject: Draft minutes
Date: Fri, 25 Jul 2003 16:06:48 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Please send in comments or corrections by next Tuesday.  I will send
in for proceedings shortly after that point.

IETF SASL WG meeting Minutes
==========================

Tuesday 15 July 2003
3:45pm
chairs:    Sam Hartman <[email-masked]> Kurt Zeilenga <[email-masked]>
scribe: Luke Howard <[email-masked]>

2222bis
=======

- Alexei noted that he has published a subsequent revision of
  2222bis; minor editorial issues remain
- Clarification of empty authorization identities 
- Alexei will do a final revision of the document in the first
  week of August after which it can go to last call

saslprep
========

- Sam noted that current belief is that this will meet the needs
  of the Kerberos community
- The saslprep document is to be revised to include informational
  mapping tables but is otherwise ready for last call.  New revision
  is expected shortly after the meeting and the last call will follow
  shortly after it is announced.

DIGEST-MD5
==========

- DIGEST-MD5: Alexei noted that since the last revision he has
  made the following changes:
- Clarifications regarding character sets and authorization vs authentication 
  identities
- reference to saslprep the last revision has been
  updated
- Clarified RC4 cipher state is not reset between
  packets
- merged AES cipher document with this one
- no changes to solve the AES CBC mod attack:
  requested text be contributed once a solution is
  found. 
- The working group decided that AES for digest-md5 will use random IVs
  rather than counter mode.  Counter mode is harder to implement
  correctly.
- Questions from Sam regarding mandatory to implement
  ciphers: what should it be (if one is not already
  required)?
- Sam believes there will be interest in making   RC4  mandatory
  to implement   because it is implemented now;
  there is no security reason to not do so that he 
  was aware of
- Kurt noted a question as to whether security layers
  were mandatory to implement; not wearing his chair
  hat he suggested that at least integrity should be
  mandatory, Alexei noted that many mail clients do
  authentication only
- Chris Newman suggested that layers should not be
  mandatory because we already have TLS; suggest that
  vendors may remove support for DIGEST-MD5 entirely
  due to engineering cost of implementing layers
- Kurt suggested SHOULD implement integrity and that
  security considerations should note that you are
  subject to MITM without TLS or layers
- Noted that CRAM-MD5 is subject to the "evil server" 
  attach which DIGEST-MD5 is not because there is a
  client nonce; also DIGEST-MD5 being compatible with 
  HTTP digest has advantages. ie. there are sufficient
  advantages over CRAM-MD5 in spite of the lack of 
  layers being mandatory to implement
- Sam asked for consensus for deprecating both DES and
  triple DES. There were no objections, nor to taking
  them out of the document. Sam suggested that we note
  in the Security Considerations or Changes Since
  section as to why these were deprecated (preference
  for latter section)

GSSAPI
======

- Sam noted draft was "eaten by the secretariat"
- Plan is to move forward on it -- 00 to appear "soon"

CRAM-MD5
========

- A version with saslprep references is available

SASL Applicability Statement
============================

- Keith Burdis agreed to submit an SASL applicability statement as an
  individual submission.  His document will include comparisons of the
  various sasl mechanisms and their security properties. Sam agreed to
  propose an outline for the document.  The working group will discuss
  rechartering to include this document after the first revision.

To: Ken Murchison <[email-masked]>
Cc: Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: SRP security layer output
From: Sam Hartman <[email-masked]>
Date: Fri, 25 Jul 2003 13:05:52 -0400
Sender: [email-masked]

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

    Ken> I agree, but that's not what is stated in Section 5 paragraph
    Ken> 3:

    Ken>    "The data always passes through this three-stage filter,
    Ken> though any of the stages may be inactive.  Only when a stage
    Ken> is active would the output be different from the input.  In

That's true only so long as section 5 is being referenced.  Any other
reading implies that this mechanism spec updates the base SASL spec.

But I agree that the section on SASL should be clarified.

Date: Thu, 24 Jul 2003 20:35:07 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Sam Hartman <[email-masked]>
CC: Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: SRP security layer output
Sender: [email-masked]

Sam Hartman wrote:

> The SASL mech should never use section 5 with all layers disabled.  If
> the SASL mech is used without security layers, the application will
> never even pass the data to the SASL implementation.

I agree, but that's not what is stated in Section 5 paragraph 3:

   "The data always passes through this three-stage filter, though any of
    the stages may be inactive.  Only when a stage is active would the
    output be different from the input.  In other words, if a stage is
    inactive, the octet sequence at the output side is an exact duplicate
    of the same sequence at the input side."

This statement and the summary in Section 5.5 leads me to believe that 
the intention is to encode the data whether a security layer exists or 
not.  I disagree with this (and the needless wrapping of the data 
elements), which is why I proposed my change.

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

To: Ken Murchison <[email-masked]>
Cc: Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: SRP security layer output
From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jul 2003 17:37:30 -0400
Sender: [email-masked]

The SASL mech should never use section 5 with all layers disabled.  If
the SASL mech is used without security layers, the application will
never even pass the data to the SASL implementation.

Date: Wed, 23 Jul 2003 16:01:37 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: SRP security layer output
Sender: [email-masked]

After working through the draft again in detail and attempting to bring 
the CMU implementation up to date, I found that the documented security 
layer output is suboptimal.

The main problem that I found is that when no layer is active, the raw 
data still needs to be put into an EOS and then wrapped in a buffer. 
This means that the raw data would be prepended with three 4-byte 
lengths (counting the one already required by RFC 2222[bis]).  I'm 
pretty sure that the other mechs that support security layers don't 
require the raw data to be encoded/decoded when no layer is active.

I also don't see the point in wrapping the data segments into EOS and OS 
even when layers *are* active.  Given the fact that SASL already 
requires the 4-byte length prepended to the output, and we know that the 
size of the HMAC is fixed, why not just append the HMAC to the 
raw/encrypted data and send them as plain bytes?  The HMAC will always 
be the last 'hashlen' bytes and the data will always be the first 
'inputlen-hashlen' bytes.

So, I'm proposing this change to section 5.5 (Note that this eliminates 
the EOS data element from the spec):

       CP   IP   RD   Peer sends/receives

       I    I    I    bytes(p)
       I    A    I    bytes(p) | IALG(Ki)( bytes(p) )
       I    A    A    bytes(p) | IALG(Ki)( bytes(p) | bytes(q) )
       A    I    I    bytes(c)
       A    A    I    bytes(c) | IALG(Ki)( bytes(c) )
       A    A    A    bytes(c) | IALG(Ki)( bytes(c) | bytes(q) )

This allows applications and/or SASL implementations to short-circuit 
the no layer case (output = input) and potentially eliminates buffer 
copies resulting from the data wrapping.

Also, with regards to the table, I think it makes it easier to read if 
the inactive layers are shown without any symbol (eg, remove the 'I's).

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

To: Nicolas Williams <[email-masked]>
Cc: [email-masked], Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: Comments on draft-burdis-cat-srp-sasl-08.txt
From: Sam Hartman <[email-masked]>
Date: Wed, 23 Jul 2003 09:33:39 -0400
Sender: [email-masked]

To clarify, I don't believe that Nico's comments about mutual
authentication actually are specific to the GSSAPI mechanism.

The SRP SASL mechanism seems to only provide mutual authentication if
the same password and verifier is used only on one server.  I'm not
sure how appropriate this is for a SASL mechanism; it seems like you
will have difficulty distinguishing between servers in an organization
that have a common authentication infrastructure.

It seems that we can either:

1) Decide this is OK for SASL and thus OK for GSSAPI.

2) Decide that we don't actually get mutual authentication and remove that claim.

3) Fix the problem.

--Sam

Date: Wed, 23 Jul 2003 06:08:52 +0200
To: [email-masked]
From: Nicolas Williams <[email-masked]>
Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens
Sender: [email-masked]

The last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not
appropriately deal with GSS-API error tokens.

Yes, there is such a thing as GSS-API error tokens, that is,
GSS_Accept_sec_context() (and init too) can return a major status other
than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the
same time.

Such tokens SHOULD be sent.  Sending GSS-API error tokens makes
debugging errors a lot easier and results in error strings that make
sense being displayed to the user.

Also note: minor status codes are generally not standardized (certainly
not for the Kerberos V GSS mechanism) and so minor error codes should
not be sent on the wire as the peer may not be able to interpret them
correctly (this is definitely the case with the Kerberos mech).

Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I
will refrain from proposing actual text changes for now.

Cheers,

Nico
-- 

Date: Tue, 22 Jul 2003 18:20:35 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Cc: Sam Hartman <[email-masked]>
Subject: Comments on draft-burdis-cat-srp-sasl-08.txt
Sender: [email-masked]

The following comments all pertain to the GSS-API mechanism defined in
section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise
noted:

1.  Mutual Authentication & SRP GSS Principal Naming

   The I-D claims to provide mutual authentication, but does not provide
   for naming acceptors.

   While I appreciate that SRP provides mutual authentication, unless
   one can bind the SRP password and verifier to an acceptor name then
   the acceptor name MUST be of type GSS_C_NT_ANONYMOUS.

   Sam Hartman has proposed appending, prepending or otherwise stirring
   the acceptor name into the password as a way to achieve mutual
   authentication with non-anonymous acceptors.

   The I-D should explain the limitations of its mutual authentication
   provision and/or add acceptor naming to the protocol.  (See questions
   below.)

   Initiator naming should also be discussed.

   Additional questions:

   Should services be able to use this mechanism as initiators?

   How about optionally running the SRP protocol in both directions so
   that the initiator and acceptor can mutually authenticate without
   having to stir GSS-API names into the password/verifier?  The two
   exchanges would have to be mutually bound, sure, perhaps in the last
   message of the double exchange.  (In this case the verifiers could
   even be published, as long as they are distributed in a secure
   fashion.)

2.  Channel Bindings

   I imagine that the I-D authors may have thought that GSS channel
   bindings are an esoteric, barely used feature of the GSS-API.  A few
   months ago they have been correct.

   This is about to change; the use of GSS-API channel bindings is
   being formalized and given new life, see:

   http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

   If the protocol can be extended to accommodate integrity protected
   channel bindings I highly encourage you to do so.

   You can always define the encoding of the channel bindings by
   reference to RFC1964, module choice of hash function (this is how
   we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt).

3.  No Error Token Is Specified

   The GSS-API does, apparent widely spread assumptions notwithstanding,
   support the use of error tokens - i.e., output tokens emitted by
   gss_init_sec_context() or gss_accept_sec_context() when they also
   return a major status code other than GSS_S_COMPLETE or
   GSS_S_CONTINUE_NEEDED.

   This problem is significant.  Please fix.

4.  Obsoleted RFCs Do Not Make for Good Normative References

   This I-D references RFC2078 instead of RFC2743.  Please fix.  :)

Cheers,

Nico
-- 

Date: Tue, 22 Jul 2003 18:20:35 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Cc: Sam Hartman <[email-masked]>
Subject: Comments on draft-burdis-cat-srp-sasl-08.txt
Sender: [email-masked]

The following comments all pertain to the GSS-API mechanism defined in
section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise
noted:

1.  Mutual Authentication & SRP GSS Principal Naming

   The I-D claims to provide mutual authentication, but does not provide
   for naming acceptors.

   While I appreciate that SRP provides mutual authentication, unless
   one can bind the SRP password and verifier to an acceptor name then
   the acceptor name MUST be of type GSS_C_NT_ANONYMOUS.

   Sam Hartman has proposed appending, prepending or otherwise stirring
   the acceptor name into the password as a way to achieve mutual
   authentication with non-anonymous acceptors.

   The I-D should explain the limitations of its mutual authentication
   provision and/or add acceptor naming to the protocol.  (See questions
   below.)

   Initiator naming should also be discussed.

   Additional questions:

   Should services be able to use this mechanism as initiators?

   How about optionally running the SRP protocol in both directions so
   that the initiator and acceptor can mutually authenticate without
   having to stir GSS-API names into the password/verifier?  The two
   exchanges would have to be mutually bound, sure, perhaps in the last
   message of the double exchange.  (In this case the verifiers could
   even be published, as long as they are distributed in a secure
   fashion.)

2.  Channel Bindings

   I imagine that the I-D authors may have thought that GSS channel
   bindings are an esoteric, barely used feature of the GSS-API.  A few
   months ago they have been correct.

   This is about to change; the use of GSS-API channel bindings is
   being formalized and given new life, see:

   http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

   If the protocol can be extended to accommodate integrity protected
   channel bindings I highly encourage you to do so.

   You can always define the encoding of the channel bindings by
   reference to RFC1964, module choice of hash function (this is how
   we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt).

3.  No Error Token Is Specified

   The GSS-API does, apparent widely spread assumptions notwithstanding,
   support the use of error tokens - i.e., output tokens emitted by
   gss_init_sec_context() or gss_accept_sec_context() when they also
   return a major status code other than GSS_S_COMPLETE or
   GSS_S_CONTINUE_NEEDED.

   This problem is significant.  Please fix.

4.  Obsoleted RFCs Do Not Make for Good Normative References

   This I-D references RFC2078 instead of RFC2743.  Please fix.  :)

Cheers,

Nico
-- 

Date: Tue, 22 Jul 2003 16:54:39 -0500
From: Will Fiveash <[email-masked]>
To: [email-masked]
Cc: Jeff Moore <[email-masked]>
Subject: Fwd: [[email-masked]: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens]
Sender: [email-masked]

Since Nico isn't subscribed I'm forwarding this for him.
-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)

----- Forwarded message from Nicolas Williams <[email-masked]> -----

Date: Tue, 22 Jul 2003 13:28:16 -0700
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens
User-Agent: Mutt/1.4i

The last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not
appropriately deal with GSS-API error tokens.

Yes, there is such a thing as GSS-API error tokens, that is,
GSS_Accept_sec_context() (and init too) can return a major status other
than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the
same time.

Such tokens SHOULD be sent.  Sending GSS-API error tokens makes
debugging errors a lot easier and results in error strings that make
sense being displayed to the user.

Also note: minor status codes are generally not standardized (certainly
not for the Kerberos V GSS mechanism) and so minor error codes should
not be sent on the wire as the peer may not be able to interpret them
correctly (this is definitely the case with the Kerberos mech).

Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I
will refrain from proposing actual text changes for now.

Cheers,

Nico
-- 

----- End forwarded message -----

Date: Fri, 18 Jul 2003 12:33:14 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: draft-burdis-cat-srp-sasl-08
Sender: [email-masked]

Trying to bring Cyrus SASL in to compliance with the latest draft.  Here 
are some notes I put together after a thorough read of the auth 
exchange.  I may have more when I get into integrity and security.

Section 3.8:

>    When such entities travel on the wire, they shall be encoded as
>    4-octet Scalar Numbers.  We shall use the syntax uint(n) to denote
>    the encoding of an Unsigned Integer n.

In what byte-order?  I assume big-endian.

Section 4.5:

>    The server computes its evidence M2, which proves to the client that
>    it knows the shared context key K, as well as U, I and o, as follows:
                                                   ^^^

>             H(   bytes(A)
>                | bytes(M1)
>                | bytes(K)

Was U removed from the calculation on purpose, or was it an oversight? 
If its no longer part of the calculation, then it should be removed from 
the sentence describing M2.

>                | bytes(H( bytes(I) ))
>                | bytes(H( bytes(o) ))
>                | bytes(sid)

If sid is UTF8, should it be hashed, like I and o?

>                | ttl

Shouldn't this be bytes(ttl)?

>             )
> 
>    All parameters received from the client that are used as input to a
>    digest operation MUST be used as received.
> 
>    The server sends:
> 
>       { os(M2) | os(sIV) | sid | ttl }
                             ^^^^^^^^^^

Shouldn't this be utf8(sid) and uint(ttl)?

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

To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>
Subject: Re: Summary of the SASL working group meeting
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Jul 2003 11:21:27 -0400
Sender: [email-masked]

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

    Ken> Sam Hartman wrote:

    >> Keith Burdis agreed to submit an SASL applicability statement
    >> as an individual submission.  His document will include
    >> comparisons of the various sasl mechanisms and their security
    >> properties. Sam agreed to propose an outline for the document.
    >> The working group will discuss rechartering to include this
    >> document after the first revision.

    Ken> How will this document differ from the following?

    Ken> http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt

The IAB document seems to discuss mechanisms at a much lower level.  I
was invisioning comparing SASL to similar technologies like EAP,
GSSAPI and TLS.

And I was hoping to discuss sasl mechansims as sasl mechanisms.

We should definitely point to the IAB document and when discussing
mechanisms describe them in the category they fit into that framework.

Date: Wed, 16 Jul 2003 09:35:50 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: Re: Summary of the SASL working group meeting
Sender: [email-masked]

Sam Hartman wrote:

> Keith Burdis agreed to submit an SASL applicability statement as an
> individual submission.  His document will include comparisons of the
> various sasl mechanisms and their security properties. Sam agreed to
> propose an outline for the document.  The working group will discuss
> rechartering to include this document after the first revision.

How will this document differ from the following?

http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt

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

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Summary of the SASL working group meeting
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Jul 2003 04:06:23 -0400
Sender: [email-masked]

The SASL working group met on Tuesday for one hour.

The document editor of RFC 2222bis (Alexei) will publish a revision in
the first week of August at which point we will last call it.
The saslprep document is to be revised to include informational
mapping tables but is otherwise ready for last call.  New revision
is expected shortly after the meeting and the last call will follow
shortly after it is announced.

Working group participants who made comments during the plain or
anonymous last call need to make sure their comments are reflected in
the current document.  The document editor believes that the working
group is done with these two documents although we are not sending
them to the IESG at this time.

The working group decided that AES for digest-md5 will use random IVs
rather than counter mode.  Counter mode is harder to implement
correctly.

There is likely to be interest in making the RC4 cipher
mandatory-to-implement for implementations that support
confidentiality with digest-md5.  The RC4 cipher is interoperable with
existing implementations and  we did not find any problems during the
security review conducted after the last meeting.

Currently, neither integrity protection nor confidentiality is
mandatory-to-implement.  At least one participant said he would remove
digest-md5 support rather than implement integrity.  The argument is
that you can just use TLS.  However, if you just use TLS, you need to
depend on TLS to authenticate the server to the client or you have a
man-in-the-mdille problem.  This will be discussed on the list.

The working group reached a consensus at the meeting to deprecate DES
and 3DES because they are insecure.

Larry submitted a 00 version of the GSSAPI draft, but it did not
appear.  He will resubmit in the near future.

Keith Burdis agreed to submit an SASL applicability statement as an
individual submission.  His document will include comparisons of the
various sasl mechanisms and their security properties. Sam agreed to
propose an outline for the document.  The working group will discuss
rechartering to include this document after the first revision.

Subject: Re: Global state and libsasl
From: Greg Hudson <[email-masked]>
To: Jeff Moore <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Organization: 
Date: 15 Jul 2003 12:22:00 -0400
Sender: [email-masked]

On Tue, 2003-07-15 at 11:25, Jeff Moore wrote:
> int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks);

What's with the leading underscores?  Symbols like that are reserved for
external linkage by the ANSI C standard.

Date: Tue, 15 Jul 2003 08:25:12 -0700
From: Jeff Moore <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Global state and libsasl
Sender: [email-masked]

As has been previously discussed, libsasl maintains global state
which can cause problems when both an application and one of its
libraries use libsasl.

The most recent suggestions on how to deal with this issue in a
compatible way do not seem to address all the issues with global
state in the Cyrus libsasl implementation.

The Cyrus 2.x libsasl implementation uses global state for the
following:

1. Loading plugins
        If an application decides which plugins to load and how to
        configure them, any other consumers of libsasl may not not
        have their needs met. Additionally, some plugins may be
        specific to a given application or library. They may not
        want the plugin to be used by other components.

        There are a number of ways there could be problems:

        a. Location of plugins (SASL_CB_GETPATH)
                Through the SASL_CB_GETPATH callback. If this callback
                is specified, libsasl will use the specified path to
                locate plugins. The specified path may not include the
                standard plugins - or it may include "private" plugins.
        b. Verification of plugins/configuration (SASL_CB_VERIFYFILE)
                Through the SASL_CB_VERIFYFILE callback. What one
                component may accept another might reject.
        c. logging of non-connection oriented problems (SASL_CB_LOG)
                 libraries will not be able to report these sorts of
                 problems themselves.
        d. Setting any global plugin configuration data:
                e.g. DIGEST-MD5 - reauth_timeout,
                     GSSAPI - keytab
                     KERBEROS_4 - srvtab
                     SRP - srp_mda
                The way to set these today is via the getopt function
                registered in the global callback. Also note that for
                things like reauth_timeout, you may not want to share
                it between different components.
        e. Loading application/library specific plugins
                Any plugin that is loaded via sasl_xxx_add_plugin will be
                available to application or libraries.
        f. Loading application/library private plugins

2. memory allocation
        sasl_set_alloc() setting memory allocation functions may have
        unintended interactions between application and libraries. If
        the library has already used libsasl to perform some memory
        allocations before the application has set sasl_set_alloc(),
        bad things may happen.
        
3. mutex functions
        sasl_set_mutex() setting mutex allocation functions may have
        unintended interactions between applications and libraries. If
        this function is a MUST, what should a library do? 

4. sasl_xxx_init() and sasl_done()
        Count of usage may deal with this - although no separation
        between client and server and potential for misbehaving
        applications/libraries to break others.

5. Global callbacks
        If specified, they will apply to both application and libraries.
        The application's global callbacks may end up handling callbacks
        for the library. If, as has been proposed, that libraries should
        not use global callbacks, the application will not see this
        problem.

6. Server sasl option configuration file
        Just as with global callbacks, options may be set for library that
        are not expected or wanted.

7. Requirement of non-thread-safe initialization.

Ideally, we would all like to see the global state problem be solved
with a minimum of changes to the existing semantics. One way to address
much of the above is to introduce a sasl global context that would be
inferred by the current sasl API, but which would allow libraries (or
applications) to use libsasl independently of each other. (There are
additional issues for sasl_set_alloc() and sasl_set_mutex().)

This approach would introduce a  number of new functions:

void *sasl_create_context(void)

Create a sasl global context - the current global state would be now
associated with the created context.

void sasl_free_context(void *ctx)

Release all resources associated with the sasl global context. This would
be semantically the same as the current sasl_done().

int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks);

Initialize the sasl global context for sasl client access.

int _sasl_client_new(void *ctx, const char *service, ...)

Create a sasl client connection using the sasl global context.

int _sasl_server_init(void *ctx, const sasl_callback_t *callbacks, ...);

Initialize the sasl global context for sasl server access.

int _sasl_server_new(void *ctx, const char *service, ...)

Create a sasl server connection using the sasl global context.

int _sasl_client_add_plugin(void *ctx, const char *plugname, ...);
int _sasl_server_add_plugin(void *ctx, const char *plugname, ...);
int _sasl_canonuser_add_plugin(void *ctx, const char *plugname, ...);
int _sasl_auxprop_add_plugin(void *ctx, const char *plugname, ...);

Add plugins to the sasl global context

The functions sasl_set_mutex() and sasl_global_listmech() would be
deprecated.

If sasl_set_alloc() is not deprecated, then _sasl_set_alloc(void *ctx, ...)
could be defined.

This approach would preserve the existing semantic and avoid: global
state issues when a library initializes the libsasl before the
application, the potential problem of applications getting callbacks for
libraries and plugins installed by one component being available for use
by other components.

Cheers,

Jeff

Date: Mon, 14 Jul 2003 03:56:41 +0200
To: "William Curley" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL w/auxprop(mysql) and shadow {Scanned}
Cc: <[email-masked]>
Sender: [email-masked]

As this list is for discussion regarding current and future SASL standardization efforts and, in particular, the work of the IETF
SASL working group, your post is off topic.  I suggest you direct
your post to a list concerning CMU's Cyrus SASL implementation,
e.g., <[email-masked]>.

Kurt, IETF SASL WG co-chair

At 04:24 AM 7/12/2003, William Curley wrote:
>I am trying to allow Postfix to authenticate via SASL to send email, SASL will either use the local shadow file or a mysql database to do the authentication. I currently have this setup more or less using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since it appears to support this. I understand that auxprop can connect to a mysql database, how do I start auxprop so it can do this? Or do I need to do this? With both pwcheck and saslauthd I've had to have the daemons running for it to work. Lastly, is it even possible to have SASL try to authenticate to both shadow and mysql at the same time? Thanks kindly for any light you can shed on this.
> 
> 
>William Curley
><mailto:[email-masked]>[email-masked]
>http://www.dodgethis.org - Free email and more.

Date: Fri, 11 Jul 2003 16:41:12 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: [email-masked]
Subject: Re: Proposed Agenda
Sender: [email-masked]

Alexey Melnikov wrote:

> Can we also have a virtual "show of hands" for people who are planning to attend?
> Please send replies to me and I will post the list to the mailing list.

So far I've received only two replies from Sam Hartman and Keith Burdis.
Kurt Zeilenga should be also in Vienna.

Alexey

From: "William Curley" <[email-masked]>
To: <[email-masked]>
Subject: SASL w/auxprop(mysql) and shadow {Scanned}
Date: Fri, 11 Jul 2003 19:24:56 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C347E2.1C5D6690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am trying to allow Postfix to authenticate via SASL to send email, =
SASL will either use the local shadow file or a mysql database to do the =
authentication. I currently have this setup more or less using =
'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since =
it appears to support this. I understand that auxprop can connect to a =
mysql database, how do I start auxprop so it can do this? Or do I need =
to do this? With both pwcheck and saslauthd I've had to have the daemons =
running for it to work. Lastly, is it even possible to have SASL try to =
authenticate to both shadow and mysql at the same time? Thanks kindly =
for any light you can shed on this.

William Curley
[email-masked]
http://www.dodgethis.org - Free email and more.
------=_NextPart_000_0007_01C347E2.1C5D6690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I am trying to allow Postfix to =
authenticate via=20
SASL to send email, SASL will either use the local shadow file or a =
mysql=20
database to do the authentication. I currently have this setup more or =
less=20
using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL =
since=20
it appears to support this. I understand that auxprop can connect to a =
mysql=20
database, how do I start auxprop so it can do this? Or do I need to do =
this?=20
With both pwcheck and saslauthd I've had to have the daemons running for =
it to=20
work. Lastly, is it even possible to have SASL try to authenticate to =
both=20
shadow and mysql at the same time? Thanks kindly for any light you can =
shed on=20
this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>William Curley<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR><A=20
href=3D"http://www.dodgethis.org">http://www.dodgethis.org</A> - Free =
email and=20
more.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0007_01C347E2.1C5D6690--

Date: Thu, 10 Jul 2003 15:07:18 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed Agenda
Sender: [email-masked]

Sam Hartman wrote:

> People should speak up today if there are other issues that need to be covered.
>
>         1) preliminary stuff - 5m
>         2) 2222bis - 15m
>         3) saslprep - 15m
>         4) other issues - 15m

>         5) open mic - remainder

There is a 50% chance that I will not be in Vienna (and there is some probability
that even if I will be, I might miss the SASL meeting). Any takers to serve as
proxy for me (i.e. 2222bis document and DIGEST-MD5)?

Can we also have a virtual "show of hands" for people who are planning to attend?
Please send replies to me and I will post the list to the mailing list.

I am not sure what is included in "other issues", but some potential topics for
discussion:
1). SASL C API (out of scope, but a lot of discussion lately)
2). Status of GSSAPI draft now that the base32 document is an RFC?

Also, I've asked Application Area ADs for a slot to talk about HTTP SASL during
Application Area Open Meeting on Monday. Assuming there is time, Peter Yee from RSA
will present if I am not present.

Cheers,
Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

To: [email-masked]
Subject: Proposed Agenda
From: Sam Hartman <[email-masked]>
Date: Mon, 07 Jul 2003 13:23:33 -0400
Sender: [email-masked]

People should speak up today if there are other issues that need to be covered.

        1) preliminary stuff - 5m
        2) 2222bis - 15m
        3) saslprep - 15m
        4) other issues - 15m
        5) open mic - remainder

To: Alexey Melnikov <[email-masked]>
Cc: Greg Hudson <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
From: Sam Hartman <[email-masked]>
Date: Sun, 06 Jul 2003 00:51:02 -0400
Sender: [email-masked]

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

    Alexey> Ok people.  I am afraid we are starting a religious war at
    Alexey> this point and this is not going to do us any good.

If this were a WG item I'd disagree that anyone was proposing a
religious war.  I'd comment that there seems to be an unspecified
requirement behind the global getopt callback.  I'd ask the proponents
of that callback to describe clearly what problem it was trying to
solve.

Then, I'd see if the WG could reach consensus on whether that problem
was a good thing to solve in a standards track API.

If the WG reached consensus on a problem and agreed the problem was
worth solving, then we would look at whether the getopt callback
actually solved that problem.

But this document is not a WG item; you can use whatever procedure you
like to decide its contents.

Date: Fri, 04 Jul 2003 08:43:53 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 11:35 AM 7/3/2003, Rob Siemborski wrote:

>On Wed, 2 Jul 2003 [email-masked] wrote:
>
>
>>       Title           : The Anonymous SASL Mechanism
>>       Author(s)       : K. Zeilenga
>>       Filename        : draft-ietf-sasl-anon-02.txt
>
>>>
>...not part of SASL itself.  Newer profiles of SASL will include the
>client message with the AUTHENTICATE command itself so the extra round
>trip below (the server response with an empty "+ ") can be eliminated.
><<
>
>Seems to indicate a requirement on new SASL profiles, which is outside of
>the scope of the document.  However, it is reasonable to add some
>clarification that the extra round trip is an artifact of the IMAP
>profile.
>
>How about something more like:
>
>...not part of SASL itself.  Additionally, protocols with SASL profiles
>permitting an initial client response will be able to avoid the extra
>round trip below (the server response with an empty "+ ").

This sounds like a reasonable suggestion...

Kurt 

Date: Fri, 4 Jul 2003 11:37:47 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Fri, 4 Jul 2003, Greg Hudson wrote:

> > I also worry a bit about sasl_xxx_init not being required to be called
> > from a single non-threaded environment, since in order to simulate this
> > the library would need to lock around it.  If sasl_set_mutex has been
> > called, presumably this means that sasl_set_mutex allocates the necessary
> > mutex, but now we can never release this mutex safely (well, unless
> > sasl_set_mutex was called again with all NULL values, I suppose).  This
> > may not be a practical concern.
>
> pthreads allows you to create a statically intialized mutex.  You'd
> never release such a beast; you'd just use it to lock around
> non-thread-safe operations.

That's true.

However, if sasl_set_mutex *is* called we have no way of staticly
allocating a mutex, since we have to dynamicly call the init function to
get the proper mutex (and we may not be using pthread mutexes).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 04 Jul 2003 11:27:20 -0400
Sender: [email-masked]

I understand not wanting to make incompatible changes to the API at this
time.

On Fri, 2003-07-04 at 11:16, Rob Siemborski wrote:
> If this change allows for implementations to advertise thread safety only
> if sasl_set_mutex is called (from a non-threaded environment), I'm at least
> willing to talk about this.

Well, as long as they're clear, they can hedge all they want, I suppose.

> I also worry a bit about sasl_xxx_init not being required to be called
> from a single non-threaded environment, since in order to simulate this
> the library would need to lock around it.  If sasl_set_mutex has been
> called, presumably this means that sasl_set_mutex allocates the necessary
> mutex, but now we can never release this mutex safely (well, unless
> sasl_set_mutex was called again with all NULL values, I suppose).  This
> may not be a practical concern.

pthreads allows you to create a statically intialized mutex.  You'd
never release such a beast; you'd just use it to lock around
non-thread-safe operations.

> The callbacks argument is the default list of callbacks (see section 3.1.1
> for definition of sasl_callback_t structure).  Libraries that are clients
> of the API MUST supply NULL For this parameter.  Applications that are
> clients of the API MAY supply a list that includes the sasl_getopt_t
> callback, but MUST NOT supply any other callbacks through this interface.

That looks okay to me.

Date: Fri, 4 Jul 2003 11:16:00 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Fri, 4 Jul 2003, Greg Hudson wrote:

> On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote:
> > Sorry, forgot about that. Either an application should pass NULL as a library (and
> > new function is introduced for setting getopt as described), or the application is
> > only allowed to set getopt as a global callback. In this case interaction between
> > global callbacks and local one should be documented.
>
> It sounds like we get the simplest transition if we make the changes:
>
>   * Libraries must pass NULL for the global callbacks.
>   * Applications must pass NULL, or only a getopt callback.
>   * Applications MAY pass a getopt callback, but we don't say they
>     SHOULD.
>
> Existing SASL implementations don't have to do anything except modify
> their documentation.

I'm okay with this.

> To resolve my other issue while still preserving the ability to use a
> non-standard thread library:
>
>   * sasl_set_mutex() becomes optional, but must be called from the
>     initial single-threaded environment if it is called at all.  If
>     it is not called, the library will use the most standard native
>     thread APIs to protect any internal global state.
>   * sasl_*_init() no longer needs to be called from the initial
>     single-threaded environment.
>
> This change is more burdensome.for existing implementations which have
> internal global state to protect; they must use threads (I'm told the
> pthreads API works under Windows, but I don't know how advisable it is
> to use it) and introduce a link-time dependency on a threads library.
> But the API does then become safely usable from a library.
>
> (I am okay with allowing implementations to simply not advertise thread
> safety, in which case they don't need to implement their own locks.)

If this change allows for implementations to advertise thread safety only
if sasl_set_mutex is called (from a non-threaded environment), I'm at least
willing to talk about this.

First, I think that calling sasl_set_mutex needs to be a "SHOULD" and not
"OPTIONAL".

I also worry a bit about sasl_xxx_init not being required to be called
from a single non-threaded environment, since in order to simulate this
the library would need to lock around it.  If sasl_set_mutex has been
called, presumably this means that sasl_set_mutex allocates the necessary
mutex, but now we can never release this mutex safely (well, unless
sasl_set_mutex was called again with all NULL values, I suppose).  This
may not be a practical concern.

> These changes do not turn the API into a shining example of standard API
> design in my book, of course; they are merely proposed as a practical
> compromise.

As you can probably understand, its really hard for me to not oppose
significant changes in the API as we try to standardize it.  We've already
implemented two substantially different SASL APIs, I'm not looking forward
to doing it a third time, especially given the deployment we currently
have.

Making it usable is one thing (for which I am willing to compromise),
however making it a "shining example of API design" in ways that are not
backwards compatible, just for the sake of doing so is probably going to
see pushback.

>    The most important callback is the "getopt" callback (see
>    section 3.3.3) which is used to retrieve security policy option set-
>    tings from the caller's preferences.
>
> This text worries me because the getopt callback is referred to as
> "important" and because security policy should be retrieved through a
> fully standard interface.  (That may require a lot of work; I haven't
> thought about that problem in great detail.)  Imagine trying to build an
> application which has a GUI to configure security policy preferences
> using the current design.

I tend to agree that "security policy" decisions should be done through
standard interfaces.  Of course, if things like telling the mechanisms
what database to pull user secrets from (or how to authenticate to that
database, or so on) is a "security policy" decision, we're going to have
problems defining any standard interface to deal with this.

I think this sentence can just be eliminated, it doesn't really add
anything useful to section 3.3.1.

>       The callbacks argument is the default list of callbacks (see sec-
>       tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD
>       include the sasl_getopt_t callback (see section 3.3.3).
>
> This text worries me because, again, it seems to expect that the
> implementation will really want to see a getopt callback and will behave
> only minimally usefully without one.

I'm willing to change SHOULD to a MAY here (for applications), and MUST
NOT (for libraries).

Something like:

The callbacks argument is the default list of callbacks (see section 3.1.1
for definition of sasl_callback_t structure).  Libraries that are clients
of the API MUST supply NULL For this parameter.  Applications that are
clients of the API MAY supply a list that includes the sasl_getopt_t
callback, but MUST NOT supply any other callbacks through this interface.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 04 Jul 2003 10:46:03 -0400
Sender: [email-masked]

On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote:
> Sorry, forgot about that. Either an application should pass NULL as a library (and
> new function is introduced for setting getopt as described), or the application is
> only allowed to set getopt as a global callback. In this case interaction between
> global callbacks and local one should be documented.

It sounds like we get the simplest transition if we make the changes:

  * Libraries must pass NULL for the global callbacks.
  * Applications must pass NULL, or only a getopt callback.
  * Applications MAY pass a getopt callback, but we don't say they
    SHOULD.

Existing SASL implementations don't have to do anything except modify
their documentation.

To resolve my other issue while still preserving the ability to use a
non-standard thread library:

  * sasl_set_mutex() becomes optional, but must be called from the
    initial single-threaded environment if it is called at all.  If
    it is not called, the library will use the most standard native
    thread APIs to protect any internal global state.
  * sasl_*_init() no longer needs to be called from the initial
    single-threaded environment.

This change is more burdensome.for existing implementations which have
internal global state to protect; they must use threads (I'm told the
pthreads API works under Windows, but I don't know how advisable it is
to use it) and introduce a link-time dependency on a threads library. 
But the API does then become safely usable from a library.

(I am okay with allowing implementations to simply not advertise thread
safety, in which case they don't need to implement their own locks.)

These changes do not turn the API into a shining example of standard API
design in my book, of course; they are merely proposed as a practical
compromise.

Rob Siemborski wrote:
> So option names would still be non-standard?  Doesn't this not address
> Greg's concern then?

There are my concerns about the API's practical usability from a
library, and there are my concerns about good design of a standard API,
and I haven't kept them separate in this discussion.  The former
concerns are mostly objective, but it's clear that the other members of
this working group don't agree with me on the latter concerns, so I will
try to stick to the former.

With that proviso, having a pseudo-standardized getopt() is okay as long
as we don't enforce its use by callers.  So I have concerns with the
following text in the current draft:

   The most important callback is the "getopt" callback (see
   section 3.3.3) which is used to retrieve security policy option set-
   tings from the caller's preferences.

This text worries me because the getopt callback is referred to as
"important" and because security policy should be retrieved through a
fully standard interface.  (That may require a lot of work; I haven't
thought about that problem in great detail.)  Imagine trying to build an
application which has a GUI to configure security policy preferences
using the current design.

      The callbacks argument is the default list of callbacks (see sec-
      tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD
      include the sasl_getopt_t callback (see section 3.3.3).

This text worries me because, again, it seems to expect that the
implementation will really want to see a getopt callback and will behave
only minimally usefully without one.

Date: Fri, 04 Jul 2003 08:32:31 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Rob Siemborski <[email-masked]>
CC: Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Rob Siemborski wrote:

> On Fri, 4 Jul 2003, Alexey Melnikov wrote:
>
> > > I don't see how this is better than allowing a getopt() callback to be set
> > > by the application, but not by libraries in the call to sasl_xxx_init().
> >
> > Would you rather allow getopt (and only getopt) to be set by the
> > application when calling a sasl_xxx_init() and a library using SASL
> > always pass NULL as callbacks?
>
> Yes, since it is much closer to what is currently done, and I don't see
> the gain of adding a separate "set getopt" function which needs to be
> called before sasl_xxx_init anyway.  If there's a concrete gain that
> justified the change in code, I'd be less opposed.
>
> > > Not quite true, this requires standardizing the name of an option, as
> > > well.
> >
> > I meant in Cyrus SASL library, not the document.
>
> So option names would still be non-standard?  Doesn't this not address
> Greg's concern then?

I think it should be standard, but Greg wouldn't care :-).

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Fri, 4 Jul 2003 10:29:31 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Fri, 4 Jul 2003, Alexey Melnikov wrote:

> > I don't see how this is better than allowing a getopt() callback to be set
> > by the application, but not by libraries in the call to sasl_xxx_init().
>
> Would you rather allow getopt (and only getopt) to be set by the
> application when calling a sasl_xxx_init() and a library using SASL
> always pass NULL as callbacks?

Yes, since it is much closer to what is currently done, and I don't see
the gain of adding a separate "set getopt" function which needs to be
called before sasl_xxx_init anyway.  If there's a concrete gain that
justified the change in code, I'd be less opposed.

> > Not quite true, this requires standardizing the name of an option, as
> > well.
>
> I meant in Cyrus SASL library, not the document.

So option names would still be non-standard?  Doesn't this not address
Greg's concern then?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 04 Jul 2003 06:38:57 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Greg Hudson <[email-masked]>
CC: [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Greg Hudson wrote:

> On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote:
> > So, how about making some constructive suggestions. How about the following:
> > 1). libraries MUST NOT specify callbacks when calling
> > sasl_client_init/sasl_server_init.
> > Global callbacks are thus deprecated.
>
> You seem to leave open the question of whether applications are allowed
> to specify callbacks.

Sorry, forgot about that. Either an application should pass NULL as a library (and
new function is introduced for setting getopt as described), or the application is
only allowed to set getopt as a global callback. In this case interaction between
global callbacks and local one should be documented.

>  Was that intentional?

No.

> (As I've mentioned before, if applications are allowed to set global
> callbacks, then a library using SASL cannot guard against accidentally
> triggering the application global callbacks.)
>
> > 2). a new function is added to set getopt callback. An application that doesn't
> > care about getopt, will not call this function.
>
> Well, as everybody knows, my religion does not include such a device,
> but global state is generally not burdensome as long as it's
> (completely) optional.  So I won't scream and yell about it.

I was hoping for this :-).

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Fri, 04 Jul 2003 06:18:17 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Rob Siemborski <[email-masked]>
CC: Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Rob Siemborski wrote:

> On Thu, 3 Jul 2003, Alexey Melnikov wrote:
>
> > Ok people. I am afraid we are starting a religious war at this point and
> > this is not going to do us any good.
>
> I agree.
>
> > So, how about making some constructive suggestions. How about the following:
> > 1). libraries MUST NOT specify callbacks when calling
> > sasl_client_init/sasl_server_init.
> > Global callbacks are thus deprecated.
> >
> > 2). a new function is added to set getopt callback. An application that
> > doesn't care about getopt, will not call this function. If this callback
> > is not set, the SASL library will use reasonable defaults or get the
> > required information from own config file/environment/registry/whatever.
> >
> > 3). one of the getopt options is a plugin directory. If the application doesn't
> > care, its getopt callback will fail to return the value for this option. The
> > SASL library will choose a reasonable default in this case. If the SASL library
> > doesn't support plugins, it will not care about this option.
>
> This is worse than the global callbacks scenario with libraries forbidden
> from setting global callbaks, since in this situation a libary can call
> the magic new function to set the getopt() callback.

IMHO, it is not different.

You can't prevent libraries or applications from doing stupid things, you can only
advise them how to avoid problems.

> I don't see how this is better than allowing a getopt() callback to be set
> by the application, but not by libraries in the call to sasl_xxx_init().

Would you rather allow getopt (and only getopt) to be set by the application when
calling a sasl_xxx_init()
and a library using SASL always pass NULL as callbacks?

> Even if we forbid libraries from calling this new function, the situation
> is worse than allowing applications to set a getopt callback in their call
> to sasl_xxx_init(), as it requires changes from current practice.
>
> > I believe this is how it works now anyway (except for new function for setting
> > getopt).
>
> Not quite true, this requires standardizing the name of an option, as
> well.

I meant in Cyrus SASL library, not the document.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Thu, 3 Jul 2003 18:44:10 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Thu, 3 Jul 2003, Alexey Melnikov wrote:

> Ok people. I am afraid we are starting a religious war at this point and
> this is not going to do us any good.

I agree.

> So, how about making some constructive suggestions. How about the following:
> 1). libraries MUST NOT specify callbacks when calling
> sasl_client_init/sasl_server_init.
> Global callbacks are thus deprecated.
>
> 2). a new function is added to set getopt callback. An application that
> doesn't care about getopt, will not call this function. If this callback
> is not set, the SASL library will use reasonable defaults or get the
> required information from own config file/environment/registry/whatever.
>
> 3). one of the getopt options is a plugin directory. If the application doesn't
> care, its getopt callback will fail to return the value for this option. The
> SASL library will choose a reasonable default in this case. If the SASL library
> doesn't support plugins, it will not care about this option.

This is worse than the global callbacks scenario with libraries forbidden
from setting global callbaks, since in this situation a libary can call
the magic new function to set the getopt() callback.

I don't see how this is better than allowing a getopt() callback to be set
by the application, but not by libraries in the call to sasl_xxx_init().

Even if we forbid libraries from calling this new function, the situation
is worse than allowing applications to set a getopt callback in their call
to sasl_xxx_init(), as it requires changes from current practice.

> I believe this is how it works now anyway (except for new function for setting
> getopt).

Not quite true, this requires standardizing the name of an option, as
well.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 03 Jul 2003 18:42:56 -0400
Sender: [email-masked]

On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote:
> So, how about making some constructive suggestions. How about the following:
> 1). libraries MUST NOT specify callbacks when calling
> sasl_client_init/sasl_server_init.
> Global callbacks are thus deprecated.

You seem to leave open the question of whether applications are allowed
to specify callbacks.  Was that intentional?

(As I've mentioned before, if applications are allowed to set global
callbacks, then a library using SASL cannot guard against accidentally
triggering the application global callbacks.)

> 2). a new function is added to set getopt callback. An application that doesn't
> care about getopt, will not call this function.

Well, as everybody knows, my religion does not include such a device,
but global state is generally not burdensome as long as it's
(completely) optional.  So I won't scream and yell about it.

Date: Thu, 03 Jul 2003 16:27:30 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Greg Hudson <[email-masked]>
CC: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Greg Hudson wrote:

> On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote:
> > Are you saying its better to have NO standard way to get configuration
> > information into the library fromt he application?
>
> Absolutely.  The vast majority of APIs contain no such mechanism,
> because a library should be able to do its job without creating such a
> mechanism.  If for some reason the library needs configuration, it can
> get it via its own configuration files, which it can find through
> mechanisms not involving the calling code (fixed paths, environment
> variables, the registry, etc.).

I am afraid I disagree. Centralizing all configuration for an application in
one place might be a good (and required) thing.

> The only exception class tends to be gui toolkits, which usually want to
> take over the command line by accepting and modifying argc and argv.
> I'm ambivalent about this practice (it makes it harder to document the
> command-line syntax of programs using the gui toolkit, but it's hard to
> imagine doing without it given the variety of standard command-line
> arguments affecting the toolkit), but it's not terribly onerous because
> a GUI toolkit tends to dominate the scope and structure of an
> application.  Not so with a SASL library.
>
> >   Thus, if I want an
> > application to work with two types of libraries, I have to provide (in
> > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and
> > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation?
>
> If we are talking about an application providing this information for
> its own reasons, then it's already sunk; the SASL API says nothing about
> plugin paths, you don't know what option name would be involved, and the
> implementation might not even use plugins.  (And of course, if the
> application is providing such information for its own reasons, it
> probably cares about the back-end plugin interface, which isn't
> specified at all.)
>
> But, of course, the specifiers are not envisioning an application
> providing this information for its own reasons; they are envisioning an
> application blindly (no stigma here) passing along user configuration,
> as reflected here:

Ok people.
I am afraid we are starting a religious war at this point and this is not going
to do us any good.

So, how about making some constructive suggestions. How about the following:
1). libraries MUST NOT specify callbacks when calling
sasl_client_init/sasl_server_init.
Global callbacks are thus deprecated.
2). a new function is added to set getopt callback. An application that doesn't
care about getopt, will not call this function. If this callback is not set,
the SASL library will use reasonable defaults or get the required information
from own config file/environment/registry/whatever.
3). one of the getopt options is a plugin directory. If the application doesn't
care, its getopt callback will fail to return the value for this option. The
SASL library will choose a reasonable default in this case. If the SASL library
doesn't support plugins, it will not care about this option.

I believe this is how it works now anyway (except for new function for setting
getopt).

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Thu, 3 Jul 2003 14:35:02 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt
Sender: [email-masked]

On Wed, 2 Jul 2003 [email-masked] wrote:

> 	Title		: The Anonymous SASL Mechanism
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-ietf-sasl-anon-02.txt

...not part of SASL itself.  Newer profiles of SASL will include the
client message with the AUTHENTICATE command itself so the extra round
trip below (the server response with an empty "+ ") can be eliminated.
<<

Seems to indicate a requirement on new SASL profiles, which is outside of
the scope of the document.  However, it is reasonable to add some
clarification that the extra round trip is an artifact of the IMAP
profile.

How about something more like:

...not part of SASL itself.  Additionally, protocols with SASL profiles
permitting an initial client response will be able to avoid the extra
round trip below (the server response with an empty "+ ").

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 03 Jul 2003 13:20:26 -0400
Sender: [email-masked]

On Thu, 2003-07-03 at 13:15, Rob Siemborski wrote:
> However, in your scenario all the applications running on a system need to
> share the same global configuration with no possibility of making
> application-specific changes.  Which really isn't acceptable.

Why not?  There is no application-specific configuration for krb5, or
for the resolver, or for a host of other libraries.  (You can, of
course, hack it up using environment variables and alternate config
files, but people rarely seem to.)

If you actually can come up with a practical reason to have
application-specific configuration for a SASL library (a concept which
doesn't make a lot of sense when SASL is being driven from another
library), then it is *still* better to handle this from a SASL-specific
configuration file, using options keyed off the application name,
because then it's possible to write documentation and GUI tools which
understand everything about the config file, unlike in your scheme.

Date: Thu, 3 Jul 2003 13:15:31 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Thu, 3 Jul 2003, Greg Hudson wrote:

> And if I want to change where (say) Cyrus SASL looks for its plugins,
> why would I want to have to do that for every application which uses
> Cyrus SASL, instead of doing it in one place?

Nothing prevents the library from having defaults, or looking at
environment variables, or reading from /dev/random to gain the
information otherwise provided by getopt in other ways.

However, in your scenario all the applications running on a system need to
share the same global configuration with no possibility of making
application-specific changes.  Which really isn't acceptable.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 03 Jul 2003 13:04:27 -0400
Sender: [email-masked]

On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote:
> Are you saying its better to have NO standard way to get configuration
> information into the library fromt he application?

Absolutely.  The vast majority of APIs contain no such mechanism,
because a library should be able to do its job without creating such a
mechanism.  If for some reason the library needs configuration, it can
get it via its own configuration files, which it can find through
mechanisms not involving the calling code (fixed paths, environment
variables, the registry, etc.).

The only exception class tends to be gui toolkits, which usually want to
take over the command line by accepting and modifying argc and argv. 
I'm ambivalent about this practice (it makes it harder to document the
command-line syntax of programs using the gui toolkit, but it's hard to
imagine doing without it given the variety of standard command-line
arguments affecting the toolkit), but it's not terribly onerous because
a GUI toolkit tends to dominate the scope and structure of an
application.  Not so with a SASL library.

>   Thus, if I want an
> application to work with two types of libraries, I have to provide (in
> hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and
> SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation?

If we are talking about an application providing this information for
its own reasons, then it's already sunk; the SASL API says nothing about
plugin paths, you don't know what option name would be involved, and the
implementation might not even use plugins.  (And of course, if the
application is providing such information for its own reasons, it
probably cares about the back-end plugin interface, which isn't
specified at all.)

But, of course, the specifiers are not envisioning an application
providing this information for its own reasons; they are envisioning an
application blindly (no stigma here) passing along user configuration,
as reflected here:

> The getopt callback supplys a standard way to get this information from
> the application.  Since presumably the application is looking up this
> information in its own config files, the user can read the documentation
> for their SASL implementation and decide if they need to set the SASL
> option "pathname" or "path_to_plugins".  This can be done without needing
> to change the code to the application.

We're going around in circles on this point.  I'll skip the part where I
argue against this idea at the end of
<http://www.imc.org/ietf-sasl/mail-archive/msg01008.html> and go to the
part where you respond in
<http://www.imc.org/ietf-sasl/mail-archive/msg01014.html> with (among
discussions of fixed paths versus other ways of finding a config file,
which we've also talked about at length):

  And being able to combine SASL options with application options in one
  place is a usability improvement.

which is another puzzling argument.  Most discussion of usability
revolves around GUI interfaces, and it is impossible to create a
non-degenerate GUI configuration interface for options you know nothing
about.  The best you can do is provide a registry-like interface where
the user can manipulate key-value pairs, which is only one step away
from editing text files.

But even if we're talking about usability among the tiny
(percentagewise) population of users who are comfortable editing
configuration files, I don't see the benefit.  Why would I want to have
a single configuration whose meaning is split over two or more different
pieces of documentation?  Wouldn't I like my configuration files to have
nicely commented templates?  (That would be logistically difficult for
configuration files which span abstraction barriers like you envision.) 
And if I want to change where (say) Cyrus SASL looks for its plugins,
why would I want to have to do that for every application which uses
Cyrus SASL, instead of doing it in one place?

Date: Thu, 03 Jul 2003 07:32:39 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on the SASL C API
Sender: [email-masked]

Simon Josefsson wrote:

> Alexey Melnikov <[email-masked]> writes:
>
> > I've added some clarification about multiple SASL tokens in sasl_decode as
> > described by Larry.
>
> Thank you, and also to Greg and Larry who provided insight.  The
> problem had a simple solution, but it wasn't really obvious [to me],
> so additional text would not hurt.  Perhaps it can even be useful to
> application writers, so they know sasl_decode() could return data that
> is the concatenation of output from more than one call to
> sasl_encode().  It appears that this could affect the choice of buffer
> sizes.

sasl_decode allocates or returns own buffer, so the caller shouldn't worry about
buffer sizes.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Thu, 3 Jul 2003 09:51:35 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Wed, 2 Jul 2003, Greg Hudson wrote:

> But let's say I'm wrong, and there really is some good reason why the
> calling code should be helping out.  And let's also say that this reason
> isn't good enough to make the plugin directory part of the standard SASL
> C API.  What value is there in half-standardizing the interface through
> which the library gets this information?  If some application needs this
> non-standard functionality and therefore can only use (let's say) the
> Cyrus implementation, then the Cyrus implementation can add its own
> non-standard function to specify the plugin directory.

Are you saying its better to have NO standard way to get configuration
information into the library fromt he application?  Thus, if I want an
application to work with two types of libraries, I have to provide (in
hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and
SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation?
Worse: what if these two implementations define the same values for these
two callbacks!

The getopt callback supplys a standard way to get this information from
the application.  Since presumably the application is looking up this
information in its own config files, the user can read the documentation
for their SASL implementation and decide if they need to set the SASL
option "pathname" or "path_to_plugins".  This can be done without needing
to change the code to the application.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on the SASL C API
From: Simon Josefsson <[email-masked]>
Date: Thu, 03 Jul 2003 05:30:06 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> I've added some clarification about multiple SASL tokens in sasl_decode as
> described by Larry.

Thank you, and also to Greg and Larry who provided insight.  The
problem had a simple solution, but it wasn't really obvious [to me],
so additional text would not hurt.  Perhaps it can even be useful to
application writers, so they know sasl_decode() could return data that
is the concatenation of output from more than one call to
sasl_encode().  It appears that this could affect the choice of buffer
sizes.

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 02 Jul 2003 22:05:04 -0400
Sender: [email-masked]

On Wed, 2003-07-02 at 20:41, Alexey Melnikov wrote:
> > Options required for a SASL library itself should be nailed down by the
> > spec or not subject to configuration by the caller.  (The plugin dir,
> > for instance, should be found in a fixed location or via an environment
> > variable; there's no reason for SASL to introduce a completely new
> > override mechanism.)
> 
> Oh, please. What if my application wants to use a fixes path, but not the one
> hardcoded in the SASL library?
> 
> Plus hardcoded paths don't work on certain OSes (e.g. Windows).

Why would you ever write an application which cares, more than any other
application, where a SASL library looks for its plugin directory?

Every caller of the SASL library should be in the same position here. 
Which means the library needs to be able to find its plugins without
help from the calling code.  Whether that means a fixed path, an
environment variable, the registry, or whatever else is up to the
library, but asking the calling code to provide that information is of
no help.

But let's say I'm wrong, and there really is some good reason why the
calling code should be helping out.  And let's also say that this reason
isn't good enough to make the plugin directory part of the standard SASL
C API.  What value is there in half-standardizing the interface through
which the library gets this information?  If some application needs this
non-standard functionality and therefore can only use (let's say) the
Cyrus implementation, then the Cyrus implementation can add its own
non-standard function to specify the plugin directory.

Date: Wed, 02 Jul 2003 18:47:29 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Rob Siemborski <[email-masked]>
CC: [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Rob Siemborski wrote:

> > Since people have grown silent on the topic, I'll note that no excuse
> > has been given for the global callbacks structure, and no answer has
> > been given to my argument that library calls to the SASL C API could
> > accidentally trigger invocations of the application's global callbacks
> > no matter what the library does to guard against this possibility.  If
> > transition for users of Cyrus SASL is the only concern, then the API
> > spec can preserve the parameter as a dummy and mandate that all callers
> > must pass NULL, as has been done in Unix with gettimeofday() and the
> > timezone parameter.
>
> Unless I am misremembering, this is basically what we discussed in San
> Francisco (I thought I had mentioned that).

Yes, this is in my notes. More specifically:

1). Init problem: deprecatate global callbacks.

If global callbacks are provided multiple times, this is implementation
dependent.

2). Make appname setprop/getprop

appname must be NULL in sasl_server_init, if it is called from a library.

> Note that this is difficult for situations such as the getopt callback,
> where path information to loadable modules (or similar information that is
> requried for the library to initialize) may need to be obtained.  In this
> case (since it is part of the one-time library startup) the application
> would need to supply a getopt callback.  Since its one-time startup state,
> your library couldn't change it if it wanted to.

So, where this discussion leaves us? Should I change the document to say that
global callbacks must be NULL, except for maybe the getopt callback?

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 02 Jul 2003 18:41:59 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Greg Hudson <[email-masked]>
CC: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Greg Hudson wrote:

> > Sure, the library can also just access a configuration file to get the
> > information it needs, but then how does the user supply the path the the
> > configuration file?  I'm quite certain that having a fixed path to a
> > configuration file isn't what users are looking for.
>
> I believe this is argument from fantasy.  I don't think there's any
> back-end mechanism library which asks for this kind of information from
> the calling code.  They all uses fixed paths, possibly overridden by
> environment variables which the calling code is not expected to tamper
> with.

> > And being able to combine SASL options with application options in one
> > place is a usability improvement.
>
> Options required for a SASL library itself should be nailed down by the
> spec or not subject to configuration by the caller.  (The plugin dir,
> for instance, should be found in a fixed location or via an environment
> variable; there's no reason for SASL to introduce a completely new
> override mechanism.)

Oh, please. What if my application wants to use a fixes path, but not the one
hardcoded in the SASL library?

Plus hardcoded paths don't work on certain OSes (e.g. Windows).

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 02 Jul 2003 18:38:12 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on the SASL C API
Sender: [email-masked]

Simon Josefsson wrote:

> ...

I've added some clarification about multiple SASL tokens in sasl_decode as
described by Larry.

> Extension:

> Here is a writeup on an idea I have received.  It might cause some
> complications and likely needs more pondering.  However, if the
> rationale for adding this makes sense to you, I'd appreciate if you
> spent the time incorporating the functions.  If you are familiar with
> the GSS-API, compare this to the gss_export_sec_context and
> gss_import_sec_context functions that were added to GSS-API version 2
> (see RFC 2744).

I like the idea and had though about something similar myself. The question
is if this belong to the base SASL API document or should this be an
extension.

I would like to hear what other people think about adding this.

>  5.2.   Exporting and importing security layer state
>
>       Some application environments wishes to separate the initial and
>       short authentication step from the potentially long lived
>       application step, where the application uses sasl_encode() and
>       sasl_decode() to transfer application data.  This separation may
>       be between processes (separation across hosts is more
>       complicated, as the security layer state is often dependent on
>       the host address, but still conceivable).  The reason for such
>       separation may be to guarantee that long-term secrets (e.g.,
>       passwords) cannot be recovered by compromising the application
>       that handles existing session.
>
>       The functions defined in this section allows the application to
>       export the security layer state associated with a session as an
>       opaque character string, and later import the opaque character
>       string.  The opaque state typically contains an encryption key,
>       initialization vectors, what encryption algorithm to use, packet
>       number etc.
>
>   5.2.1. sasl_export_security_layer_state function
>
> Arguments:
>             sasl_conn_t *conn,
>             const char **state,
>             unsigned int *statelen
>
> Results:
>             SASL_OK        -- Success
>             SASL_NOTDONE   -- Security layer negotiation not finished
>
>       This function exports the security layer state required to
>       implement the sasl_encode() and sasl_decode() functions after
>       the state has been imported.  The security layer state is an
>       opaque data string.  The state and statelen are filled in with
>       the opaque state data and its length respectively. If the
>       security layer negotiation has not finished, SASL_NOTDONE is
>       returned.  After calling this function, the application should
>       treat the SASL session as concluded and call sasl_dispose().  In
>       particular, the application MUST NOT call sasl_encode() or
>       sasl_decode() [XXX sasl_dencode should simply return a error
>       code when it happens].  The state data is only valid until a
>       call to sasl_dispose(), and should be copied before calling
>       sasl_dipose() if necessary.
>
>   5.2.2. sasl_import_security_layer_state function
>
> Arguments:
>             const char *state,
>             unsigned int statelen
>             sasl_conn_t **conn,
>
> Results:
>             SASL_OK        -- Success
>             SASL_BADPARAM  -- Invalid parameter supplied
>
>       This function create a SASL session, for use with sasl_encode(),
>       sasl_decode() and sasl_dispose() only, from the given security
>       layer state.  The security layer state is an opaque data string,
>       as returned from sasl_export_security_layer_state().

Cheers,
Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-03.txt
Date: Wed, 02 Jul 2003 16:34:06 -0400
Sender: [email-masked]

--NextPart

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

	Title		: SASLprep: Stringprep profile for user names and 
                          passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-03.txt
	Pages		: 6
	Date		: 2003-7-2
	
This document describes how to prepare Unicode strings representing
user names and passwords for comparison.  The document defines the
'SASLprep' 'stringprep' profile to be used for both user names and
passwords.  This profile is intended to be used by Simple
Authentication and Security Layer (SASL) mechanisms (such as PLAIN,
CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user
names and/or passwords.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-saslprep-03.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-anon-02.txt
Date: Wed, 02 Jul 2003 16:34:12 -0400
Sender: [email-masked]

--NextPart

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

	Title		: The Anonymous SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-anon-02.txt
	Pages		: 9
	Date		: 2003-7-2
	
It is common practice on the Internet to permit anonymous access to
various services.  Traditionally, this has been done with a plain text
password mechanism using 'anonymous' as the user name and optional
trace information, such as an email address, as the password.  As
plaintext login commands are not permitted in new IETF protocols, a
new way to provide anonymous login is needed within the context of the
Simple Authentication and Security Layer (SASL) framework.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-anon-02.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-02.txt
Date: Wed, 02 Jul 2003 16:34:16 -0400
Sender: [email-masked]

--NextPart

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

	Title		: The Plain SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-plain-02.txt
	Pages		: 8
	Date		: 2003-7-2
	
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-plain-02.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: Re: Using SASL C API from a library
From: Sam Hartman <[email-masked]>
Date: Wed, 02 Jul 2003 12:36:25 -0400
Sender: [email-masked]

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    Rob> On Sun, 29 Jun 2003, Greg Hudson wrote:

    >> It seems like a bizarre argument, especially when Unix systems
    >> converged on the POSIX threads API years and years ago.

    Rob> Solaris has a non-pthreads threading API.  There's no reason
    Rob> the SASL C API should dictate what threading API to use.

It's my understanding that at least in recent Solaris versions, the
locks between this API and the pthreads API are compatible.  Please
correct me if I'm wrong.

Subject: Re: Using SASL C API from a library
From: Greg Hudson <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 01 Jul 2003 11:27:26 -0400
Sender: [email-masked]

On Tue, 2003-07-01 at 10:12, Rob Siemborski wrote:
> > So, unless you can demonstrate a present practical issue, I don't think
> > this argument is even vaguely compelling.

> The good news here is that most of these are (or can be made to be)
> connection-context specific.  Ones that potentially need to be supported
> by a global getopt callback really significantly fewer.

Certainly it should be possible for krb5, since krb5 does not use global
state.  (It also does not allow the caller to pass a path to find
krb5.conf.)

> Sure, the library can also just access a configuration file to get the
> information it needs, but then how does the user supply the path the the
> configuration file?  I'm quite certain that having a fixed path to a
> configuration file isn't what users are looking for.

I believe this is argument from fantasy.  I don't think there's any
back-end mechanism library which asks for this kind of information from
the calling code.  They all uses fixed paths, possibly overridden by
environment variables which the calling code is not expected to tamper
with.

> And being able to combine SASL options with application options in one
> place is a usability improvement.

Options required for a SASL library itself should be nailed down by the
spec or not subject to configuration by the caller.  (The plugin dir,
for instance, should be found in a fixed location or via an environment
variable; there's no reason for SASL to introduce a completely new
override mechanism.)

> Implementations of the SASL API will require configuration options to
> function properly, we shouldn't deny them a reasonable way to get that
> information in a standard way, even if the information itself is
> implementation dependent.

Once again, you've made an argument which (I believe) no other
standardized API makes, and provided no specific examples to back it up.

Date: Tue, 1 Jul 2003 10:12:53 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Greg Hudson <[email-masked]>
cc: [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

On Tue, 1 Jul 2003, Greg Hudson wrote:

> > Unless I am misremembering, this is basically what we discussed in San
> > Francisco (I thought I had mentioned that).
>
> (The minutes do not appear to document any discussion of the SASL C API,
> incidentally.)

Since its not a charter item, it wasn't discussed in the formal WG
meeting.  I think Alexey has notes from when a few of us sat around
discussing it though.

> Previously, you said "it can be solved by not using global callbacks
> except in the outermost application," which is very different from "not
> using global callbacks at all."
>
> > Note that this is difficult for situations such as the getopt callback
> > where path information to loadable modules (or similar information that is
> > requried for the library to initialize) may need to be obtained.
>
> There is really no limit to the number of awful things you could justify
> putting into the API if you want to satisfy every possible foible of a
> back-end library. [snip]

You don't need to satisfy every possible one, but let's at least try to
anticipate reasonable desires of the implementors.

> So, unless you can demonstrate a present practical issue, I don't think
> this argument is even vaguely compelling.

Kerberos mechanisms need a path to a srvtab or keytab.  Perhaps shared
secret mechanisms need a path to a database of shared secrets.

Perhaps one of the worse examples (though one of the most useful) is a
list of mechanisms to limit what the library advertises.

The good news here is that most of these are (or can be made to be)
connection-context specific.  Ones that potentially need to be supported
by a global getopt callback really significantly fewer.

> Franky, the getopt callback is a great big hole in the spec for
> unspecified behavior (both mechanism-specific and
> implementation-specific), since there is no standardization of what the
> options mean.  Presumably the idea is that you would provide the answers
> from a configuration file or from command-line options, giving a sort of
> direct communications channel between the user and the SASL library or
> specific mechanism.  That may sound attractive to implementors, but it's
> a totally unacceptable idea, because it's impossible to document such a
> config file or command-line syntax without knowing the intimate (and
> version-specific) details of your SASL implementation, and because it's
> impossible to provide reasonable answers in a situation where a config
> file or command line doesn't make sense.

The application doesn't have to understand the options its handing
to the library, only the user does.  And the user can have access to
implementation-specific information about the library.

Sure, the library can also just access a configuration file to get the
information it needs, but then how does the user supply the path the the
configuration file?  I'm quite certain that having a fixed path to a
configuration file isn't what users are looking for.  And being able to
combine SASL options with application options in one place is a usability
improvement.

Implementations of the SASL API will require configuration options to
function properly, we shouldn't deny them a reasonable way to get that
information in a standard way, even if the information itself is
implementation dependent.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 01 Jul 2003 10:01:52 -0400
From: Larry Greenfield <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Greg Hudson <[email-masked]>, [email-masked]
Subject: Re: Using SASL C API from a library
Sender: [email-masked]

Philip Guenther wrote:

>Rob Siemborski <[email-masked]> writes:
>...
>  
>
>>This works, until an application is running using an incompatible
>>threading API (see Larry's answer to my earlier question).
>>    
>>
>I knew I should have replied to Larry's answer.  I find his example
>unconvincing.  He has suggested that there may exist a cooperative
>threading library running on a system that has a system level threading
>implementation and that intercepts blocking I/O calls (i.e., supplies
>symbols like connect(), read(), etc) such that it intercepts the calls
>of unmodified libraries, but that *doesn't* intercept calls to the
>system's threading primitives.  (If that's not what you're suggesting,
>Larry, please correct me.)
>
This appears to be an accurate description of the GNU Pth library using 
the "hard system call mapping". (I base this off of the documentation 
and not first hand experience.)

Pth is a popular and frequently used threading library.

Larry

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-02.txt
Date: Tue, 01 Jul 2003 07:23:50 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: P. Leach, C. Newman, A. Melnikov
	Filename	: draft-ietf-sasl-rfc2831bis-02.txt
	Pages		: 39
	Date		: 2003-6-30
	
This specification defines how HTTP Digest Authentication [Digest]
can be used as a SASL [RFC 2222] mechanism for any protocol that has
a SASL profile. It is intended both as an improvement over CRAM-MD5
[RFC 2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-01.txt
Date: Tue, 01 Jul 2003 07:23:45 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2222bis-01.txt
	Pages		: 18
	Date		: 2003-6-30
	
SASL provides a method for adding authentication support with an
optional security layer to connection-based protocols.  It also
describes a structure for authentication mechanisms.  The result is
an abstraction layer between protocols and authentication mechanisms
such that any SASL-compatible authentication mechanism can be used
with any SASL-compatible protocol.
This document describes how a SASL authentication mechanism is
structured, how a protocol adds support for SASL, defines the
protocol for carrying a security layer over a connection, and defines
the EXTERNAL SASL authentication mechanism.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nystrom-http-sasl-07.txt
Date: Tue, 01 Jul 2003 07:22:28 -0400
Sender: [email-masked]

--NextPart

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

	Title		: SASL in HTTP/1.1
	Author(s)	: M. Nystrom, A. Melnikov
	Filename	: draft-nystrom-http-sasl-07.txt
	Pages		: 33
	Date		: 2003-6-30
	
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in http/1.1 [RFC2616],
and defines one approach to accomplish this.
Please send comments on this document to the relevant mailing lists,
e.g. [email-masked].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-nystrom-http-sasl-07.txt

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

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

--OtherAccess--

--NextPart--