Subject: Re: rfc2222bis: re-negotiating SASL security layer

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 14:22:06 +0000

>
>
>>>rfc2222bis section 6.3 "Multiple authentications" says:
>>>
>>>  If a security layer is in effect
>>>  and a subsequent SASL negotiation selects a second security layer,
>>>  then the second security layer replaces the first. If a security
>>>  layer is in effect and a subsequent SASL negotiation selects no
>>>  security layer, the original security layer must be removed.
>>>
>>>Exactly when is the old layer canceled?
>>>
>>>If an old layer is active and the client starts to negotiate a new
>>>layer, it may not know when to expect the response from the server.
>>>So the layer can't be canceled by starting a new negotiation.
>>>      
>>>
>>No, the layer can only be canceled/replaced after a subsequent 
>>authentication completes successfully.    
>>
>
>OK.  Please mention that explicitly.
>
After rereading the LDAP document that discusses SASL I finally realised 
why this is not obvious :-). The new text reads:

If a profile explicitly permits multiple successful SASL
negotiations to occur, then in no case may multiple security layers be
simultaneously in effect.  If a security layer is in effect
and a subsequent SASL negotiation selects a second security layer,
then the second security layer replaces the first. If a security layer
is in effect and a subsequent SASL negotiation selects no security layer,
the original security layer MUST be removed. The rest of this section 
explain
why this is important. Also note, that if a subsequent authentication fails,
the protocol profile MAY allow the connection state to return to 
non-authenticated,
however the previously negotiated security layer MUST NOT be removed. Only
a successful reauthentication is able replace/remove the previously 
negotiated
security layer.

>>Each profile document must document exactly when this takes place.    
>>
>
>'this' = 'it completed successfully', I take it.
>  
>
Yes.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Nov 2003 10:15:42 -0800

Alexey,

RFC 2222 said:
  If a security layer is in effect and a subsequent SASL negotiation
  selects no security layer, the original security layer remains in effect.

I think changing this is bad.

The primary reason posted on the list for the change was: "Applications
should be allowed to remove layers."   I argue that this is, effective,
adding a new feature to SASL.  Adding new features is beyond our scope.

The primary reason given in the draft is to address a security concern.
I would suspect that there are numerous other cases, including where
re-authentication is not involved, where another party may have direct
knowledge of information being encrypted.  For example, the same concern
arises when an LDAP server provides results obtained through chaining.
Or by an LDAP client is chasing a referral.  This concerns, I think,
would be better addressed by stating security consideration.

The primary reason why this is better is because the change will cause
significant interoperability problems.  Existing implementations expect
those layers to remain in effect.

Kurt

At 06:22 AM 11/1/2003, Alexey Melnikov wrote:

>>>No, the layer can only be canceled/replaced after a subsequent authentication completes successfully.    
>>
>After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads:
>
>the original security layer MUST be removed. The rest of this section explain
>the protocol profile MAY allow the connection state to return to non-authenticated,
>a successful reauthentication is able replace/remove the previously negotiated
>security layer.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 18:55:46 +0000

>adding a new feature to SASL.  Adding new features is beyond our scope.
I never said that and I don't believe this is an important feature.

>would be better addressed by stating security consideration.
Kurt, I think you are missing the point. You are describing authorized 
disclosure (or something similar to a situation when one end of the 
connection is broadcasting decrypted data over the network in the 
clear). The draft describes a potential security vulnerability.
I understand your concern about LDAP backward compatibility (as LDAP is 
the only protocol I know that allows for reauthentication),
but there is no point of propagating something which is known to be 
broken to new protocols.

>those layers to remain in effect.
How about changing MUST to SHOULD to allow for backward compatibility 
for LDAP?

Alexey

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Nov 2003 12:35:06 -0800

At 10:55 AM 11/1/2003, Alexey Melnikov wrote:
>The draft describes a potential security vulnerability.

I don't disagree that there is a potential security vulnerability.
I disagree that we should address it by changing the protocol.  The
issue can be (and, in my opinion, should be) addressed through statement
of appropriate security considerations.

