Subject: [NNTP] Comments on draft-...-authinfo-03

From: clive at demon.net (Clive D.W. Feather)
Date: Thu Sep 16 04:37:14 2004

Mostly nitpicks:

I suggest that the text at the start of section 2 be called section 2.1.
Title perhaps "General concepts".

Page 4, "The server may list ...". Is the server required to reject any
AUTHINFO command that is then received? The purpose of this paragraph isn't
clear to me.

Page 4 last para: a 480 indicates that the client must authorise, and
AUTHINFO is a way to do this, but it doesn't mean that AUTHINFO MUST be
used.

Page 7 para 2: s/compliant/conforming/ perhaps?

Page 7 para 3: s/and client/and a client/

Section 2.2.2 first para: I'm not sure if this belongs here. Why forbid a
server from offering GENERIC as well, since there's no clash of names?
If GENERIC in [NNTP-COMMON] is deprecated, we just end up with no
definition of it at all; how does that help?

Perhaps a better approach is to replace the paragraph with:

    The use of AUTHINFO GENERIC [NNTP-COMMON] is deprecated in favour
    of AUTHINFO SASL. A server SHOULD NOT report AUTHINFO GENERIC
    in the list returned by LIST EXTENSIONS.

I still think it belongs somewhere else, such as the general part of 2 (the
bit I think should be 2.1).

Section 2.2.2 para 4: delete the stuff after ("="). Or replace the entire
sentence with:

    A server challenge that has zero length MUST be sent as a single
    equals sign ("=") and not omitted.

Page 9 last (part) para: calling the argument a "response" when it's the
very first thing in the exchange sounds odd. Perhaps rather than
"challenge" and "response" this text should just talk about "data" or
"words" or "negotiations".

Page 10 first (part) para: I don't think "defined to be the same as" is
right; perhaps:

    In NNTP, an empty server challenge and one of zero length are the
    same thing, encoded as a single equals sign.

2.2.2 para "After a security layer ...": why must the SASL mechanism list
be the same? Why can't new ones be added? Why is STARTTLS forbidden?

3.5: I would remove the comment, since it just duplicates the syntax.

5 para 2: s/posted articles, or by/posted articles or by/

8.2 [UTF-8]: s/Novermber/November/

-- 
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: ken at oceana.com (Ken Murchison)
Date: Thu Sep 16 07:44:18 2004

> Mostly nitpicks:

Thanks for the feedback.

> Title perhaps "General concepts".

Where exactly are you suggesting a split?  Are you saying that 
everything before the current 2.1 should be 2.1 and there would be no 
text directly under 2.?

> AUTHINFO command that is then received? The purpose of this paragraph isn't

I believe the purpose is to prevent clients which are capable of 
AUTHINFO USER from attempting to use it if the server explicitly states 
that its not available.

> AUTHINFO is a way to do this, but it doesn't mean that AUTHINFO MUST be

I changed this to read:

"When an NNTP server responds to a client command with a 480 response,
this indicates the client MUST authenticate and/or authorize in order
to use that command or access the indicated resource.  Use of the
AUTHINFO command as described below is one such way that a client can
authenticate/authorize to the server."

> Page 7 para 2: s/compliant/conforming/ perhaps?

Done.

> Page 7 para 3: s/and client/and a client/

Done

>     in the list returned by LIST EXTENSIONS.

This replacement text look fine to me.  I'm curious what other opinions are.

> bit I think should be 2.1).

We already state that its deprecated in Section 1, so maybe restating it 
here *is* redundant.  I'm not sure if we need to state that GENERIC 
SHOULD NOT be in LIST EXTENSIONS.

>     equals sign ("=") and not omitted.

What is the problem with the existing text?  The only reason we are 
requiring "=" at all in this case *is* to distinguish any empty 
challenge from any trailing junk.  All of the other messaging protocols 
simply allow an empty string (no "=") because they don't allow trailing 
junk.

> "words" or "negotiations".

