Subject: Normalization of passwords in SASL and SSH

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Nov 2004 20:27:45 -0800

Hi.  A discussion in the IETF 61 secsh meeting re-opened the issue of
how to handle password normalization for passwords received by the
server.  The ssh protocol had adopted a significantly different
solution to this problem than the sasl plain mechanism.  This concerns
me; I want to either solve the problem of password normalization in a
consistent manner or to understand why the ssh requirements are
different than the sasl requirements.  

As a result of that discussion I've been talking to several people
about the issue.  Now I think I understand things well enough to
propose a solution to both working groups.

First, I'd like to revisit the motivation behind normalization.  There
are a variety of semantically equivalent sequences of characters that
have multiple representations in Unicode.  The simplest example is
accented characters where one code point represents the accented
character and another series of code points represents the
semantically equivalent character plus a combining accent.  Other
examples exist.  Which sequence of code points gets used tends to
depend on the input method used to enter the characters.  That means
that it tends to depend on the OS, application and version of software
used.  So, telling users to type their password the same way is not a
sufficient answer to guarantee that you end up with the same sequence
of code points; the user may not have a choice of input methods.

The IDN working group developed an architecture called Stringprep
which allows protocol-specific profiles of rules for mapping some
semantically equivalent strings into the same sequences of code
points.  It is not perfect; as with any normalization discussion the
question of where to draw boundaries between equivalence classes is
difficult.  The SASL working group developed a profile of Stringprep
called Saslprep; this profile is targeted at simple usernames and
passwords.  Everyone I talked to over the past two weeks believes that
if you are going to normalize passwords for ssh or the SASL plain
mechanism, Saslprep is a reasonable profile to use.  Saslprep has the
advantage of already being in the rfc editor queue.

We'd like to tell people to normalize passwords all the time.  If they
actually did that then it would improve interoperability and the user
experience.  However most systems we use do not store plaintext
passwords.  Instead, they tend to store some function of the password
or to call out to something like PAM or RADIUS to do password
authentication.  Normalizing a password before you check it but not
when new passwords are stored may be very problematic.  

For example, consider an environment where the input method tends to
produce separate base character and accent code points. Without
normalization, when passwords containing accents are stored, any
computed hash will include both the base character and the accent.
However Saslprep will normalize such a string to use a single code
point when possible.  Thus in such an environment, normalizing only
when checking passwords would decrease interoperability because
accented characters would never work in passwords.

I'm proposing the following approach to address this situation.  For
both ssh and sasl plain, normalization should be done on the server if
at all.  Only the server knows what the password store technology in
use is.  We recommend normalizing when passwords can be normalized
both as they are set and as they are compared.  In environments where
passwords may not be normalized as they are set, implementations may
want to try comparing against both the normalized and supplied form of
the password.  Doing so may improve interoperability because it means
there is a password that if successfully set will work when used with
any input method.  However in many environments such as when a server
calls out to PAM or RADIUS, even the server cannot try multiple
passwords without incrementing failed password counters or having
other similar side effects.  Here are some examples of how I see these
recommendations working.

A sasl plain implementation that manages its own password database
would always normalize when setting a password and when checking
passwords.  

A Windows ssh service  that managed its own authentication database
and provided the only tool for setting passwords  would normalize both
for setting passwords and for comparing them.

An ssh implementation that used a unix password file would not
normalize passwords for comparison.  This is true even if the ssh
implementation sometimes was used to set passwords, because the passwd
command could be used independently of the ssh implementation.

An ssh implementation that called out to PAM or RADIUS would not
normalize passwords.  However some of the modules eventually doing the
password comparison might well do normalization if appropriate for the
password store in question.

Does this seem like a reasonable approach to people?  If so, we can
work on appropriate text.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Nov 2004 22:26:45 -0800

These are the changes (in unified diff form) I propose to make to
the sasl-plain I-D to address this concern.  Note that change impacts
authcids as well as passwords.

-- Kurt

 The presented authentication identity and password strings are not
-to be compared directly with stored strings.  The server SHALL first
-prepare authentication identity and password strings using the
-[SASLPrep] profile of the [StringPrep] algorithm.  Per Section 7
-of [StringPrep], unassigned code points may appear in prepared
-presented (query) strings but are prohibited in stored strings.  If
-preparation fails or results in an empty string, verification SHALL
-fail.  If the server stores only the hash of expected string, the
-string MUST be prepared before generation of the hash.
+to be compared directly with stored strings.  The server SHOULD
+first prepare authentication identity and password strings using
+the [SASLPrep] profile of the [StringPrep] algorithm as detailed
+below.  When preparing using [SASLprep] or other [StringPrep] based
+algorithm, per Section 7 of [StringPrep], unassigned code points
+may appear in prepared presented (query) strings but are prohibited
+in stored strings.  If only the output of a non-invertible function
+of expected string is stored, the string MUST be prepared before
+input to that function.
+
+The SASLprep preparation is recommended to improve the likelihood
+that comparisons behave in an expected manner.  It is not mandatory
+to allow the server to employ other preparation algorithms (including
+none) as necessary to interoperate with external systems.
+
+Regardless of the preparation algorithm, if preparation fails or
+results in an empty string, verification SHALL fail.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Nov 2004 22:26:45 -0800

-- Kurt

>work on appropriate text.

Date: Mon, 29 Nov 2004 22:26:45 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Normalization of passwords in SASL and SSH
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

-- Kurt

>work on appropriate text.

Date: Mon, 29 Nov 2004 20:30:30 -0800
To: [email-masked]
From: Sam Hartman <[email-masked]>
Subject: Re: Normalization of passwords in SASL and SSH : ietf-sasl
Sender: [email-masked]

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> (WG chair hat off.  just my questions) Why should these
    Bill> proposed rules apply only to passwords and not also to login
    Bill> names?  It seems like the core justification for server side
    Bill> normalization -- that they're often stored in database
    Bill> maintained by a subsystem not under the control of the ssh
    Bill> server implementor -- also applies to usernames.

SASL believes they should apply to usernames as well.
Kerberos has adopted the same position.

    Bill> Is it ever the case that normalization functions would
    Bill> change the human-readable representation meaningfully?
    Bill> Examples?

I'd expect a normalization profile for passwords to remove direction
markers.  I'd expect it to map all forms of white space together.
You'd lose the difference between say a 1 em space and u+0x20, which
would be visible.  I'd say anything outside of these sorts of examples
would be a bad idea in a stringprep profile, especially for a security
application.

