Subject: call for SASL agenda items for IETF71

From: Tom Yu <[email-masked]>
Date: Tue, 26 Feb 2008 17:01:10 -0500

Hi,

What agenda topics would people like for the SASL WG sesison at
IETF71?  I can think of a few off the top of my head

* DIGEST-to-historic
* implementation report
* RFC4422bis
* direction for password-based mechanisms

any others?

Initial WG agendas are due tomorrow, so please let me know soon.  Thanks.

---Tom

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 27 Feb 2008 00:36:29 +0100

> any others?

* The proposed new IDN WG, what does it mean for SASLprep ?
* Is 2195bis ready for DS ?  The I-D expired three weeks ago,
  one unnecessary MUST NOT could be shaky for the promotion.

 Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Feb 2008 15:49:54 +0000

>IETF71?  I can think of a few off the top of my head
IMHO, I don't think there is much point in discussing this, as the 
document is more or less done and waiting for SCRAM to become stable.

>* implementation report
I don't think anybody has done anything on this item, and I hate 
repeated discussions resulting in "we need to do something" decision.

>* direction for password-based mechanisms
I suggest we add GS2/GS3 discussion to this list.

Date: Wed, 27 Feb 2008 15:49:54 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: call for SASL agenda items for IETF71
Sender: [email-masked]

>IETF71?  I can think of a few off the top of my head
IMHO, I don't think there is much point in discussing this, as the 
document is more or less done and waiting for SCRAM to become stable.

>* implementation report
I don't think anybody has done anything on this item, and I hate 
repeated discussions resulting in "we need to do something" decision.

>* direction for password-based mechanisms
I suggest we add GS2/GS3 discussion to this list.

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, Sam Hartman <[email-masked]>
Subject: Re: SCRAM with(out) GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 27 Feb 2008 13:22:52 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> Thus I am strongly in favor of at least adding the channel-binding-only
> option to GS2.  I am also leaning towards being in favor of removing
> support for security layers and security layer negotiation from GS2 as
> well -- that would another significant simplification.  On the latter
> point I'd like to hear from Simon and others whether they are OK with
> GS2 (GS3, whatever) mechanisms not providing any security layers.

I am.  My use case has always been to use GS2 with TLS and channel
bindings.  With Kerberos 5 for optimized round-trips, and with a
password-based GSS-API mechanism for wide use.

I don't see what has to be _added_ to GS2 support this though?

/Simon

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Holding gs2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 27 Feb 2008 13:19:16 +0100
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

> As a SASL implementer, it is my current intention to not implement the
> "security layer" feature of SASL.

For the record, I agree and think that the "security layer" of SASL has
been a failure and the time has come to officially deprecate them.

We could update RFC 4422 to say that security layers are deprecated in
favor of channel-binding to another security layer such as TLS or IPSEC.

/Simon

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: call for SASL agenda items for IETF71
Date:  Wed, 27 Feb 2008 00:36:29 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 9
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Tom Yu wrote:
=20

 Frank

To: [email-masked]
Subject: call for SASL agenda items for IETF71
From: Tom Yu <[email-masked]>
Date: Tue, 26 Feb 2008 17:01:10 -0500
Lines: 15
Sender: [email-masked]

Hi,

* DIGEST-to-historic
* implementation report
* RFC4422bis

any others?

---Tom

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Digest-MD5 to Historic
Date:  Fri, 22 Feb 2008 10:44:38 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 10
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Frank Ellermann wrote:
=20
> here is the proposed text explaining the MD5-SESS Digest-MD5
> problem.  I could transform it into xml2rfc format if needed.

Of course it should be "algorithm" instead of "alg" in the MD5
examples, sorry.  I've updated the test suite also for RFC 5090,
http://omniplex.blogspot.com/2008/02/md5-sess-and-rfc-5090.html

 Frank

Date: Mon, 18 Feb 2008 02:10:53 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Comments on YAP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I believe YAP should share as much as possible with SCRAM, including key
hierarchy and message formats, but it should still be a distinct
mechanism.

YAP should differ from SCRAM only in that the client does not request a
challenge and the server does not furnish it.  Instead unique channel
bindings are required and are used as the ServerNonce, and no
ClientNonce is used.

YAP should be usable in place of SCRAM when the client has "recently"
authenticated to the same server using SCRAM.  This is needed so that
the client can know the salt, iteration count, ...

I.e., YAP should be, essentially, a round-trip optimized version of
SCRAM but with limited applicability.

Nico
-- 

Date: Mon, 18 Feb 2008 01:56:18 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Comments on SCRAM
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I think we can do better w.r.t. key hierarchy.

I suggest:

 o Replacing Hi() with something like PBKDF2 (see RFC2898), using HMAC()
   as the PRF:

   U0 := HMAC(Password, salt)
   U1 := HMAC(Password, U0)
   U2 := HMAC(Password, U1)
   ..
   Uc := HMAC(Password, Uc-1)

   Hi = U0 XOR U1 XOR U2 XOR .. XOR Uc

   This is, essentially, PBKDF2 with HMAC() as the PRF and with dkLen
   == output length of HMAC() == output length of H().  It's also very
   similar to the Hi() that is specified in the I-D.

   'c' here is the iteration count, of course.

 o Specifying a minimum iteration count.  This will require doing some
   performance measurements on various systems.

 o Adding an optional realm name that:

   a) can be sent by the client in the challenge request IF the client
      knows it

   b) can be sent by the server IF the client did not send it in the
      challenge request, AND IF there is a realm at all

   c) is part of the salt used in the derivation of what we might call
      the "master secret" for a {user, realm}

   This way if the client knows the realm name, it can use it, and if
   not, not.  The client, however, would need to know whether a realm
   name is known (e.g., the UI may need to ask the user if the
   server-provided realm name is correct).

 o Adding the server name to the derivation of the shared secret with
   the server

So that the result might look like this:

   MasterSecret := Hi(HMAC(password, salt + realm)

   RealmSharedSecret := HMAC(MasterSecret, "realm-shared-secret")

   ClientSecret := HMAC(MasterSecret, "client-secret")
   ClientSecretVerifier := H(ClientSecret)

   SharedSecret := HMAC(RealmSharedSecret, "shared-secret;" + server-name)
   ServerSecret := HMAC(RealmSharedSecret, "server-secret;" + server-name)

   AuthMessage := client-first-message + "," +
                  server-first-message + "," +
                  final-client-message-without-proof
   ClientSignature := HMAC(SharedSecret, AuthMessage)
   ClientProof := ClientSignature XOR ClientSecret
   ServerSignature := HMAC(ServerSecret, AuthMessage)

The server stores ClientSecretVerifier and ServerSecret.  The realm, if
there is one, stores RealmSharedSecret and ClientSecretVerifier.

This scheme allows the server to impersonate the client to itself after
the client authenticates to it once (but this is of little use to the
server), and it allows the realm to impersonate the client to all
servers in that realm once it has seen ClientSecret.

Also, we may want to define an error message in case the client
specifies a realm name unknown to the server, or in case the ClientProof
cannot be validated.

Nico
-- 

Date: Wed, 13 Feb 2008 18:02:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG at IETF71 scheduled
Sender: [email-masked]

Tom Yu wrote:

>SASL WG session for IETF71 is scheduled for Tuesday March 11,
>13:00-15:00.
>
>https://datatracker.ietf.org/meeting/71/agenda.html
>
>Please let me know before February 20 if this timing is a problem;
>rescheduling requests are due by that date.
>  
>
This looks Ok to me so far.

[To the WG:] Do we have a list of things to discuss?

To: [email-masked]
Subject: SASL WG at IETF71 scheduled
From: Tom Yu <[email-masked]>
Date: Wed, 13 Feb 2008 12:01:04 -0500
Lines: 7
Sender: [email-masked]

SASL WG session for IETF71 is scheduled for Tuesday March 11,
13:00-15:00.

https://datatracker.ietf.org/meeting/71/agenda.html

Please let me know before February 20 if this timing is a problem;
rescheduling requests are due by that date.

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Digest-MD5 to Historic
Date:  Mon, 11 Feb 2008 11:34:50 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 194
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hi,=20

here is the proposed text explaining the MD5-SESS Digest-MD5
problem.  I could transform it into xml2rfc format if needed.

 Frank

-----------------------------------------------------------------
Not counting the optional and for digest calculations unused HTTP
Auth Digest <opaque> parameter DIGEST-MD5 uses up to twelve input
parameters <user>, <pass>, <realm>, <method>, <uri>, <nonce>,
<qop>, <cnonce>, <nc>, <alg>, <hash>, and <authz>.

All parameter values are given in <quoted-string>s or directly as
<token>s.  The <quoted-string> form is required for values using
characters not permitted in a <token>.  In a <quoted-string> all
characters can be given as a <quoted-pair> (a backslash followed
by the character).  Notably <quoted-pair>s are required for the
quote and backslash characters.

For all digest calculations <token> values are used "as is", for
<quoted-string>s the delimiting quotes are removed, yielding a
<qdstr-val> keeping any <quoted-pair>s.

The <alg> parameter is optional, its default value is 'MD5',  It
can be also 'MD5-SESS', a case insensitive value for comparisons.
The optional <authz> parameter can be used only with 'MD5-SESS'.

Client nonce <cnonce> and nonce count <nc> are required if <qop>
is given, the <nc> is evaluated as eight hex. digits (big endian
with leading zeros).

For backwards compatibility [RFC 2069} <qop>, <cnonce>, <nc>,
<alg>, <hash>, and <authz> can be omitted.  'MD5-SESS' cannot be
used in backwards compatible mode.

If given <qop> can be 'auth', 'auth-int', and 'auth-conf'.  The
<hash> is required for 'auth-int' and 'auth-conf'.  It consists
of 32 lower case hex. digits for the MD5 of the body, or 32 zero
digits if there is no body.  For <qop> 'auth' a <hash> cannot be
used.

For challenges the <method> is either 'AUTHENTICATE' [RFC 2831]
or 'GET', 'INVITE', etc. [RFC 2617].  For responses the method is
omitted and treated as empty string.  In digest calculations the
<uri> is always separated by a colon from the preceding <method>,
empty or otherwise.  But it is only separated by a colon from a
following <hash> if there is a <hash>, i.e. not for <qop> 'auth'.

Omitting plausibility checks and parameter parsing, as well as
all details of  XURI =3D <method> ":" <uri> [":" <hash>]  the code
for DIGEST-MD5 could be something (here using REXX) like this:

   parse arg USER, PASS, REALM, NONCE, CNONCE, NC, QOP, XURI, ALG
   ALG =3D translate( ALG )        /* ALGorithm is case insensitive */

   HA1 =3D MD5(  USER || ':' || REALM || ':' || PASS )
   if ALG =3D 'MD5-SESS'  then  do
      HA1 =3D x2c( HA1 ) || ':' || NONCE || ':' || CNONCE
      if arg( 10, 'e' ) then  HA1 =3D HA1 || ':' || arg( 10 )
      HA1 =3D MD5( HA1 )           /* optional 10th argument: AUTHZ */
   end

   HA2 =3D MD5( XURI )             /* XURI incl. hash for auth-int  */
   TMP =3D NONCE                   /* 2069 compatibility (=3D no qop) */
   if ALG =3D 'MD5-SESS' | QOP <> ''  then  do
      TMP =3D translate( d2x( NC, 8 ), 'abcdef', 'ABCDEF' )
      TMP =3D NONCE || ':' || TMP || ':' || CNONCE || ':' || QOP
   end

   return MD5( HA1 || ':' || TMP || ':' || HA2 )

Here MD5( x ) is a subroutine returning 32 lower case hex. digits
of the MD5 [RFC 1321].  Ideally this code should also work for an
HTTP Auth Digest [RFC 2617].  Unfortunately this is not the case
for 'MD5-SESS':  [RFC 2831] adopted the [RFC 2617] algorithms "as
is" before the 'MD5-SESS' erratum was reported.  One line in the
example code shown above has to be modified:

      HA1 =3D HA1 || ':' || NONCE || ':' || CNONCE

The difference is x2c( HA1 ) vs. HA1.  In other words [RFC 2831]
uses a binary MD5 where [RFC 2617] plus erratum uses a hex. MD5
string.  See the expired [I-D.smith-sipping-auth-01] for correct
2069-fallback and 'MD5-SESS' examples.

New "fixed" [RFC 2617] 'MD5-SESS' results for examples published
in [RFC 2831] and [RFC 4643] are shown below, followed by four
relevant examples found in [I-D.smith-sipping-auth-01]:

1: user   =3D "chris"
   pass   =3D "secret"
   realm  =3D "elwood.innosoft.com"
   method =3D "AUTHENTICATE"
   uri    =3D "imap/elwood.innosoft.com"
   nonce  =3D "OA6MG9tEQGm2hh"
   qop    =3D "auth"
   cnonce =3D "OA6MHXh6VqTrRk"
   nc     =3D 1
   alg    =3D "md5-sess"

   RFC 2831 digest  =3D "d388dad90d4bbd760a152321f2143af7"
   RFC 2831 rspauth =3D "ea40f60335c427b5527b84dbabcdfffd"

   RFC 2617 digest  =3D "26ef1190b643a36e879673066098379c"
   RFC 2617 rspauth =3D "c316c87a595a2cbfb4405784db016e34"

2: user   =3D "chris"
   pass   =3D "secret"
   realm  =3D "elwood.innosoft.com"
   method =3D "AUTHENTICATE"
   uri    =3D "acap/elwood.innosoft.com"
   nonce  =3D "OA9BSXrbuRhWay"
   qop    =3D "auth"
   cnonce =3D "OA9BSuZWMSpW8m"
   nc     =3D 1
   alg    =3D "md5-sess"

   RFC 2831 digest  =3D "6084c6db3fede7352c551284490fd0fc"
   RFC 2831 rspauth =3D "2f0b3d7c3c2e486600ef710726aa2eae"

   RFC 2617 digest  =3D "90771dc5643a801bb9a9bcbb1ed3cd34"
   RFC 2617 rspauth =3D "ec0700b2da00dd133bcb0c841f42d341"

3: user   =3D "test"
   pass   =3D "test"
   realm  =3D "eagle.oceana.com"
   method =3D "AUTHENTICATE"
   uri    =3D "nntp/localhost"
   nonce  =3D "sayAOhCEKGIdPMHC0wtleLqOIcOI2wQYIe4zzeAtuiQ=3D"
   qop    =3D "auth-conf"
   cnonce =3D "0Y3JQV2Tg9ScDip+O1SVC0rhVg//+dnOIiGz/7CeNJ8=3D"
   nc     =3D 1
   alg    =3D "md5-sess"
   hash   =3D "00000000000000000000000000000000"

   RFC 2831 digest  =3D "d43cf66cffa903f9eb0356c08a3db0f2"
   RFC 2831 rspauth =3D "de2e127e5a81cda53d97acda35cde83a"

   RFC 2617 digest  =3D "41e814138958b1a0f08ef8b2dbe94ee9"
   RFC 2617 rspauth =3D "3f4d2b034c67c0c77df650f34ece6127"

4: user   =3D "bob"
   pass   =3D "zanzibar"
   realm  =3D "biloxi.com"
   method =3D "INVITE"
   uri    =3D "sip:[email-masked]"
   nonce  =3D "dcd98b7102dd2f0e8b11d0f600bfb0c093"
   cnonce =3D "0a4f113b"
   nc     =3D 1

   digest =3D "bf57e4e0d0bffc0fbaedce64d59add5e"
   No <qop> =3D> 2069-fallback, <cnonce> and <nc> ignored

5: user   =3D "bob"
   pass   =3D "zanzibar"
   realm  =3D "biloxi.com"
   method =3D "INVITE"
   uri    =3D "sip:[email-masked]"
   nonce  =3D "dcd98b7102dd2f0e8b11d0f600bfb0c093"
   qop    =3D "auth"
   cnonce =3D "0a4f113b"
   nc     =3D 1

   digest =3D "89eb0059246c02b2f6ee02c7961d5ea3"
   No <alg> =3D> default 'MD5', <cnonce> and <nc> honored

6: user   =3D "bob"
   pass   =3D "zanzibar"
   realm  =3D "biloxi.com"
   method =3D "INVITE"
   uri    =3D "sip:[email-masked]"
   nonce  =3D "dcd98b7102dd2f0e8b11d0f600bfb0c093"
   qop    =3D "auth"
   cnonce =3D "0a4f113b"
   nc     =3D 1
   alg    =3D "MD5-sess"

   RFC 2617 digest =3D "e4e4ea61d186d07a92c9e1f6919902e9"

7: user   =3D "bob"
   pass   =3D "zanzibar"
   realm  =3D "biloxi.com"
   method =3D "INVITE"
   uri    =3D "sip:[email-masked]"
   nonce  =3D "dcd98b7102dd2f0e8b11d0f600bfb0c093"
   qop    =3D "auth-int"
   cnonce =3D "0a4f113b"
   nc     =3D 1
   alg    =3D "MD5-sess"
   hash   =3D "c1ed018b8ec4a3b170c0921f5b564e48"

   RFC 2617 digest =3D "91984da2d8663716e91554859c22ca70"

Date: Wed, 06 Feb 2008 10:25:25 +0100
From: redhadjasper <[email-masked]>
To: [email-masked]
Subject: logs filling up
Sender: [email-masked]

Hi everywan

when i upgraded my machine to fc8  from fc6 my logs are filling up with
: postfix/smtpd[1241]: auxpropfunc error invalid parameter supplied
same config files used.
now i read on the Internet that i have to remove a plugin to remove this 
problem
but were and what plug in.
i use fc8 and ldap for identification  passwords settings etc.

if i have si send a config file please let me know.
i have been trying a lot of div rent  settings none helped.

many thanks jasper

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door DarkEagle scanners en lijkt schoon te zijn.