headers
Daryl Odnert | 8 Mar 2002 01:35

TLS Indicators in Internet Message Headers


Greetings,

A quote from RFC 3207, section 4.1.

 "A publicly-referenced SMTP server would probably
  want to accept any verifiable certificate from an
  SMTP client, and would possibly want to put
  distinguishing information about the certificate
  in the Received header of messages that were
  relayed or submitted from the client."

I was curious whether anyone on this list is familiar
with what existing implementations are doing
with respect to adding security indicators in
any of the messages headers when TLS is used?
I'd be interested in seeing example message
headers from real implementations, or documents
that describe the syntax being used.  

Has any standard has been proposed?

Thanks,
Daryl Odnert
Tumbleweed Communications
email: daryl.odnert <at> tumbleweed.com
Permalink | Reply | 0 comments |
headers
Paul V Ford-Hutchinson | 7 Aug 2001 12:43
Picon
Favicon

FTP over SSL


The ftp/ssl draft has been around now since 1997 and I feel it is time to 
ask for it to be put onto Standards Track.

(see http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-07.txt)

Do people on these lists have strong views on this ?  I am struggling to 
find a path through the IETF processes for putting individual submissions 
onto Standards Track, so I'd love to know what others did.

For a page of links to implementations, see 
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html .

Cheers,
Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh <at> uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 25 Jul 2001 21:27
Picon

Changes after IETF last call for 2487bis


There were two significant commments that came out of the IETF last call.

The first was a disagreement from Keith Moore (with agreement from 
Ned Freed) about the addition of the text that described 
interoperating with earlier versions of SSL. In retrospect, I agree 
that the text that was added didn't help an implementor create an 
interoperable system and in some ways made it harder. Thus, I have 
removed that paragraph from the document. Of course, this does not 
prevent client and server implementations from recognizing multiple 
versions of SSL/TLS during the SSL negotiation.

The second was about security considerations wording in 2487 about 
preventing man-in-the-middle attacks. Ned suggested alternate wording 
that is much more amenable to servers turning TLS on and off. The new 
wording is:

   A man-in-the-middle attack can be launched by deleting the "250
   STARTTLS" response from the server. This would cause the client not
   to try to start a TLS session. Another man-in-the-middle attack is
   to allow the server to announce its STARTTLS capability, but to
   alter the client's request to start TLS and the server's response.
   In order to defend against such attacks both clients and servers MUST
   be able to be configured to require successful TLS negotiation of
   an appropriate cipher suite for selected hosts before messages can
   be successfully transferred. The additional option of using TLS when
   possible SHOULD also be provided. An implementation MAY
   provide the ability to record that TLS was used in communicating
   with a given peer and generating a warning if it is not used in a
   later session.
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. Chong | 19 Mar 2001 11:07
Picon
Favicon

Client Authentication


I think I have sent this question... I am sorry if I have bothered you
with this email. I know that client authentication might be initialized by
the server... but I wish to know more about this... Thanks.

Dear all,

	I am total newbie of TLS or SSL. I have a question about what I
will do for my work. I wish to apply the SSL or TLS client authentication
but I don't want to continue the SSL or TLS to set up the secure session
between the server and client. I wish to manually control (from the client
side) using the Web browser (for example Internet Explorer) the client
authentication to the server, for example, which certificate to be sent
and so on... I wish to know whether it is possible to do that... and
wishing to have your expertise and directions. Your reply is highly
appreciated. Thank you very much. Wish you all the best.

Best regards,
Jordan CN CHONG 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 14 Mar 2001 03:41
Picon

Are we ready for last call?

