Subject: Re: [NNTP] Notes on auxiliary documents

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 1 Dec 2004 11:49:30 GMT

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>I would lean towards forgetting all state, since that's the obviously safe
>thing to do from a security standpoint.  I can't figure out the parameters
>of an attack that would exploit this, but I know that it can't be
>exploited if we forget state.

>However, there's MODE READER, and we can't forget that state,
>unfortunately; Mark made that point, and it's accurate.  That state I can
>argue doesn't pose any security issues, however, other than a DoS attack
>(which is generally uninteresting).  I can't make a similar argument about
>all server state.

>It seems to be more in the general spirit of SASL and TLS to discard all
>state after negotiating a security layer.

Yes, but I explained why the usual SASL spirit might not apply to NNTP in
my message of Nov 18th.

Most SASL application are there to prevent the Bad Guy from stealing MY
resources (e.g. money from my bank account). But NNTP is different; SASL
is there for protecting the server's resources from being used by the Bad
Guy. Preserving state across authentication does no harm in that
scenario, whereas _not_ preserving state _does_ do harm in the case I
outlined, where I am suddenly asked to authenticate in the middle of
reading a group because I suddenly encountered an article cross-posted to
some other group with special restrictions on it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 11:29:01 -0800

Charles Lindsey <[email-masked]> writes:

> Yes, but I explained why the usual SASL spirit might not apply to NNTP
> in my message of Nov 18th.

> is there for protecting the server's resources from being used by the
> Bad Guy. Preserving state across authentication does no harm in that
> reading a group because I suddenly encountered an article cross-posted
> to some other group with special restrictions on it.

I'm afraid that I don't find this argument particularly convincing.  The
point is to preserve the connection from outside tampering, and the reason
for discarding all state is that any amount of tampering might have
happened before the security layer was negotiated.

I'd be inclined to discard all server state except for the mode switch
when a security layer is negotiated, but I'd love to hear other opinions.

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 14:37:05 -0500

> when a security layer is negotiated, but I'd love to hear other opinions.

The current STARTTLS and AUTHINFO drafts say the following:

"The server MUST discard any knowledge obtained from the client, such as 
the current newsgroup and article number, that was not obtained from the 
TLS/SASL negotiation itself.  Likewise, the client SHOULD discard and 
MUST NOT rely on any knowledge obtained from the server, such as the 
list of NNTP service extensions, which was not obtained from the 
TLS/SASL negotiation itself."

I don't see where having to reselect the group and article would create 
a great hardship for the client.

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

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 11:42:14 -0800

> TLS/SASL negotiation itself."

If we keep MODE READER, we're unfortunately probably going to have to put
in an exception for it, just to make that clear.

> a great hardship for the client.

Likewise.  I think most clients that are going to negotiate a privacy
layer are doing it on initial connection right now.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 14:53:33 -0500

> in an exception for it, just to make that clear.

I assume you mean that we can't discard the MODE READER state change, 
correct?

> layer are doing it on initial connection right now.

Which makes me think about whether 483 makes any sense after 
authentication.  If I've already authenticated without a privacy layer, 
but a group I'm trying to access requires privacy, the only thing I can 
do is quit and reconnect, since neither re-authentication nor STARTLS 
after authentication are allowed.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 12:33:40 -0800

>> If we keep MODE READER, we're unfortunately probably going to have to
>> put in an exception for it, just to make that clear.

> I assume you mean that we can't discard the MODE READER state change,

Right.

> after authentication are allowed.

Good point.  Sounds like that should become a 502 in that situation.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 09:00:38 +0000

> after authentication are allowed.

But a different privacy extension might still be.

483 does NOT REPEAT NOT mean "you must use STARTTLS". It means "you need
privacy to do this". If it turns out that the only privacy extension you
have available won't let you do privacy in this context then, yes, you
should quit and reconnect, but that is not a reason to not use 483. Rather,
the 483 combined with no available privacy extensions (in the CAPABILITIES
output) is a signal that you need to quit and reconnect.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 01:03:40 -0800

> should quit and reconnect, but that is not a reason to not use
> 483. Rather, the 483 combined with no available privacy extensions (in
> the CAPABILITIES output) is a signal that you need to quit and
> reconnect.

The reasons for disallowing STARTTLS after AUTHINFO would apply to any
other privacy extension as well.  They're not specific to TLS.  (In
particular, new privacy layer => discard all existing state => discard
existing authentication => double authentication messes that we decided to
punt on.)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 09:40:43 +0000

> existing authentication => double authentication messes that we decided to

Not necessarily so.

If the authentication mechanism uses a public-key or zero-knowledge system,
successful authentication means that both sides can be sure that the other
person is who they say they are *even* if there's an active attacker in the
middle (that is, the AAitM can prevent authentication but can't falsely
authenticate). At which point they can use an existing shared secret as the
encryption key.

It only applies to TLS because:
- the defined layering puts the SASL encryption on the TLS-encrypted path,
  not the other way round;
- TLS uses certificates rather than shared secrets.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 11:49:51 +0000

Russ Allbery said:
>>> In the following paragraph, surely "MUST discard" should be "SHOULD NOT
>>> rely on", since the client can still make heuristic decisions.
[...]
> How about MUST NOT rely on?

I think I can live with that.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 09:47:21 -0500

> output) is a signal that you need to quit and reconnect.

Yes, your last point is a good one.  We should probably just stick with 
483 so the client knows for sure why the command failed, and then let it 
determine if it can solve the problem within the current session or 
needs to start another.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:21:12 -0800

>> existing authentication => double authentication messes that we decided
>> to punt on.)

> If the authentication mechanism uses a public-key or zero-knowledge
> system, successful authentication means that both sides can be sure that
> the other person is who they say they are *even* if there's an active
> attacker in the middle (that is, the AAitM can prevent authentication
> but can't falsely authenticate). At which point they can use an existing
> shared secret as the encryption key.

> - TLS uses certificates rather than shared secrets.

Hm.  Okay, that's a reasonably convincing argument to me.