Date: Mon, 29 Nov 2004 20:29:27 -0800
To: [email-masked]
From: Sam Hartman <[email-masked]>
Subject: Re: Normalization of passwords in SASL and SSH
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> [email-masked] (Niels Möller) writes:
    >> 2. Add some new text saying that we recommend that systems
    >> supporting non-ascii passwords always normalize passwords and
    >> usernames whenever they are added to the database, or compared
    >> (with or without hashing) to existing entries in the database.

    Simon> I believe the part about storing normalized strings in
    Simon> databases is a poor recommendation.

    Simon> If the password is stored, then I believe it would be
    Simon> better to store the unprepared string than the prepared
    Simon> string.  Otherwise, there is an upgrade problem when
    Simon> SASLprep2 is released.

Note that the sasl working group considered Simon's argument and ended
up disagreeing with him.

As  I recall, Simon  was concerned  about cases  where either  bugs in
Unicode (which do exist) or explicit changes to saslprep 2 designed to
be incompatible would create  a situation where saslprep2(foo) was not
the same as saslprep1(foo).  

The stringprep specification has a reasonable versioning model.  It is
generally true that if applying one version of a stringprep profile to
some string succeeds with unassigned code points prohibited, then
later versions of the same profile will yield the same result.

Simon's concern is that generally true is not the same as always true.

The SASL working group did not decide to adopt this interpretation.  I
don't think a consensus was declared on the reasoning.  

Date: Mon, 29 Nov 2004 20:28:25 -0800
To: [email-masked]
From: Sam Hartman <[email-masked]>
Subject: Re: Normalization of passwords in SASL and SSH
Sender: [email-masked]

>>>>> "Niels" == Niels Möller <[email-masked]> writes:

    Niels> If I understand your proposal, as it applies to ssh, you're
    Niels> suggesting that we should

    Niels> 1. Strike the new text on normalization, in effect
    Niels> reverting to what was in older drafts
    Niels> (e.g. draft-ietf-secsh-userauth-18.txt says "Note that the
    Niels> password is encoded in ISO-10646 UTF-8. It is up to the
    Niels> server how it interprets the password and validates it
    Niels> against the password database.").

    Niels> 2. Add some new text saying that we recommend that systems
    Niels> supporting non-ascii passwords always normalize passwords
    Niels> and usernames whenever they are added to the database, or
    Niels> compared (with or without hashing) to existing entries in
    Niels> the database.

And say that ssh implementations that both store the passwords and
compare them SHOULD use saslprep for normalization.

Date: Mon, 29 Nov 2004 20:27:45 -0800
To: [email-masked]
From: Sam Hartman <[email-masked]>
Subject: Normalization of passwords in SASL and SSH
Sender: [email-masked]

Subject: Re: Normalization of passwords in SASL and SSH
From: Bill Sommerfeld <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 29 Nov 2004 17:17:49 -0500
Sender: [email-masked]

(WG chair hat off.  just my questions)

Why should these proposed rules apply only to passwords and not also to login names?  It seems like the core justification for server side normalization -- that they're often stored in database maintained by a subsystem not under the control of the ssh server implementor -- also applies to usernames.

Is it ever the case that normalization functions would change the human-readable representation meaningfully?  Examples?

If there are multiple available normalization functions it would seem that you might be able to either (a) try several, accept if one matches, and/or (b) "renormalize" already normalized strings using alternate functions, in which case erroneous client-side normalization could well be undone or worked around by the server.

								- Bill

Date: Wed, 17 Nov 2004 16:04:38 -0500
To: Sam Hartman <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: digest-md5 and CBC
Sender: [email-masked]

I would like to make two points.

First, AES-CBC with an explicit IV is always safe.  The WG needs to decide 
if the expansion caused by the IV is too much.  If so, then other 
approaches need to be considered, including AES-CTR.

Second, AES-CTR is sometimes used with an IV too.  When a constant encrypt 
time is important, an LFSR can be used instead of a counter.  This is very 
important in very high-speed implementations.  Again, the WG needs to 
determine if this is a concern in this context.

RFC 3686 provides the rationale for including an IV when AES-CTR is used in 
IPsec ESP.  It says:

    In the development of this specification, the use of the ESP sequence
    number field instead of an explicit IV field was considered.  This
    selection is not a cryptographic security issue, as either approach
    will prevent counter block collisions.

    In a very conservative model of encryption security, at most 2^64
    blocks ought to be encrypted with AES-CTR under a single key.  Under
    this constraint, no more than 64 bits are needed to identify each
    packet within a security association.  Since the ESP extended
    sequence number is 64 bits, it is an obvious candidate for use as an
    implicit IV.  This would dictate a single method for the assignment
    of per-packet value in the counter block.  The use of an explicit IV
    does not dictate such a method, which is desirable for several
    reasons.

    1. Only the encryptor can ensure that the value is not used for more
       than one packet, so there is no advantage to selecting a mechanism
       that allows the decryptor to determine whether counter block
       values collide.  Damage from the collision is done, whether the
       decryptor detects it or not.

    2. Allows adders, LFSRs, and any other technique that meets the time
       budget of the encryptor, so long as the technique results in a
       unique value for each packet.  Adders are simple and
       straightforward to implement, but due to carries, they do not
       execute in constant time.  LFSRs offer an alternative that
       executes in constant time.

    3. Complexity is in control of the implementer.  Further, the
       decision made by the implementer of the encryptor does not make
       the decryptor more (or less) complex.

    4. When the encryptor has more than one cryptographic hardware
       device, an IV prefix can be assigned to each device, ensuring that
       collisions will not occur.  Yet, since the decryptor does not need
       to examine IV structure, the decryptor is unaffected by the IV
       structure selected by the encryptor.  One cannot make use of the
       same technique with the ESP sequence numbers, because the
       semantics for them require sequential value generation.

    5.  Assurance boundaries are very important to implementations that
       will be evaluated against the FIPS Pub 140-1 or FIPS Pub 140-2
       [SECRQMTS].  The assignment of the per-packet counter block value
       needs to be inside the assurance boundary.  Some implementations
       assign the sequence number inside the assurance boundary, but
       others do not.  A sequence number collision does not have the dire
       consequences, but, as described in section 6, a collision in
       counter block values has disastrous consequences.

    6. Coupling with the sequence number is possible in those
       architectures where the sequence number assignment is performed
       within the assurance boundary.  In this situation, the sequence
       number and the IV field will contain the same value.

    7. Decoupling from the sequence number is possible in those
       architectures where the sequence number assignment is performed
       outside the assurance boundary.

    The use of an explicit IV field directly follows from the decoupling
    of the sequence number and the per-packet counter block value.  The
    overhead associated with 64 bits for the IV field is acceptable.
    This overhead is significantly less than the overhead associated with
    Cipher Block Chaining (CBC) mode.  As normally employed, CBC requires

    a full block for the IV and, on average, half of a block for padding.
    AES-CTR with an explicit IV has about one-third of the overhead as
    AES-CBC, and the overhead is constant for each packet.

    The inclusion of the nonce provides a weak countermeasure against
    precomputation attacks.  For this countermeasure to be effective, the
    attacker must not be able to predict the value of the nonce well in
    advance of security association establishment.  The use of long keys
    provides a strong countermeasure to precomputation attacks, and AES
    offers key sizes that thwart these attacks for many decades to come.

    A 28-bit block counter value is sufficient for the generation of a
    key stream to encrypt the largest possible IPv6 jumbogram [JUMBO];
    however, a 32-bit field is used.  This size is convenient for both
    hardware and software implementations.

Russ

At 05:36 PM 11/16/2004, Sam Hartman wrote:

>Hi.  I'm sorry that this message has been delayed so long.
>
>After IETf 60, Alexey and I (as chair) talked to Russ about
>digest-md5's usage of CBC.
>
>As the working group will recall, there are two proposals.  The first
>proposal is that an explicit IV be included in every message.  The
>second proposal is that there be two blocktypes.  The first includes
>an explicit IV and the second includes a CBC block.  No requirement
>would be made that every block be proceeded by a CBC block.
>
>There are two advantages the the second proposal.  The first is that
>it happens to fit the Cyrus code base better.  The second is that it
>can avoid the expansion factor of the IV.  Russ didn't think much of
>the first advantage; personally I agree.
>
>My concern with this approach is that I believe it is vulnerable to an
>attack where the CBC datastream can be used as an oracle to test
>guesses of what previous ciphertext decrypts to.  The attack is
>somewhat hard to construct and assumes that an attacker can observe
>the generated ciphertext and can inject text to be encrypted directly.
>So it is not completely clear that we must address this problem.
>
>
>Russ instructed me to run the proposal by the CFRG and if they did not
>raise strong objections the WG could take that approach if it desired.
>
>The rest of this message is my opinion as an individual participant.
>
>If our goal is the avoid expansion, there is a secure way to do that.
>We can use counter mode instead of CBC.  That would make our AES mode
>work a lot like our RC4 mode.  You need to be careful when using a
>counter-mode cipher, but we already have this complexity for RC4.
>
>We decided against counter mode for complexity reasons.  However if we
>need the features of counter mode I'd rather see us take that
>approach.
>
>
>--Sam

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: digest-md5 and CBC
From: Sam Hartman <[email-masked]>
Date: Wed, 17 Nov 2004 13:30:18 -0500
Sender: [email-masked]

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

    >> My concern with this approach is that I believe it is
    >> vulnerable to an attack where the CBC datastream can be used as
    >> an oracle to test guesses of what previous ciphertext decrypts
    >> to.  The attack is somewhat hard to construct and assumes that
    >> an attacker can observe the generated ciphertext and can inject
    >> text to be encrypted directly.  So it is not completely clear
    >> that we must address this problem.
    >> 
    >> 
    Alexey> Can you give a bit more details on how this would work,
    Alexey> maybe application guys will be able to understand ;-).