Its called an initial response both in [SASL] and the IMAP, POP3 and 
SMTP SASL profile documents.  I'd like to stay consistent.

>     same thing, encoded as a single equals sign.

How about this:

"In NNTP, a server challenge that contains no data is
equivalent to a zero length challenge and is encoded as a single
equals sign ("=")."

> be the same? Why can't new ones be added? 

This is to help detect man in the middle attacks.  Its possible for an 
active attacker to change the list of mechanisms that the client is 
presented.  When a security layer is negotiated (assuming its not 
incredibly weak), the client can compare the lists before and after SASL 
to see if they changed.  If the server unilaterally changed the list, 
then the client may think the connection is compromised.  I've change 
the paragraph to the following:

"After a security layer is established, the server MUST continue to
advertise the AUTHINFO capability and "SASL:" argument (with the same
mechanism list as before authentication) to help detect active
attacks.  In addition the server SHOULD NOT advertise the STARTTLS
[NNTP-TLS] capability (as STARTTLS is not allowed after
authentication)."

Note that this is also addressed in Section 6.

> Why is STARTTLS forbidden?

Because of the nesting of encryption layers.  The document (as well as 
IMAP, POP3, and SMTP) all require TLS before any SASL security layer. 
That being said, if the client has already negotiated encryption via a 
SASL mech, why would it then proceed to initiate TLS?

> 3.5: I would remove the comment, since it just duplicates the syntax.

Done.

> 5 para 2: s/posted articles, or by/posted articles or by/

Done.

> 8.2 [UTF-8]: s/Novermber/November/

Done.

-- 
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: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep 17 02:42:49 2004

> everything before the current 2.1 should be 2.1 and there would be no 

That's right.

> AUTHINFO USER from attempting to use it if the server explicitly states 

In which case, shouldn't you say that the server MUST reject these
commands?

> authenticate/authorize to the server."

That's fine; that addresses my issue.

> What is the problem with the existing text?

I felt it had the wrong emphasis, though on re-reading it I'm less bothered
than I was.

Note the next paragraph: it also talks about encoding zero length strings
as = signs, but without attempting to justify why. In fact, we could send
it as a blank line in this case - I'm not suggesting this, just noting it
would be technically possible.

> The only reason we are 

I think this is it. You are looking at it from an SASL point of view: NNTP
wants to do something odd because of an NNTP feature. I'm looking at it
from an NNTP point of view: there's no such thing as an optional argument
in a response, so we need to encode zero-length strings.

[What happens in SMTP and POP3? I thought these allowed text after the
response code.]

As I said, it's a matter of emphasis. I can't find compromise wording, so
I'm not too bothered.

> SMTP SASL profile documents.  I'd like to stay consistent.

Okay.

> equivalent to a zero length challenge and is encoded as a single

Fine. [Are there protocols where the two are different? If so, how do they
handle this?]

> This is to help detect man in the middle attacks.
[...]

I'm going to take this to a separate message.

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Fri Sep 17 03:10:06 2004

> In which case, shouldn't you say that the server MUST reject these

I feel like we've had this discussion before...

If a new standard specifies that a server must reject AUTHINFO USER, 
servers are simply going to disregard that, because no one wants to 
break backwards compatibility for users who haven't updated their 
clients in a decade (and we all know there are some).  The goal of the 
requirement above is to prohibit revised clients from using AUTHINFO 
USER -without- having to break backwards compatibility for clients that 
have never heard of LIST EXTENSIONS.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep 17 03:21:16 2004

> I feel like we've had this discussion before...

Quite possibly.

> have never heard of LIST EXTENSIONS.

Okay, this rings a bell, and I can't see any way even to document it
formally.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep 17 05:41:06 2004

> [NNTP-TLS] capability (as STARTTLS is not allowed after

I remain confused.

Firstly, why won't an active attacker just present the old list anyway?
It's no skin off his nose to do it.

<later>
After much reading, I'm beginning to understand some of it (but still not
the Man in the Middle bit). But I think the draft needs to explain it all
much better.