I think we're talking about the same class of attacks.  There are
numerous cases where a third party (such as BB in your discussion)
have limited knowledge of protected content and could use that knowledge
to mount an attack.

Note that your solution doesn't complete eliminate this particular
case as the old layers are in-effect during the reauthentication.
Server BB could still use its knowledge of the reauthentication process
to attack the encryption of previously sent information.

I think the risk of this class of attack is not sufficient to warrant
changing the protocol especially considering the interoperability
(and security?) problems the change would cause.

I say "and security?" as now traffic which an old client expected to be
protected by old layers would not be protected.  We have to consider that
as well.

>I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication),  but there is no point of propagating something which is known to be broken to new protocols.

I don't consider SASL broken in this respect.  It just that there are
security concerns to be considered.

>How about changing MUST to SHOULD to allow for backward compatibility for LDAP?

A SHOULD would be inappropriate as interoperability mandates that either all
implementations keep the layer or all implementations drop the layer.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 20:42:39 +0000

>implementations keep the layer or all implementations drop the layer.
SHOULD in protocol profile, not "SHOULD keep/drop the old layer".

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 20:43:09 +0000

> How about changing MUST to SHOULD to allow for backward compatibility 

Thinking more about this. What I didn't like about the original text is 
that it was kind of MUST.
What if I rephrase to allow a protocol profile to have a choice: either 
keep the original layer if none was negotiated during reauthentication 
(and have a security consideration about the issue) or remove the 
original layer.
If the protocol profile chooses to do the former, it should recommend to 
always negotiate a new security layer during reauthentication.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Nov 2003 19:32:17 +0000

Alexey Melnikov wrote:

> Thinking more about this. What I didn't like about the original text 
> is that it was kind of MUST.
> What if I rephrase to allow a protocol profile to have a choice: 
> either keep the original layer if none was negotiated during 
> reauthentication (and have a security consideration about the issue) 
> or remove the original layer.
> If the protocol profile chooses to do the former, it should recommend 
> to always negotiate a new security layer during reauthentication. 

Ok, the new text reads:

the protocol profile has to specify a choice between:

1) keeping the original security layer.
2) removing the original security layer (replacing with no layer).

RFC 2222 only allowed for the first choice, however it was later 
discovered that the choice is vulnerable to a security attack described 
later in this section. Thus, new protocol profiles should use the second 
choice. The protocol profiles that depend on RFC 2222 behaviour should 
recommend to always negotiate another security layer, once a security 
layer was installed.

Also note, that if a subsequent authentication fails,
the protocol profile MAY allow the connection state to return to
non-authenticated, however the previously negotiated security layer MUST NOT
be removed. Only a successful reauthentication is able replace/remove the
previously negotiated security layer.

Hopefully this will make everybody happy.

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 5 Nov 2003 20:49:53 +0100

Alexey Melnikov writes:
> (...) Only a successful reauthentication is able replace/remove the

Just to make sure it has been mentioned:

This also means that non-SASL authentication must keep any old SASL
layer.  I expect that's intended, including for LDAPv4?

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 5 Nov 2003 22:32:30 +0100

> (...)
> If a security layer

This belongs in section 5 (Protocol Profile Requirements).
I suggest to indent (1) and (2), BTW.

> the protocol profile MAY allow the connection state to return to

I can't find anything about that in section 5.  Is it this text?

   "A protocol profile MAY further refine the definition of an
   authorization identity by adding additional syntactic restrictions
   and protocol-specific semantics."

If so, maybe that sentence should be clarified to explicitly allow the
protocol profile to say something about the effect of authentication on
authentication/authorization IDs.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 02:00:33 +0100

rfc2222bis says:
> selects no security layer, (...)

Please rephrase as either 'does not select a security layer' (like
PLAIN) or '(explicitly) selects that there should be no security layer'
(which PLAIN does _not_ do).  I presume it's the former.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 10:35:10 +0000

>This belongs in section 5 (Protocol Profile Requirements).
Yes, this is also mentioned in section 5 [in my copy].