I've got some client listening to an unencrypted stream and protecting
the results using digest-md5 in CBC mode.

An attacker sees the encrypted network traffic and controls the
unencrypted stream.

Previously in the same stream (before the attacker controlled it) was
some text.  The attacker believes he knows what the text is and wishes
to verify a guess.  The attacker can try sending the text over the
stream xored with the appropriate block based on the previous IV.  If
the guess is correct, the resulting encrypted block will be related to
the previous encrypted block.

    Alexey> I personally have no problem with the counter mode: the
    Alexey> DIGEST-MD5 deprecates all old ciphers in CBC mode (DES,
    Alexey> 3DES) and AES is a new cipher, so it doesn't have to use
    Alexey> CBC. I presume that there is another advantage of using
    Alexey> the counter mode - the existing structure of DIGEST-MD5
    Alexey> security layer packets will remain the same, which is a
    Alexey> good thing.  Due to my lack of experience with the counter
    Alexey> mode, somebody has to help me out with the text.
Understood.

    Alexey> One question remains though: do we want to allow for
    Alexey> ciphers in CBC mode in the future? If we do, we still have
    Alexey> to choose between two choices described in the draft.

I think the structure of the cipher packets should be cipher
dependent.

Date: Wed, 17 Nov 2004 10:50:31 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Love <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments: gssapi-domain-based-name
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Love <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Nov 17, 2004 at 01:11:08PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >Love's point is that RFC2222 specifically talks about what server names
> >are like, and that is like hostbased-services.  Introducing new name
> >types for SASL mechs may require changing this.
> > 
> >
> 2222bis only refers to service names. I can't find anywhere in the text 
> reference to hostnames.
> 
> I think only the GSSAPI draft is affected.

Good.  I'll come up with some text.

Date: Wed, 17 Nov 2004 10:54:58 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: Further thoughts on PASSDSS
Sender: [email-masked]

I was getting ready to respin Chris' PASSDSS draft since we seem to have 
some support for such a mechanism and I started thinking about making it 
more extensible.

http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt

As currently documented, this mech uses only the required features of 
SSH2: Diffie-Hellman Group 1 key exchange, DSS public key, SHA1 HMAC and 
3DES cipher.  The big advantage of this is that its fairly simple.  The 
exchange only takes 2 roundtrips and looks something like this:

client sends:
   authzid
   authid
   DH pubkey X

server responds:
   DSA pubkey params
   DH pubkey Y
   available sec layers
   max sec layer bufsize
   DSA sig params

client sends (3DES-CBC encrypted):
   sec layer selection
   sec layer bufsize
   password
   HMAC-SHA1 sig

My thought is that we could make this more extensible/flexible by making 
all of these items (key exchange alg, pubkey type, HMAC, cipher) 
selectable/negotiable.  Depending on the key exchange alg, it would add 
at least one more roundtrip (only one for DH).

For simplicity (and to eliminate yet another rountrip), the key exchange 
algorithm wouldn't be part of the exchange, it would be part of the 
mechanism name.  For instance, we'd have SECPASS-DH for Diffie-Hellman 
and SECPASS-FOO for the FOO key exchange method.

The general form of the exchange would be a variation of the original 
and would something look like:

client sends:
   authzid
   authid
   (optional) initial key exch params

server responds:
   pubkey_algs
   ciphers
   hmac_algs
   (optional) initial key exch params