After a successful AUTHINFO SASL, the client MUST NOT issue another
AUTHINFO command and, if it does, the server MUST respond with a 502.
Therefore the contents of the LIST EXTENSIONS response AUTHINFO line is
largely academic; its only use is as information to the client as to what
*was* available. This doesn't just apply to SASL, it applies to all
authorisation mechanisms.

Okay, here's what I suggest. Replace the last three paragraphs of section 2
("After an AUTHINFO command ... section 2.2.2.") with:

     A server MUST NOT under any circumstances reply to an AUTHINFO
     command with a 480 response.

     After an AUTHINFO command has been successfully completed, no more
     AUTHINFO commands may be issued in the same session and a server
     server MUST reject any further AUTHINFO commands with a 502 response.
     For this reason, once authentication has happened the AUTHINFO line
     in the results of LIST EXTENSIONS is effectively irrelevant. In order
     to allow the client to determine what options were available, the
     server MUST return the same arguments in this line as it would have
     done immediately before the successful authentication.

Possibly add an example, or extend the first example of 2.2.3.

The text in question in 2.2.2 ("After a security layer ...") can then be
removed as unneeded.

Question to the group: would it be worth adding a flag to show that
authentication is no longer possible? Something like:

    AUTHINFO - USER SASL:EXTERNAL

?

> Note that this is also addressed in Section 6.

Where?

> SASL mech, why would it then proceed to initiate TLS?

Okay, that makes sense, but again the document doesn't explain it well
(I'm sure I won't be the last person to get confused). I would suggest
dropping the "and SHOULD NOT ..." text and modifying the next paragraph
instead.

     When both TLS [NNTP-TLS] and SASL security layers are in effect,
     the TLS encoding MUST be applied after the SASL encoding. For this
     reason (maintaining the correct layering), when an SASL security
     layer is in effect then the client MUST reject the STARTTLS command
     (with the 502 response code) and MUST NOT advertise the STARTTLS
     capability in the results of LIST EXTENSIONS.

Um, I've just realized that the first sentence isn't that clear either; I
presume you mean that the TLS stream is encoding the results of the SASL
encoding, but it could be read as that SASL must be activated first (that's
how I read it the first time). Can I suggest:

     When both TLS [NNTP-TLS] and SASL security layers are in effect,
     the TLS encoding MUST be applied to the results of the SASL encoding
     of the plaintext messages, not the other way round.

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Sep 17 10:53:05 2004

>>everything before the current 2.1 should be 2.1 and there would be no 

OK.  After thinking about this, I'm going to split all of that text into 
something like "AUTHINFO Capability" and "AUTHINFO Behavior" sections.

> would be technically possible.

This is what I originally had (same as SMTP and POP3), but someone 
didn't like this (don't recall who), so I changed it to be the same as 
an empty initial response and empty server challenge.  If someone can 
provide me with some text that gives me a reason why we're using "=", 
I'll add it.  Or if we just want to use a blank line, I'm fine with that 
too.

> [What happens in SMTP and POP3? I thought these allowed text after the

I'd have to read the RFCs again to see if its allowed in general 
commands, but its definitely not allowed for the AUTH commands.

> Fine. [Are there protocols where the two are different? If so, how do they

Not that I know of.  I believe the SASL RFC uses the phrase "challenge 
that contains no data" and most of the profile docs (including NNTP 
AUTH) use "zero length challenge", so I'm just making sure that people 
know wthat they are equivalent.

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Sep 17 11:10:38 2004

> It's no skin off his nose to do it.

Presumably if a security layer is negotiated, the attacker can no longer 
hijack the connection, thus can't change the list.

> the Man in the Middle bit). But I think the draft needs to explain it all