>   and protocol-specific semantics."
No.
This is a new text added to allow for LDAP behaviour.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 10:52:30 +0000

>(which PLAIN does _not_ do).  I presume it's the former.
No, I actually mean both. DIGEST-MD5 has a mode when you can explicitly 
negotiate no security layer.

I would welcome any suggestions to make this clearer.

Alexey

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.ht

___________________________________________

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 16:18:50 +0100

Alexey Melnikov writes:
> No, I actually mean both.

Now I'm confused.  If a SASL security layer is active and I authenticate
with PLAIN, is the layer removed or not?  If it is removed, my first
suggested text above clarifies that.  If it is not, my second text.  Are
there other alternatives?

> DIGEST-MD5 has a mode when you can explicitly 

Where?  A search for 'layer' in rfc2831bis-02 only turns up the
reference

   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Nov 2003 07:14:25 -0800

>I would welcome any suggestions to make this clearer. 

I think one of the problems we have adding this profile option
is that the specification is now much more complex and
framework implementations, especially those which support both
options, will need to be much more complex.  We need to keep
SASL and the specification of SASL simple.

I don't see the risk from the described threat being so high
to warrant the insertion of this option ESPECIALLY given that
the option doesn't not fully address the vulnerability.  The
information sent under the subsequent layers is still contains
information known by those involved in the reauthentication.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 16:22:20 +0100

> This is a new text added to allow for LDAP behaviour.

That it allows for LDAP is fine, but I'm wondering about the text 'the
protocol profile MAY allow the connection state to return to
non-authenticated'.  If it's not the text I quoted, allowing the
connection state to return to non-authenticated has nothing to do with
the protocol profile at all.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 16:07:51 +0000

>there other alternatives?
Using your own words: PLAIN (implicitly) selects that there should be no 
security layer, as it is unable to negotiate any.

>              (SASL)", RFC 2222, October 1997.
Sections 2.3 and 2.4.

Also search for  "qop-options"

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST)

> SASL and the specification of SASL simple.

I have to agree with Kurt here.  One of the major benefits of SASL is that
the framework layer has been historically simple.  Allowing both modes
(dropping the layer or continuing under the old layer) needlessly
complicates the implementation and breaks backwards compatibility for
minimal gain.

> information known by those involved in the reauthentication.

I tend to agree with this assessment.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 21:14:26 +0000

Rob Siemborski wrote:

>complicates the implementation
>
Which implementation are you talking about?

> and breaks backwards compatibility for
>minimal gain.
>
A protocol profile is not allowed to do both. It has to document a choice.
This is a checkbox.

There is only a single protocol that currently allows for reauthentication.

>>the option doesn't not fully address the vulnerability.
>>
True. But it is more difficult to implement an attack during 
reauthentication. And servers should drop connection after some number 
of failed authentications.

>>  The
Actually, I am not sure I understand what are you saying here Kurt.

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST)

> Which implementation are you talking about?

I'll use the CMU SASL implementation as an example, but I don't think it
really matters.

Using RFC2222, if you had a re-authentication and the new session didn't
have a security layer, you would need to keep the old SASL context around
and continue to use it for security layer purposes (from an API
standpoint, this sucks, granted).

In 2222bis-03, you no longer have to do this, but it breaks LDAP as
deployed (which is bad).

In your suggested text, there's no longer a set way of handling this -- it
varies from protocol to protocol (as long as they allow reauthentication).
And its yet another thing that can be gotten wrong in an implementation.

In any case though, I suppose this is application layer not framework
layer.

Due to the related nature of many of the protocols that implement SASL, we
often see one product using SASL for many protocols at once (a mail client
can implement POP3, IMAP, SMTP, LDAP and IMSP/ACAP without breaking a
sweat, and a mail server can come close to twice that).  Subtle
differences between these protocols can be a nightmare for implementors
(just look at how similar the new POP3 and SMTP profiles are, yet how they
both have subtle differences).

I fear what will happen when we have another protocol that allows
reauthentication but does it in a different way from LDAP.