*(
   client sends:
     add'l key exch params

   server responds:
     add'l key exch params
)

client sends:
   pubkey_alg selection
   cipher selection
   hmac selection
   final key exch params

server responds:
   pubkey params
   final key exch params
   available sec layers
   max sec layer bufsize
   sig params

client sends (encrypted):
   sec layer selection
   sec layer bufsize
   password
   HMAC sig

The DH variant, with the the ability to have selectable prime/generator 
(per draft-ietf-secsh-dh-group-exchange-04) would look something like:

client sends:
   authzid
   authid
   1024 (min group size)
   1024 (preferred group size)
   2048 (max group size)

server responds:
   "ssh-dss,ssh-rsa" (pubkey_algs)
   "3des-cbc,aes128-cbc,blowfish-cbc" (ciphers)
   "hmac-sha1,hmac-sha1-96,hmac-md5" (hmac_algs)
   p (e.g. group1 prime)
   g (e.g. group1 generator)

client sends:
   "ssh-dss" (pubkey_alg selection)
   "3des-cbc" (cipher selection)
   "hmac-sha1" (hmac selection)
   DH param X

server responds:
   DSA pubkey params
   DH param Y
   available sec layers
   max sec layer bufsize
   DSA sig params

client sends (3DES-CBC encrypted):
   sec layer selection
   sec layer bufsize
   password
   HMAC-SHA1 sig

For interoperability, we would require certain algorithms/params to be 
implemented such as DH group1, DSS, SHA1, and 3DES (as shown above).

Thoughts?  Is this too complicated?

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

Date: Wed, 17 Nov 2004 13:21:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: digest-md5 and CBC
Sender: [email-masked]

Sam Hartman wrote:

>Hi.  I'm sorry that this message has been delayed so long.
>
>After IETf 60, Alexey and I (as chair) talked to Russ about
>digest-md5's usage of CBC.
>
>As the working group will recall, there are two proposals.  The first
>proposal is that an explicit IV be included in every message.  The
>second proposal is that there be two blocktypes.  The first includes
>an explicit IV and the second includes a CBC block.  No requirement
>would be made that every block be proceeded by a CBC block.
>
>There are two advantages the the second proposal.  The first is that
>it happens to fit the Cyrus code base better.  The second is that it
>can avoid the expansion factor of the IV.  Russ didn't think much of
>the first advantage; personally I agree.
>
>My concern with this approach is that I believe it is vulnerable to an
>attack where the CBC datastream can be used as an oracle to test
>guesses of what previous ciphertext decrypts to.  The attack is
>somewhat hard to construct and assumes that an attacker can observe
>the generated ciphertext and can inject text to be encrypted directly.
>So it is not completely clear that we must address this problem.
>  
>
Can you give a bit more details on how this would work, maybe 
application guys will be able to understand ;-).

>Russ instructed me to run the proposal by the CFRG and if they did not
>raise strong objections the WG could take that approach if it desired.
>
>The rest of this message is my opinion as an individual participant.
>
>If our goal is the avoid expansion, there is a secure way to do that.
>We can use counter mode instead of CBC.  That would make our AES mode
>work a lot like our RC4 mode.  You need to be careful when using a
>counter-mode cipher, but we already have this complexity for RC4.
>
>We decided against counter mode for complexity reasons.  However if we
>need the features of counter mode I'd rather see us take that
>approach.
>  
>
I personally have no problem with the counter mode: the DIGEST-MD5 
deprecates all old ciphers in CBC mode (DES, 3DES) and AES is a new 
cipher, so it doesn't have to use CBC. I presume that there is another 
advantage of using the counter mode - the existing structure of 
DIGEST-MD5 security layer packets will remain the same, which is a good 
thing.
Due to my lack of experience with the counter mode, somebody has to help 
me out with the text.

One question remains though: do we want to allow for ciphers in CBC mode 
in the future? If we do, we still have to choose between two choices 
described in the draft.

Alexey

Date: Wed, 17 Nov 2004 13:11:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Love <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments: gssapi-domain-based-name
Sender: [email-masked]

Nicolas Williams wrote:

>Love's point is that RFC2222 specifically talks about what server names
>are like, and that is like hostbased-services.  Introducing new name
>types for SASL mechs may require changing this.
>  
>
2222bis only refers to service names. I can't find anywhere in the text 
reference to hostnames.

I think only the GSSAPI draft is affected.

To: [email-masked]
Subject: Re: digest-md5 and CBC
From: Sam Hartman <[email-masked]>
Date: Tue, 16 Nov 2004 18:05:49 -0500
Sender: [email-masked]

I failed to make one thing clear.  If the working group believes that
the second CBC proposal is the right approach, we can still go to the
CFRG and go down that path.

When reviewing the document for the IESG I'll want to understand why
the working group believes that CBC without explicit IVs is better
than counter mode if the group does take that approach.

To: [email-masked]
Subject: digest-md5 and CBC
From: Sam Hartman <[email-masked]>
Date: Tue, 16 Nov 2004 17:36:59 -0500
Sender: [email-masked]

Hi.  I'm sorry that this message has been delayed so long.

After IETf 60, Alexey and I (as chair) talked to Russ about
digest-md5's usage of CBC.

As the working group will recall, there are two proposals.  The first
proposal is that an explicit IV be included in every message.  The
second proposal is that there be two blocktypes.  The first includes
an explicit IV and the second includes a CBC block.  No requirement
would be made that every block be proceeded by a CBC block.

There are two advantages the the second proposal.  The first is that
it happens to fit the Cyrus code base better.  The second is that it
can avoid the expansion factor of the IV.  Russ didn't think much of
the first advantage; personally I agree.

My concern with this approach is that I believe it is vulnerable to an
attack where the CBC datastream can be used as an oracle to test
guesses of what previous ciphertext decrypts to.  The attack is
somewhat hard to construct and assumes that an attacker can observe
the generated ciphertext and can inject text to be encrypted directly.
So it is not completely clear that we must address this problem.

Russ instructed me to run the proposal by the CFRG and if they did not
raise strong objections the WG could take that approach if it desired.

The rest of this message is my opinion as an individual participant.

If our goal is the avoid expansion, there is a secure way to do that.
We can use counter mode instead of CBC.  That would make our AES mode
work a lot like our RC4 mode.  You need to be careful when using a
counter-mode cipher, but we already have this complexity for RC4.

We decided against counter mode for complexity reasons.  However if we
need the features of counter mode I'd rather see us take that
approach.

--Sam