Anyone implementing this extension will have to read RFC 2222bis, so I 
don't want to repeat what is already dicussed there:

    In order to detect Man-in-the-middle (MITM) attacks the client MAY
    list available SASL mechanisms both before and after the SASL
    security layer is negotiated.  This allows the client to detect
    active attacks that remove mechanisms from the server's list of
    supported mechanisms, and allows the client to ensure that it is
    using the best mechanism supported by both client and server.  New
    protocol profiles SHOULD require servers to make the list of SASL
    mechanisms available for the initial authentication available to the
    client after security layers are established.  Some older protocols
    do not require this (or don't support listing of SASL mechanisms once
    authentication is complete); for these protocols clients MUST NOT
    treat an empty list of SASL mechanisms after authentication as a MITM
    attack.

I suppose a reference to this text wouldn't hurt however.

>     AUTHINFO - USER SASL:EXTERNAL

Or we could just ignore a SHOULD in RFC 2222bis and not display the 
AUTHINFO capability at all after authentication.  But I don't think this 
is a good idea.

>>Note that this is also addressed in Section 6.

My mistake.  I got myself confused between documents.

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Fri Sep 17 14:21:16 2004

On Sep 17, 2004, at 8:40 AM, Clive D.W. Feather wrote:

>> This is to help detect man in the middle attacks.  [...]
>
> I remain confused.
>
> much better. [...]

Let me take a stab it this, for completeness.  Assuming I've understood 
it correctly.

(I think this is one of those things that doesn't need to be completely 
explained in the protocol, actually.  I mean, a programmer implementing 
a spec doesn't have to explain exactly what went in to every design 
decision, and at some point the sheer quantity of explanatory material 
makes the overall task -more- complicated.)

You should keep in mind a couple underlying assumptions that are true 
in other SASL-using protocols perhaps more than NNTP.  One is that the 
client may have some way to verify the server's identity after the 
connection is established.  Another is that the data passing over the 
connection is more valuable than the user's password itself.

In the kind of attack being considered, an attacker has the ability to 
snoop on the (initially unencrypted) connection, and to forge packets 
appearing to come from the server.  At some point the client sends LIST 
EXTENSIONS, and the attacker forges a response in which the list of 
available SASL mechanisms has been altered.  In particular, the 
strongest mechanisms have been removed from the list.  So the client 
sees the altered list, and selects one of the (weak) available 
mechanisms, even if the client would have preferred something else that 
might have been in the unaltered list.  When the server's LIST 
EXTENSIONS response arrives, the client TCP stack discards it as a 
duplicate.  The client and server proceed with the SASL negotiation 
(the server having no idea the client hasn't chosen its ideal 
mechanism), and establish a SASL layer.  Keep in mind that it's the 
true server (and the client has perhaps verified this  during the 
exchange in a way the attacker couldn't forge); the attacker is not 
forging any packets during the negotiation.  So the attacker has 
"successfully" caused the established layer to be weaker than 
otherwise, and now a second attack has to be used -- but perhaps an 
attack is known against the weaker mechanism now in use.

>     AUTHINFO - USER SASL:EXTERNAL

This seems decent at first glance, actually.  (Although I don't know 
how I feel about the "-" as a special parameter.)

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Sep 22 07:09:10 2004

Ken Murchison said:
> didn't like this (don't recall who),

Quite possibly me.

> so I changed it to be the same as 

I think the present protocol is fine; it's only the way it's described that
I'm commenting on.

How about this?

    A server challenge is sent as a 383 reply with a single argument
    containing the [BASE64] encoded string supplied by the SASL
    mechanism.  A server challenge that has zero length MUST be sent
    as a single equals sign ("=") and not omitted (in order to comply
    with the [NNTP] requirement that responses always have the same
    number of arguments).

    A client response consists of a line containing a [BASE64] encoded
    string.  A client response that has zero length MUST be sent as a
    single equals sign ("=") and not omitted (for consistency with
    the server challenge format).  If the client wishes to cancel
    the authentication exchange, it issues a line with a single "*".
    If the server receives such a response, it MUST reject the AUTHINFO
    SASL command by sending a 481 reply.