Then again, maybe you're right and the benefits of allowing it both ways
outweigh the implementation complexity -- especially given the (somewhat
inevitable, I think) upcoming "SASL Implementation Recommendations"
document.

> of failed authentications.

Are we both talking about the vulnerability discussed at the bottom of
section 6.3?

I may be misunderstanding the problem -- as I read it, we don't want the
initial realm to be able to read traffic going to the newly-authenticated
realm.   But if the new authentication doesn't have a security layer, how
is dropping the old security layer any benefit?  We're moving from a
tunneled layer (which, granted, can be read/modified by the initial realm)
to one that can be read/modified by anyone!

I definitely see a win with forcing a change when the new authentication
creates a new security layer, but in the absence of a new security layer,
I'm not seeing the benefit.

> Actually, I am not sure I understand what are you saying here Kurt.

Now that I re-read this, I'm not sure it applies to the vulnerability
discussed in 6.3.

However, it is true that if I know a good deal of the plaintext that you
are sending encrypted (e.g. I am a backend server and you are a proxy), I
have a huge advantage in trying to break your session key with a client.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Nov 2003 15:33:03 -0800

>Actually, I am not sure I understand what are you saying here Kurt. 

Part of the problem here is that I am (and maybe others are) having
trouble making sense of your scenario.   After further examination,
I think your text and picture don't match up.  The text implies
the layers are active between the client and the Realm A server
called AA, but your picture implies the layers are active between
the client and the middlebox ("proxy/frontend").

If the layers are active between the client and server AA,
then the middlebox could not normally insert a re-authenication to
server BB without coordination from AA.  That is, the middle
box would need to know how to decrypt/encrypt the exchanges
(before, during, after reauthentication).  If AA doesn't trust
the middlebox (and its relations with the likes of BB), then AA
simply need not provide the secrets to the middlebox necessary
to support reauthentication with others.  If AA does trust
the middlebox, then it implicitly accepts the risk of that trust.

If the layers are active between the client and middlebox,
the middlebox likely would need cooperation from AA to
support reauthentication to BB.  (In this case, it would be
better to call the middlebox the SASL server and AA and BB
"external systems" (not servers).)  If AA doesn't trust the
middlebox, then it should not cooperate with it.   But if it
does, even if layers are dropped, it (AA) would be vulnerable
to attack from BB because the subsequent exchange (which
BB has knowledge of) is protected by those layers.

In either case, this risk is quite limited and can be
managed as part of the trust relationship between AA and
the middlebox.

I think these scenarios are part of a larger class of
vulnerabilities: attacks from 3rd parties which have
limited knowledge of information protected by the SASL.
I think this class of vulnerabilities is best addressed
by stating a broad security consideration (possibly
supported by one or two specific examples).

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST)

> BB has knowledge of) is protected by those layers.

Ah, I think I misunderstood the example slightly [didn't understand how
the middlebox was playing with the rest of the system].  However, I still
agree with Kurt -- this is a minimal case that can be dismissed with a
Security Consideration about the trust relationships involved.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 9 Nov 2003 19:32:52 +0100

> layer.  I expect that's intended, including for LDAPv4?

Perhaps I should clarify a bit:

The current text does not allow protocols - e.g. LDAP - to say that
non-SASL authentication (in LDAP, that's "Simple Bind") should remove
the layer.  If we want protocols to be allowed to specify that,
rfc2222bis must say instead something like

   the protocol profile may specify that authentication by other means
   than SASL may remove the SASL security layer

or if we don't want SASL to 'know about' non-SASL auth at all, that

   ... the protocol may at any time decide by other means than SASL to
   remove the security layer

BTW, I'm not saying that we should do this.  Nor that we shouldn't.  I
simply want the issue to be deliberately decided rather than defaulted.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 19:23:00 +0000

Hallvard B Furuseth wrote:

>>>>Whether Simple bind removes or keep a previous security layer has 
>>>>nothing to do with SASL, this is very LDAP specific.
>>>>        
>>>>
>>>If SASL allowed LDAP to do so, it would be LDAP specific.
>>>      
>>>
>>SASL can't (and must not) document something it is not aware of. SASL 
>>doesn't have no be aware about Simple bind.
>>    
>>
>
>Your text does document that anything else than SASL authentication -
>and therefore also Simple Bind - may not remove the SASL security layer.
>
I am not sure that I wrote this anywhere in the document.
Anyway, even if I did, that wasn't the intent.

>Even though it's not aware of Simple Bind.  All it is aware of is that
>whatever Simple Bind is, it's not SASL.
>  
>
>>Simple bind is NOT SASL PLAIN,
>>    
>>
>
>I know.  That's why I brought it up.
>
>  
>
>>>It doesn't, so it isn't.
>>>      
>>>
>>Why?
>>    
>>
>
>Maybe I should start over.
>
>I did not say that SASL should say whether or not LDAP Simple Bind
>should remove the layer.  I said that the current text does not allow
>_LDAP_ to say that Simple Bind should remove the layer.  If we want LDAP
>- or other protocols - to be _allowed_ to specify that something like
>non-SASL Simple Bind should remove the layer, rfc2222bis must say
>instead something like
>
>or if you don't want SASL to 'know about' non-SASL auth, that
>
>BTW, I'm not saying that we should do this.  Nor that we shouldn't.
>I simply wanted the issue to be deliberately decided rather than
>defaulted.  That's all.
>  
>
IMHO, something that is not explicitly prohibited is allowed.

If the WG feels that this issue should be addressed, I will add some 
clarifying text.

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 21:06:54 +0100

> Anyway, even if I did, that wasn't the intent.

You are right, it's not in the document.  It's in two explanatory
messages from you in this thread:

  Date: Wed, 15 Oct 2003 12:52:04 +0100
  Message-ID: <[email-masked]>
  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html

  "No, the layer can only be cancelled/replaced after a subsequent 
  authentication completes successfully."

and

  Date: Sat, 01 Nov 2003 14:22:06 +0000
  Message-ID: <[email-masked]>
  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html

  "Only a successful reauthentication is able replace/remove the
  previously negotiated security layer."

> If the WG feels that this issue should be addressed, I will add some 

Well, I at least think it should be clarified.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 20:39:15 +0000

>  previously negotiated security layer."
I was thinking specifically about SASL [re]authentication when writing this.
My point was that a failed reauthentication didn't remove a previously 
negotiated security layer. This should apply to non-SASL 
reauthentications as well.

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 22:24:45 +0100

Alexey Melnikov writes:
> I was thinking specifically about SASL [re]authentication when writing
> this.  My point was that a failed reauthentication didn't remove a

Oh.  So... server and client may at any time agree to remove
the security layer, _except_ after failed reauthentication?

> This should apply to non-SASL reauthentications as well.

Except that in the message you quoted a few messages ago,
you didn't want SASL to know about non-SASL reauthentications,
so it shouldn't say anything about them.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 14:22:06 +0000

Yes.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Nov 2003 10:15:42 -0800

Alexey,

RFC 2222 said:

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 18:55:46 +0000

Alexey

Cell: +44 7753759732

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Nov 2003 12:35:06 -0800

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 20:42:39 +0000

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 20:43:09 +0000

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Nov 2003 19:32:17 +0000

Ok, the new text reads:

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 5 Nov 2003 20:49:53 +0100

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 5 Nov 2003 22:32:30 +0100

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 02:00:33 +0100

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 10:35:10 +0000

No.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 10:52:30 +0000

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 16:18:50 +0100

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Nov 2003 07:14:25 -0800

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2003 16:22:20 +0100

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 16:07:51 +0000

Sections 2.3 and 2.4.

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Nov 2003 21:14:26 +0000

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Nov 2003 15:33:03 -0800

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 9 Nov 2003 19:32:52 +0100

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 19:23:00 +0000

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 21:06:54 +0100

and

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 20:39:15 +0000

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 22:24:45 +0100

-- 
Hallvard