Date: Tue, 16 Nov 2004 16:53:42 -0500
From: Tony Hansen <[email-masked]>
To: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Go for it. I hope there's enough support this go around.

	Tony Hansen
	[email-masked]

Ken Murchison wrote:

> Alexey Melnikov wrote:
> 
>> Tony Hansen wrote:
>>
>>> Both Chris and I saw the need for such a SASL mechanism. His proposal 
>>> was definitely more fleshed out than mine; I didn't want to go into 
>>> all the work of fleshing mine out until I got support from the 
>>> community.
>>>
>>> However, neither of us got much support as to the need, and both 
>>> proposals withered and died.
>>>
>>> But I still feel that the need is there.
>>
>> This seems to suggest that we need to find an energetic editor (and I 
>> am not volunteering).
> 
> I'll volunteer.  I'd probably start by respinning Chris' draft, if 
> people feel its a good starting place.  Since I've already written a 
> plugin based on this spec, I have an obvious bias towards it.
> 

Date: Tue, 16 Nov 2004 16:30:18 -0500
From: Tony Hansen <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

You're assuming that I remembered Chris' document when I wrote mine. 
Remember that there were 5 years between the two drafts. :-)

I would be very happy with what Chris proposed.

	Tony Hansen
	[email-masked]

Ken Murchison wrote:

> Tony Hansen wrote:
> 
>> Both Chris and I saw the need for such a SASL mechanism. His proposal 
>> was definitely more fleshed out than mine; I didn't want to go into 
>> all the work of fleshing mine out until I got support from the community.
>>
>> However, neither of us got much support as to the need, and both 
>> proposals withered and died.
>>
>> But I still feel that the need is there.
> 
> Did/do you envision something different from what Chris had come up 
> with?  I assume you must otherwise you would've just revived the PASSDSS 
> draft.

Date: Tue, 16 Nov 2004 09:53:13 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: Tony Hansen <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Alexey Melnikov wrote:

> Tony Hansen wrote:
> 
>> Both Chris and I saw the need for such a SASL mechanism. His proposal 
>> was definitely more fleshed out than mine; I didn't want to go into 
>> all the work of fleshing mine out until I got support from the community.
>>
>> However, neither of us got much support as to the need, and both 
>> proposals withered and died.
>>
>> But I still feel that the need is there.
> 
> 
> This seems to suggest that we need to find an energetic editor (and I am 
> not volunteering).

I'll volunteer.  I'd probably start by respinning Chris' draft, if 
people feel its a good starting place.  Since I've already written a 
plugin based on this spec, I have an obvious bias towards it.

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

Date: Tue, 16 Nov 2004 13:26:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Tony Hansen wrote:

> Both Chris and I saw the need for such a SASL mechanism. His proposal 
> was definitely more fleshed out than mine; I didn't want to go into 
> all the work of fleshing mine out until I got support from the community.
>
> However, neither of us got much support as to the need, and both 
> proposals withered and died.
>
> But I still feel that the need is there.

This seems to suggest that we need to find an energetic editor (and I am 
not volunteering).

Date: Mon, 15 Nov 2004 14:33:33 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tony Hansen <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Tony Hansen wrote:

> Both Chris and I saw the need for such a SASL mechanism. His proposal 
> was definitely more fleshed out than mine; I didn't want to go into all 
> the work of fleshing mine out until I got support from the community.
> 
> However, neither of us got much support as to the need, and both 
> proposals withered and died.
> 
> But I still feel that the need is there.

Did/do you envision something different from what Chris had come up 
with?  I assume you must otherwise you would've just revived the PASSDSS 
draft.

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

Date: Mon, 15 Nov 2004 12:14:16 -0500
From: Tony Hansen <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Both Chris and I saw the need for such a SASL mechanism. His proposal 
was definitely more fleshed out than mine; I didn't want to go into all 
the work of fleshing mine out until I got support from the community.

However, neither of us got much support as to the need, and both 
proposals withered and died.

But I still feel that the need is there.

	Tony Hansen
	[email-masked]

Ken Murchison wrote:

> Continuing a conversation started during the IETF meeting...
> 
> I'm solitciting opinions for/against creating a new non-plaintext SASL 
> mech which allows the plaintext password to be recovered by the server.
> ...
> 2. Create a new SASL mech in which the plaintext password is not sent in 
> the clear, but is recoverable by the server.  Tony Hansen hinted at such 
> a mech with his strawman draft last year:
> 
> http://www.watersprings.org/pub/id/draft-hansen-sasl-pki-00.txt
> 
> and Chris Newman fully documented such a mech back in 1998:
> 
> http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt
> 
> Both the PKI and PASSDSS mechs are similiar in that they do a DH key 
> exchange and then encrypt the password.  Chris' mech is actually an 
> SSH2-style negotiation in which the privacy/integrity protection MAY be 
> used to protect the entire session.  The PASSDSS mech is pretty straight 
> forward as I implemented a plugin for Cyrus SASL in about a day using 
> OpenSSL libcrypto.
> 
> So, is a niche market like NNTP worth creating a new SASL mech for, or 
> should we find a way to either force them to use TLS or make it more 
> palatable (as described above)?  The advantage of using TLS is that 
> we're not reinventing the wheel (since any new SASL mech would probably 
> look a lot like TLS or SSH) and we gain the ability to negotiate 
> compression for the session.  The advantage of a new SASL mech is that 
> its a lot cleaner IMO and we eliminate any potential security problems 
>  by using fiddling with the TLS session.
> 

Date: Sun, 14 Nov 2004 17:34:39 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Kurt D. Zeilenga wrote:

  > Note that in our LDAP implementation (if we did allow this, we'd
> likely move the authorization state to anonymous status upon downgrade
> to NULL) as without the integrity protection the session is open to
> hijack attack.

Actually with OpenSSL, it doesn't let you remove the integrity layer (at 
least not that I could find).

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

Date: Sun, 14 Nov 2004 17:33:18 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Sam Hartman <[email-masked]>
CC: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
Sender: [email-masked]

Sam Hartman wrote:

> I think having this SASL mech would generally be a good idea.  I think
> any such mech should provide security layers as an option.

Chris' PASSDSS allows integrity and/or privacy to be negotiated for the 
entire session.

My biggest question about PASSDSS is should it allow for multiple 
ciphers and other types of public keys (e.g. RSA)?

Sam, as a Security Area Director, can you have someone look at PASSDSS 
from a security standpoint?  Especially 3DES CBC mode.  My guess is that 
if SSH2 gets published then PASSDSS wouldn't have any problems.

-- 
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: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 14 Nov 2004 12:16:45 -0800
Sender: [email-masked]

Kurt D Zeilenga <[email-masked]> writes:

> While the news itself may not be sensitive information, many
> users likely consider their choice of what news they read to
> be sensitive information.

Yeah, like most security decisions, it's a tradeoff.  It would clearly be
better to continue to encrypt the entire session, from a security
standpoint, to prevent session hijacking and to keep user transactions
confidential.

However, NNTP sessions frequently involve *huge* amounts of data.  (Unlike
e-mail services, the significant majority of NNTP reader traffic these
days is centralized at a few widely used NNTP providers, who are used as
outsourcing providers by ISPs, and also unlike e-mail, the vast majority
of Usenet traffic by volume is large encoded binaries.)  What I've heard
from admins at such providers is that supporting TLS for every session
would involve significant new hardware purchases, and the potential attack
vectors just don't seem to justify that right now.  Customers aren't
demanding TLS to protect their reading data; quite to the contrary, they
don't want anything that makes their news sessions slower.

I could go on about how much RADIUS annoys me (I've run into this
cleartext password problem in a whole host of other places as well), but
it does seem to be what people use at the moment.  Right now, most news
providers are just using cleartext passwords without TLS protection at
all, despite the fact that this is known to be insecure, because there
aren't any other alternatives that are fast enough for their purposes and
widely supported by news readers.  Of course, any new authentication
mechanism also won't be widely supported by news readers at first, but I
can hope that something obviously useful for NNTP will be picked up.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>
Subject: Re: New SASL mech?
From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2004 15:02:30 -0500
Sender: [email-masked]

I think having this SASL mech would generally be a good idea.  I think
any such mech should provide security layers as an option.

Date: Sun, 14 Nov 2004 09:50:17 -0500
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: New SASL mech?
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

At 08:54 AM 11/14/2004, Ken Murchison wrote:
>Continuing a conversation started during the IETF meeting...
>
>I'm solitciting opinions for/against creating a new non-plaintext SASL mech which allows the plaintext password to be recovered by the server.
>
>The rationale for such a mech is this:  While working on the NNTP SASL profile, it has been brought to my attention that many NNTP servers forward authentication off to another server such as a Radius server. In this case, the server MUST have access to the plaintext password, which eliminates shared secret mechs such as CRAM-MD5, DIGEST-MD5, etc.  Currently, the only way to do this is to use a plaintext mechanism in conjunction with TLS.  However, several of the NNTP folks have told me that TLS protecting an entire NNTP session (which is almost always public data) just to protect the password is overkill and in some cases unreasonable given the sheer volume of traffic.  I have tried arguing for the use of TLS+PLAIN, but I continually get shot down as an outsider who "doesn't understand NNTP".

While the news itself may not be sensitive information, many
users likely consider their choice of what news they read to
be sensitive information.

>I see two solutions to this problem:
>
>1.  Use TLS+PLAIN but allow the server to either shutdown the TLS session or renegotiate the session down to the NULL cipher. Both options are already allowed in TLS and can be done without killing the NNTP connection.  As a test, I have implemented both in Cyrus nntpd and the Cyrus test client and with a little tweaking of the code they do work.
>What I don't know about these techniques is what the security implications are.  Obviously, the TLS shutdown or renegotiation MUST NOT be allowed prior to completion of the authentication.  In the case of renegotiating down to the NULL cipher, this session MUST NOT be allowed to be resumed as an initial session.

This option introduces significant complexity into implementations.
In our LDAP implementation, we simply refuse to allow downgrade as
it is too difficult to properly manage all the security associations
(e.g., ensuring responses for operations sent in the protected
channel are not sent in the unprotected channel, managing authorization
state, etc.).

Note that in our LDAP implementation (if we did allow this, we'd
likely move the authorization state to anonymous status upon downgrade
to NULL) as without the integrity protection the session is open to
hijack attack.

>2. Create a new SASL mech in which the plaintext password is not sent in the clear, but is recoverable by the server.  Tony Hansen hinted at such a mech with his strawman draft last year:
>
>http://www.watersprings.org/pub/id/draft-hansen-sasl-pki-00.txt
>
>and Chris Newman fully documented such a mech back in 1998:
>
>http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt
>
>Both the PKI and PASSDSS mechs are similiar in that they do a DH key exchange and then encrypt the password.  Chris' mech is actually an SSH2-style negotiation in which the privacy/integrity protection MAY be used to protect the entire session.  The PASSDSS mech is pretty straight forward as I implemented a plugin for Cyrus SASL in about a day using OpenSSL libcrypto.
>
>So, is a niche market like NNTP worth creating a new SASL mech for, or should we find a way to either force them to use TLS or make it more palatable (as described above)?  The advantage of using TLS is that we're not reinventing the wheel (since any new SASL mech would probably look a lot like TLS or SSH) and we gain the ability to negotiate compression for the session.  The advantage of a new SASL mech is that its a lot cleaner IMO and we eliminate any potential security problems  by using fiddling with the TLS session.

The market may not be limited to NNTP.

I note that SASL mechanisms are free to provide compression services
in addition to data security services.

Kurt 

Date: Sun, 14 Nov 2004 08:54:25 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: New SASL mech?
Sender: [email-masked]

Continuing a conversation started during the IETF meeting...

I'm solitciting opinions for/against creating a new non-plaintext SASL 
mech which allows the plaintext password to be recovered by the server.

The rationale for such a mech is this:  While working on the NNTP SASL 
profile, it has been brought to my attention that many NNTP servers 
forward authentication off to another server such as a Radius server. 
In this case, the server MUST have access to the plaintext password, 
which eliminates shared secret mechs such as CRAM-MD5, DIGEST-MD5, etc. 
  Currently, the only way to do this is to use a plaintext mechanism in 
conjunction with TLS.  However, several of the NNTP folks have told me 
that TLS protecting an entire NNTP session (which is almost always 
public data) just to protect the password is overkill and in some cases 
unreasonable given the sheer volume of traffic.  I have tried arguing 
for the use of TLS+PLAIN, but I continually get shot down as an outsider 
who "doesn't understand NNTP".

I see two solutions to this problem:

1.  Use TLS+PLAIN but allow the server to either shutdown the TLS 
session or renegotiate the session down to the NULL cipher.  Both 
options are already allowed in TLS and can be done without killing the 
NNTP connection.  As a test, I have implemented both in Cyrus nntpd and 
the Cyrus test client and with a little tweaking of the code they do work.

What I don't know about these techniques is what the security 
implications are.  Obviously, the TLS shutdown or renegotiation MUST NOT 
be allowed prior to completion of the authentication.  In the case of 
renegotiating down to the NULL cipher, this session MUST NOT be allowed 
to be resumed as an initial session.