In each case you might prefer to insert "this is" at the start of the
parenthetical comment.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Sep 22 07:28:26 2004

> Let me take a stab it this, for completeness.  Assuming I've understood 

Thanks very much.

> makes the overall task -more- complicated.)

I appreciate your point there.

The problem in this case is that the requirement is apparently nonsense and
self-contradictory: after establishing a security layer:
* you MUST advertise AUTHINFO even though you can't use it;
* you MUST NOT advertise STARTTLS *because* you can't use it.
Plus the mention of an "active down-negotiation attack" without explaining
how this prevents/detects it.

Anyway:

> connection is established.

External to the link or internal?

> Another is that the data passing over the 

Hmm. Surely if you've got the password then you have access to the data at
your leisure?

But continuing ...

> appearing to come from the server.

Ah. This is *not* what "man in the middle" means to me. My model has been:
* the client is talking to the attacker thinking it's the server (either
  through DNS manipulation or IP re-routeing);
* the attacker is talking to the server on a separate TCP connection,
  pretending to be the client.
Messages are passed through unless the attacker has a need to modify them.
Packet boundaries are *not* preserved and separate encryption is carried
out on each leg.

What you have is a snooper who can inject packets but not delete them.

> At some point the client sends LIST 
> might have been in the unaltered list.

Okay. I'm not sure how much of a threat that is, but ...

> When the server's LIST 
> duplicate.

Only if it's exactly the same length. If it isn't, the two ends will now
be out of sync.

    Attacker sends  "AUTHINFO SASL:WEAK" as the last item in the response.
    Server sends "AUTHINFO SASL:WEAK,MEDIUM,STRONG" as the last item.

Suppose the client discards that message and sends a command, say "AUTHINFO
SASL WEAK". The server sends a 283 response. The client's stack will see a
11 octet gap in sequence numbering and send a retransmission request. The
server will now send "UM,STRONG[CR][LF].[CR][LF]283 whatever[CR][LF]"
and the client will barf.

> The client and server proceed with the SASL negotiation 
> mechanism),
[...]
> but perhaps an 

I follow this, though if SASL:WEAK isn't strong enough the client shouldn't
be using it.

> how I feel about the "-" as a special parameter.)

Better something like that than "DONTUSE". I would have suggested
"-AUTHINFO USER SASL:EXTERNAL" except that the first word has to be all
uppercase.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Sep 22 07:41:52 2004

[...]

Following Jeffrey's explanation I now understand the attack that you're
defending against, though I wouldn't call it "Man-in-the-Middle".

>    In order to detect Man-in-the-middle (MITM) attacks

You may want to bring the terminology discussion to whoever is working on
2222bis.

>    New
>    client after security layers are established.

Fine.

> I suppose a reference to this text wouldn't hurt however.

I'd be happy with:

    In agreement with [SASL], after a security layer is established
    the server MUST continue to advertise the AUTHINFO capability with
    the same arguments as before authentication.

> AUTHINFO capability at all after authentication.  But I don't think this 

I'm happy to show the information, though I think it's better being flagged
(so that a naive client [author] doesn't think that AUTHINFO is valid at
this point).

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Wed Sep 22 15:58:35 2004

On Sep 22, 2004, at 10:28 AM, Clive D.W. Feather wrote:

>> explained in the protocol, actually.  [...]
>

Point.

> External to the link or internal?

I was purposefully vague because I didn't want to look up specifics, 
but in principle the SASL negotiation can be bidirectional, similar to 
the way a web browser would verify a TLS server certificate.

> Hmm. Surely if you've got the password then you have access to the 

Not if it's a one-time pad or a challenge-response mechanism :-)

> Ah. This is *not* what "man in the middle" means to me. [...]

Yeah, I'm not sure if there's a different attack that I haven't thought 
of, or if it's just a terminology problem.

>> [...] So the client [...] selects one of the (weak) available

Seems contrived to me too :-)