I have made all the agree-to changes to 
draft-hoffman-rfc2487bis-05.txt (the draft is at 
<http://www.imc.org/draft-hoffman-rfc2487bis>). It seems like the 
only open issue is how to deal with multiple host names on a single 
server, and the generally-agreed answer is "we don't; that's a TLS 
issue".

Could people look over the draft soon and make comments? I would like 
to send it to the IESG after the Minneapolis fun-fest next week.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 0 comments |
headers
Gregory Neil Shapiro | 6 Oct 2000 02:55

rfc2487bis-04: Failed negotiations & virtual hosting

I had a couple of comments on the new draft:

1. You might want to mention what happens if the TLS negotiation fails in a
   non-recoverable way.  In these cases, the connection is simply dropped.
   (Since the encryption is out of skew, there is no way for a client to
   send a QUIT command or a server to send an error back to the client).

2. As Paul Hoffman and I discussed at IETF, there may be a virtual hosting
   problem that will necessitate a change.  For example, smtp.gshapiro.net
   does virtual hosting for about 50 domains.  If a client expects the
   certificate CN and the hostname to match, there needs to be some way to
   communicate that information.  HTTP has HTTP/1.1 or the Server: line to
   indicate the requested server.  SMTP will need the same if the server is
   to be able to determine which certificate to send.
Permalink | Reply | 11 comments |
headers
Frederik Vermeulen | 24 Aug 2000 16:02
Favicon

SMTP/TLS: MTA certificate type

Hello,

since a typical MTA has both server and client capability, it
seems logical to me to have a single certificate with
X509v3_extensions mentioning both SSL server and SSL client
usage.

Apparently commercial CA's only deliver either server certificates or
client certificates however.

What are advantages/disadvantages of both schemes? Could the RFC
mention the combined usage possibility to convince CA's of the
need for server+client certificates?

Regards,

Frederik Vermeulen
Permalink | Reply | 1 comment |
headers
Paul Hoffman / IMC | 17 Aug 2000 00:34
Picon

draft-hoffman-rfc2487bis-03.txt

Greetings after a long time. I updated that rfc2487bis draft a month 
ago but forgot to tell this list. Could all the folks who have 
implemented STARTTLS for SMTP please review the draft and comment on 
any changes needed? There is a list of the changes at the beginning 
of section 1.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 21 comments |
headers
Peter 'Luna' Runestig | 27 Jul 2000 13:31

ANNOUNCE: SSL/TLS ftp

This is to announce a unix implementation of ftp with SSL/TLS according
to the "draft-murray-auth-ftp-ssl-05.txt" IETF draft, which describes
the AUTH TLS, PBSZ 0 and PROT P ftp commands. It uses the OpenSSL
toolkit <http://www.openssl.org/>. There is actually two server imp-
lementations and one client:

The first server is based on the ProFTPD ftp server
<http://www.proftpd.net/>. It also has support for SSL/TLS-based user
authentication. Tested on Linux and OpenBSD, test reports on other
systems welcome! Available at:
ftp://ftp.runestig.com/pub/proftpd-tls/

Since everyone didn't feel comfortable running proftpd on their servers,
there's an alternative. I have made a port of the OpenBSD 2.7 ftpd
server and added the TLS code. For Linux, I have added shadow password
file support, but note that there's no PAM support (yet anyway). Tested
on Linux and OpenBSD, test reports on other systems welcome! Available
at:
ftp://ftp.runestig.com/pub/ftpd-tls/

X509 client authentication
--------------------------
Support for user authentication is possible through the custom function
int x509_to_user(X509 *peer_cert, char *userid, int len) in the file
x509_to_user.c, and by a .tlslogin file in the user's home directory.

o tls_userid_from_client_cert() is called and returns a user id or
  NULL. tls_userid_from_client_cert() calls the site specific function
  x509_to_user().
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thierry Van Doninck | 26 Jun 2000 09:05
Picon

request for information.

Hi,

I'm aware that these mailing-lists are for discussing standarts more than products, so I would 
invite people te respond to me personnally.

I'm looking for information on products that implement the SSL V3 and/or TLS protocols but not
for HTTP. Namely for securing FTP, SMTP, POP3 and IMAP4 protocols. (Both for servers and clients).

If anyone knows of a list, or specific product, please reply to 

thierry.vandoninck <at> dexia.be

Thanks for any help/info received,

Thierry.
Permalink | Reply | 0 comments |
headers
RFC Editor | 8 Jun 2000 20:04
Picon
Favicon

RFC 2830 on LDAPv3: Extension for Transport Layer Security


A new Request for Comments is now available in online RFC libraries.

        RFC 2830

        Title:	    Lightweight Directory Access Protocol (v3):
                    Extension for Transport Layer Security 
        Author(s):  J. Hodges, R. Morgan, M. Wahl
        Status:     Standards Track
	Date:       May 2000
        Mailbox:    JHodges <at> oblix.com, rlmorgan <at> washington.edu,
                    Mark.Wahl <at> innosoft.com 
        Pages:      12
        Characters: 24469
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-ldapext-ldapv3-tls-06.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2830.txt

This document defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an
LDAP extended request.

This document is a product of the LDAP Extension Working Group of the
IETF.

This is now a Proposed Standard Protocol.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane