Subject: TLS and TN

From: [email-masked]
Date: Thu, 4 Dec 97 14:50:56 -0800

Could the same effect be achieved by using inline negotiation for two
   different ports.  The secure port requires the negotiation of security (SSL,
   SASL, or whatever is acceptable) and close the connection if the is
   insufficient authentication and/or security.  That way we have the
   flexibility of inline negotiation and the server configuration can be simple
   and leave topology decisions up to the firewall if it desires (which could be
   risky) without having two different specs.

Protocols like POP and IMAP are interested in authenticating the user for
authorization to access mail on servers.  As John pointed out in the previous
message any method is open to a man in the middle attack if it does not require
mutual authentication of the client and server,  both the client and server have
to be configured to require authentication to avoid this attack.

>
>     The SMTP, IMAP, POP, LDAP drafts all discourage the use of a separate
>     ports.

>>   ** the EMAIL wire protocols are not interested in protecting the data or
>>   authentication of the end-user sender/receiver (this is done by signing and
>>   or encrypting the message outside of these protocols using something like
>>   SMIME or PGP) but only in discouraging SPAMers from injecting junk in the
>>   network. One of the latest drafts I read clearly points out the man in the
>>   middle attack problem with this approach.

>>   The only real secure LDAP available today in fact uses a separate port
>>   ("The default secure (LDAP over SSL) LDAP port of 636 can be selected by
>>   supplying the constant LDAPS_PORT" in the oct 96 LDAP RFC draft
>>   at http://www.alternic.net/info/drafts/draft-howes-ldap-api-00.txt.html
>>   and
>>   also see
>>   http://home.netscape.com/eng/server/directory/3.0/ag/dsmanage.htm#1009690)

Joe

---

From: [email-masked]
Date: Thu, 4 Dec 97 14:50:56 -0800

Joe

---

From: Michael Boe <[email-masked]>
Date: Thu, 4 Dec 1997 16:00:09 -0800 (PST)

>    different ports.  The secure port requires the negotiation of security
>    (SSL, SASL, or whatever is acceptable) and close the connection if the
>    is insufficient authentication and/or security.  That way we have the
>    flexibility of inline negotiation and the server configuration can be
>    simple and leave topology decisions up to the firewall if it desires
>    (which could be risky) without having two different specs.
>
>
> authorization to access mail on servers.  As John pointed out in the
> previous message any method is open to a man in the middle attack if it
> does not require mutual authentication of the client and server,  both the
> client and server have to be configured to require authentication to avoid
> this attack.

Perhaps we're not quite speaking the same terminology here.  There's a
difference between authenticating a user's identity (or an end-station, or a
router or whatever) and being able to trust there's no man in the middle once
the "secure" part of the session has gotten underway. You can most certainly
not care who the client is, yet be confident that there's no man in the middle
attack in progress. Wagner & Schneier have a paper analyzing the SSL 3.0
protocol, and their opinion is that SSL 3.0 the key-exchange algorithms aren't
subject to the man-in-the-middle attack.  Their two main concerns have to do
with "change cipher spec" drop and key-exchange rollback attacks.

That's not to say that the server ALWAYS doesn't care who the client is at
connect time.  It might, or it might not. But that's site-specific policy and
no business of ours to dictate that policy.

The client may well care who the server is.  But certainly with RSA and DSS
key-exchange protocols, this is possible to do because the server always
provides authentication credentials that can be verified.

A final point:  rollback attacks can be easily mounted against the
authentication schemes in IMAP and ACAP. In fact, it's extremely difficult to
protect against rollback attacks completely; they can almost always at least
cause denial-of-service.  This includes SSL 3.0 and TLS.

> >>   ** the EMAIL wire protocols are not interested in protecting the data
> >>   or authentication of the end-user sender/receiver (this is done by
> >>   signing and or encrypting the message outside of these protocols using
> >>   something like SMIME or PGP) but only in discouraging SPAMers from
> >>   injecting junk in the network. One of the latest drafts I read clearly
> >>   points out the man in the middle attack problem with this approach.

Yes, it's true that a great desire of the email community is to allow some
policy on who's connecting into a site. Or the policy might even be to just
monitor who's connecting in (by requiring a certificate).  But that's not to
say that's their only desire. You should really make your assertion to the
email community and see how they react. Let us know the results!

/msb
> >>   ("The default secure (LDAP over SSL) LDAP port of 636 can be selected
> >>   by supplying the constant LDAPS_PORT" in the oct 96 LDAP RFC draft
> >>   at
> >>   http://www.alternic.net/info/drafts/draft-howes-ldap-api-00.txt.html and
> >>   also see
> >>
> >>

---

From: [email-masked]
Date: Fri, 5 Dec 97 09:47:36 -0800

My terminology is a bit sloppy.

     Let me see if I can catch up to the same page.

     In a Man-in-The-Middle attack an attacker compromises the security of
     the session by inserting himself in the middle of the conversation.
     He can then read any message from both sides or even modify many
     messages from either side.

     Another attack involves the attacker spoofing the host, appearing as a
     communication endpoint instead of in the middle of the conversation.
     I'm not sure what is the proper terminology for this attack but I'll
     call it spoofing for right now (not such a good term since the above
     Man-in-the-middle-attack probably uses spoofing techniques).

     The two attacks have different results.  In the Man-in-the-middle
     Attack the attacker has full control and access to both host and
     client data directly.  The spoofing attack is somewhat less severe.
     The attacker can fool the user into giving up valuable information
     (for example putting up a login screen and stealing the password), but
     this requires some knowledge of what the server actually does.  The
     attacker does not have direct access to the server, although he may be
     able to use the info he steals at a later time to gain access.

     Going back to inline negotiation of TLS:

     >
     >     Client configuration is easier.  The client does not have to
     >     reconfigure for secure and non secure connections.
     >
     >>     ** FALSE, THE CLIENT MUST FORCE SECURITY AND NOT NEGOTIATE
     >>     TO NON-SECURE as doing this allows a man in the middle
     >>     attack - the clients session configuration must at least
     >>     have a secure/not-secure flag that can not be negotiated
     >>     on session setup.

In this case if the Server Requires security the MITM attack is no longer a
problem.  The spoofing attack is still a problem.  However it may be the
case that the information that the attacker could get is not useful. i.e if
the proper gateway has another mechanism for logging into the mainframe the
user may not posses a password.  In this case a client may not have to
reconfigure.  Also it is conceivable that a site may have an internal
security mechanism that is different from what is available externally.  In
this case the client is configured to negotiate either one of two methods,
but not none.  If a spoof attack takes pace both security mechanisms fail
and the client drops the connection.  In this case the client does not have
to reconfigure if the same port is used (i.e. the server is aware of the
topology.

______________________________ Reply Separator
_________________________________
Subject: Re: TLS and TN
Author:  mboe ([email-masked]) at internet
Date:    12/4/97 4:00 PM

/msb

---

From: [email-masked]
Date: Fri, 5 Dec 97 09:47:36 -0800

/msb