>     Server sends "AUTHINFO SASL:WEAK,MEDIUM,STRONG" as the last item.

*shrug*  So the attacker sends "AUTHINFO SASL:WEAK FOOBAR GZNORT" 
instead, and the client (appropriately, kinda) ignores FOOBAR and 
GZNORT think that they're new authentication types it doesn't 
recognize.

> I follow this, though if SASL:WEAK isn't strong enough the client 

Fair enough, but with the eternal luggage of backwards compatibility, I 
wouldn't be surprised if a client will at least have to option to fall 
back to anything that might work rather than give up the connection.

> "-AUTHINFO USER SASL:EXTERNAL" except that the first word has to be all

*nod*

It's a bit more of a change late in the game, but what do you think 
about putting the - before each of the forbidden auth types?  Say, 
"AUTHINFO -USER -SASL:EXTERNAL".

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: rra at stanford.edu (Russ Allbery)
Date: Sun Sep 26 16:04:31 2004

>     the same arguments as before authentication.

This sounds like the best fix to me as well.

>> AUTHINFO capability at all after authentication.  But I don't think
>> this is a good idea.

> I'm happy to show the information, though I think it's better being
> flagged (so that a naive client [author] doesn't think that AUTHINFO is
> valid at this point).

I'd rather not add more complexity to the syntax right now.  I know it's a
little bit confusing, but I think it's best to leave it as currently
presented rather than adding a separate flag with a syntax that isn't
really related to the rest of the protocol.

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

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Sep 27 06:37:20 2004

> really related to the rest of the protocol.

We could go back to what Chris Newman had originally had which is a 
separate capability for SASL, eg,

before authentication:

AUTHINFO USER SASL
SASL PLAIN CRAM-MD5

after authentication:

SASL PLAIN CRAM-MD5

---

From: rra at stanford.edu (Russ Allbery)
Date: Mon Sep 27 12:52:40 2004

> SASL PLAIN CRAM-MD5

I'm ambivalent about this.  I don't mind this, but I also don't mind what
we already have.  I'm willing to endorse the change, but only if what we
have now really bothers people and the general consensus is that this
would be a substantial improvement; if not, I'd rather err on the side of
going with what we have so that we can get a document released.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Sep 28 05:49:30 2004

Russ Allbery said:
> would be a substantial improvement;

I don't think it would be an improvement at all.

We have an odd situation here: we want to show that a capability *isn't*
there but used to be; that is, any attempt to use it will fail. I suggested
the "-" as a way of showing this. I don't think the above suggestion gets
the message across at all.

> if not, I'd rather err on the side of

Okay (but see other emails I'm about to write).

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Sep 28 05:49:30 2004

> I'd rather not add more complexity to the syntax right now.

It's not a syntax issue (apart from a trivial adjustment to the formal
syntax), since the arguments to a LIST EXTENSIONS capability can have any
form other than white space.

> I know it's a

Shrug. It's your call; I'm not going to die in the ditch on this one.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Sep 28 06:05:55 2004

Okay.

Point.

> instead,

Only if it knows the exact length of the string. Okay, it can make a
separate connection to the server to see, but it's starting to get a bit
threadbare as a threat.

> "AUTHINFO -USER -SASL:EXTERNAL".

Hmm. That would also allow a server to say "I grok this method but aren't
permitting it" at an earlier stage:

    AUTHINFO -USER SASL:EXTERNAL

If Russ will go for it, I'd be happy.

---

From: chl at clerew.man.ac.uk (Charles Lindsey)
Date: Wed Sep 29 09:12:41 2004

>separate connection to the server to see, but it's starting to get a bit

But surely the attacker will wait till he has seen the server's attempt. I
am assuming that this "man in the middle" is receiving packets from the
server and normally passing them on to the client unchanged. When he sees
"AUTHINFO SASL:WEAK,MEDIUM,STRONG", he drops it on the floor and inserts
"AUTHINFO SASL:WEAK FOOBAR GZNORT" in its place.

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