2. Create a new SASL mech in which the plaintext password is not sent in 
the clear, but is recoverable by the server.  Tony Hansen hinted at such 
a mech with his strawman draft last year:

http://www.watersprings.org/pub/id/draft-hansen-sasl-pki-00.txt

and Chris Newman fully documented such a mech back in 1998:

http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt

Both the PKI and PASSDSS mechs are similiar in that they do a DH key 
exchange and then encrypt the password.  Chris' mech is actually an 
SSH2-style negotiation in which the privacy/integrity protection MAY be 
used to protect the entire session.  The PASSDSS mech is pretty straight 
forward as I implemented a plugin for Cyrus SASL in about a day using 
OpenSSL libcrypto.

So, is a niche market like NNTP worth creating a new SASL mech for, or 
should we find a way to either force them to use TLS or make it more 
palatable (as described above)?  The advantage of using TLS is that 
we're not reinventing the wheel (since any new SASL mech would probably 
look a lot like TLS or SSH) and we gain the ability to negotiate 
compression for the session.  The advantage of a new SASL mech is that 
its a lot cleaner IMO and we eliminate any potential security problems 
  by using fiddling with the TLS session.

-- 
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: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Section 3.2 in 2222bis
From: Sam Hartman <[email-masked]>
Date: Sat, 13 Nov 2004 19:28:56 -0500
Sender: [email-masked]

Authentication identities may not be unicode or even characters.  They
may be DNs, Kerberos principals, public keys, etc.

--Sam

Date: Thu, 11 Nov 2004 10:35:08 -0500
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Summary of the SASL WG session @ IETF#61
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The SASL WG met on Tuesday afternoon for 1 hour.

It was noted that Sam Hartman will be stepping down as
co-chair to take on Security AD duties.  He was thanked
for his fine service to the WG.  It was also noted that
the Security ADs are seeking a suitable co-chair replacement.
Those who have recommendations in this area were encouraged
to contact Russ, Sam, or Steve.

The WG discussed the recent WGLC of the sasl-rfc2222bis I-D
and issues with the subsequently revision.  Currently, it
is believed that at least one more revision of the I-D will
be necessary to address a number of issues including:
  - ensure the "rekeying" text reflects consensus established
    during the WGLC,
  - ensure the "identity" issues are resolved.
The later issue will require more eyes on it and more
discussion.  The room (and jabber) was polled as to who has
reviewed the I-D front-to-back.  The response indicated
that the I-D has not yet been adequately reviewed by
the WG.

The working group briefly discussed status of the various
other WG I-Ds.  For each I-D, the chairs polled the room
(and jabber) as to who has reviewed each and for each the
response indicated inadequate review by the WG.

The chairs asked the WG to focus review energy on the
sasl-rfc2222bis I-D in hopes to complete our work on this
draft by the end of the year.

-- Kurt, SASL chair

Date: Thu, 11 Nov 2004 01:03:33 -0600
From: Nicolas Williams <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Love <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments: gssapi-domain-based-name
Mail-Followup-To: "Kurt D. Zeilenga" <[email-masked]>, Sam Hartman <[email-masked]>, Love <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Love's point is that RFC2222 specifically talks about what server names
are like, and that is like hostbased-services.  Introducing new name
types for SASL mechs may require changing this.

Nico
-- 

Date: Wed, 10 Nov 2004 15:08:39 -0500
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Comments: gssapi-domain-based-name
Cc: Love <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 09:49 AM 11/10/2004, Sam Hartman wrote:

>>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
>
>    Nicolas> On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote:
>    >>  I think that sasl needs to be modified to use domain based
>    >> names.
>    >> 
>    >> rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE
>    >> with service and hostname as service@hostname.

To be clear, its the "GSSAPI" mechanism specification in RFC 2222
which wants this... not the SASL framework specification that
wants this.

>    Nicolas> Yes.  At this rate rfc2222bis might as well be modified
>    Nicolas> accordingly and have a reference to the domain based
>    Nicolas> naming i-d added to be.
>
>Are there any 2222 implications or is it just a gssapi implication?

This might have "GSSAPI"-bis implications (sasl-gssapi), but it
shouldn't have any SASL framework (sasl-2222bis) implications.

Kurt 

To: Love <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Comments: gssapi-domain-based-name
From: Sam Hartman <[email-masked]>
Date: Wed, 10 Nov 2004 09:49:26 -0500
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote:
    >>  I think that sasl needs to be modified to use domain based
    >> names.
    >> 
    >> rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE
    >> with service and hostname as service@hostname.

    Nicolas> Yes.  At this rate rfc2222bis might as well be modified
    Nicolas> accordingly and have a reference to the domain based
    Nicolas> naming i-d added to be.

Are there any 2222 implications or is it just a gssapi implication?

Date: Tue, 9 Nov 2004 17:29:54 -0600
From: Nicolas Williams <[email-masked]>
To: Love <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Comments: gssapi-domain-based-name
Mail-Followup-To: Love <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote:
> 
> I think that sasl needs to be modified to use domain based names.
> 
> rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE with service
> and hostname as service@hostname.

Yes.  At this rate rfc2222bis might as well be modified accordingly and
have a reference to the domain based naming i-d added to be.

> and since nico uses ldap, that uses sasl, as an example. I think think
> needs to make into consideration if the example is ever is going to work.

Yes.

Thanks for pointing this out.

Nico
-- 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Section 3.2 in 2222bis
Date: Tue, 09 Nov 2004 23:01:50 +0100
Lines: 67
Cancel-Lock: sha1:KqUm9kumhYSNAUblgpu+odXYoH0=
Sender: [email-masked]

Hello.  One idea for section 3.2.

OLD:

   SASL mechanism specifications describe the form of credentials
   used to authenticate clients, and SASL application
   profiles describe the form of authorization identities
   transferred as part of authentication exchange.
   However, the
   precise form(s) of the authentication identities (used
   within the server in its verifications, or otherwise)
   and the precise form(s) of the authorization identities
   (used in making authorization decisions, or otherwise) is
   beyond the scope of the SASL and this specification.  In
   some circumstances, the precise identity forms used
   outside of the SASL exchange may be dictated by other
   specifications.  For instance, the authorization policy
   specification for an application protocol may dictate the
   precise form that an authorization identity is to be
   represented in the authorization policy.

   <<Need to address few issues in the two remaining paragraphs>>
   Any normalization of the authentication identity (for the purposes
   of conducting authentication exchange) is defined by a particular
   SASL mechanism, the protocol profile doesn't influence it.
   Note, that the mechanism specification doesn't control how
   authentication identity information is represented elsewhere
   <<need to add few examples>>.

   The mechanism MUST preserve Unicode codepoints when transferring
   authorization identity (e.g. the mechanism can't apply any form
   of normalization).

NEW:

   SASL mechanism specifications describe the credentials used to
   authenticate clients.  SASL application profiles describe the
   authorization identities transferred as part of authentication
   exchange.

   The authentication and authorization identities are assumed to be
   arrays of Unicode code points.

   The mechanism MUST preserve Unicode code points when transferring
   the authorization identity.  Specifically, the mechanism cannot
   apply any form of normalization on authorization identities.  The
   mechanism MAY normalize the authentication identity before or after
   sending it from the client to the server.

   The application profile MUST NOT place any requirements on the
   authentication identity that is to be transfered by the mechanism.
   Specifically, the application profile cannot apply any form of
   normalization to the authentication identity.  The application
   profile MAY normalize the authorization identity before or after
   sending it from the client to the server.

   The encoding (e.g., UTF-8 or UCS-4) of the authentication identity
   (used within the server in its verifications, or otherwise) and the
   encoding of the authorization identity (used in making
   authorization decisions, or otherwise) is beyond the scope of the
   SASL and this specification.  In some circumstances, the encodings
   used may be dictated by other specifications.  For instance, the
   authorization policy specification for an application protocol may
   dictate that a specific encoding of the authorization identity is
   used.

Thanks.

Date: Tue, 09 Nov 2004 17:01:11 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Changes to the DIGEST-MD5 document
Sender: [email-masked]

I don't think if I've sent a message on this. Below I summarize the 
changes between -03 and -04:

1). Clarified text about realms:
 a). server is not required to advertise all realms it supports.
 b). added more examples
 c). added a new section with requirements on UIs as per discussion with 
Paul Leach.
2). Changed informative "should abort the authentication exchange" to 
"MUST/SHOULD about the authentication exchange" depending on context:
 a). no qop option is recognized by the client - MUST
 b). multiple "stale" directives - MUST
 c). failed SASLPrep on a username - SHOULD
 d). missing or multiple "algorithm" directives - SHOULD (is MUST better 
here?)
 e). multiple "charset" directives - MUST
3). Clarified that if the client recognizes no ciphers, it should behave 
as if "auth-conf" qop was not advertised by the server.
4). Changed "a buffer of security encoded data" to "a buffer of 
protected data", as per terminology change in rfc2222bis.
5). Cleaned up "Changes since ..." section.

I am still waiting for some input from Sam about how to resolve the 
CBC-mode attack fix.

Alexey

Date: Tue, 09 Nov 2004 15:46:53 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt
Sender: [email-masked]

[email-masked] wrote:

>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-09.txt
>	Pages		: 11
>	Date		: 2004-10-27
>	
>The Simple Authentication and Security Layer (SASL) is a framework
>   for providing authentication and data security services in
>   connection-oriented protocols via replaceable mechanisms. It provides
>   a structured interface between protocols and mechanisms.  The
>   resulting framework allows new protocols to reuse existing mechanisms
>   and allows old protocols to make use of new mechanisms.  The
>   framework also provides a protocol for securing subsequent protocol
>   exchanges within a data security layer.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt
>
>  
>
Hi everyone,
I don't think there is a point of providing a detailed list of changes from -08, as this is going to be a huge list. I think I've incorporated most of the editorial suggestions by Nicolas, Kurt and Hallvard, as well as addressed most of the Last Call issues. The remaining Last Call issues are described below:

1). Section 3.2. (Identity Concepts) needs review.

In particular text about normalization:

   Any normalization of the authentication identity (for the purposes
   of conducting authentication exchange) is defined by a particular
   SASL mechanism, the protocol profile doesn't influence it.
   Note, that the mechanism specification doesn't control how
   authentication identity information is represented elsewhere
   <<need to add few examples>>.

   The mechanism MUST preserve Unicode codepoints when transferring
   authorization identity (e.g. the mechanism can't apply any form
   of normalization).

The following text was lost in -09:

  The authorization identity is made available to further server
  processing for use in making access policy decisions.  The provision
  of additional client attributes that may affect access policy is not
  covered by this specification.

I think it falls under <<need to add few examples>>

2). In Section 5 (Mechanism profile guidelines) I've added text about re-keying. There is the original Nico's version of the text as well as mine (rewrite of Nico's text, hopefully it is clearer).

   6) SASL does not provide for re-keying (see Section 9.1), but SASL
      mechanisms may.

   <<Original Nico's text follows:>>
   SASL mechanisms that support re-keying SHOULD:
    - indicate that re-keying is or will be needed immediately;
    - provide re-keying messages or transparently include re-keying
      messages in the security layers; the latter can happen without
      application involvement, but only as long as the application is
      engaged in timely bidirectional exchanges with its peer.

   <<Alternative text by Alexey:>>
   A SASL mechanism supports re-keying if it is able to generate/process
   messages that request immediate re-keying and it is able to carry out
   re-keying exchange. (Note that the mechanism MAY use a single message
   type to do both). SASL mechanisms that support re-keying MAY also be
   able to indicate that re-keying will be needed in the future.
   A re-keying exchange can be conducted transparently by the mechanism,
   or the mechanism should be able to provide/accept re-keying messages
   to/from the application. The former can happen without application
   involvement, but only as long as the application is engaged in timely
   bidirectional exchanges with its peer.

3). Text in Section 9.1. (Re-keying) needs review. In particular text in <<>>. Do we need to keep it? Does it have to be 

   The secure or administratively permitted lifetimes of SASL
   mechanisms' security layers are finite.  Cryptographic keys weaken as
   they are used and as time passes; the more time and/or ciphertext
   that a cryptanalyst has after the first use of the a key, the easier
   it is for the cryptanalyst to mount attacks on the key.

   Administrative limits on security layers lifetime may take the form
   of time limits expressed in x.509 certificates, Kerberos V tickets,
   or in directories, and are often desired.  <<In practice one likely
   effect of administrative security layers lifetime limits is that
   applications may find that security layers stop working in the middle
   of application protocol operation, such as, perhaps, during large
   data transfers.  As the result of this the connection will be closed
   (see section 3.3), which will result in unpleasant user experience.>>

   Re-keying (key renegotiation process) is a way of addressing the
   weakening of cryptographic keys. SASL framework does not provide for
   re-keying.  SASL mechanisms may; all future SASL mechanisms that
   provide security layers should provide for re-keying.

Alexey