Hathai Tanta-ngai, Tony Abou-Assaleh, Sittichai Jiampojamarn, and Dr. Nick Cercone

1. Secure Mail Transfer Protocol (SecMTP) Hathai Tanta-ngai, Tony Abou-Assaleh, Sittichai Jiampojamarn, and Dr. Nick Cercone Faculty of Computer Science Dalhousie University

2. Overview • Introduction • Current email security • Secure Mail Transfer Protocol • Discussion • Conclusion • Future work

3. Introduction • Email is everyday used in electronic world • Simple Mail Transfer Protocol (SMTP) is trivial and anonymous • Security is need for transferring email over internet

4. SMTP

5. Current email security • Confidentiality and Integrity • Authentication • Non-repudiation • User Applications • Web Applications

6. Secure Mail Transfer Protocol (SecMTP) • Overview • Assumption and Limitation • Architecture • Specification • Example

7. SecMTP: Overview • Incorporate security procedure into SMTP • Maintain the simplicity and compatibility that SMTP provides • Achieve the five security goals: confidentiality, integrity, authentication, non-repudiation, and certification

8. Assumption and Limitation • All SecMTP compliant servers must be properly certified • Non-repudiation has to be implemented • SecMTP user trusts the integrity of the end servers but not the intermediate connection • We designed SecMTP’s architecture, protocol specifications, and SecMTP Extension Service to SMTP

9. The SecMTP Architecture SecMTP architecture with the extension of security services

10. The SecMTP Specification • Default specification • User requested options

11. The SecMTP Default Specification • TLS channels • Authentication headers • Digital signature • TTP (if receiver non-repudiation is required)

12. The SecMTP User Requested Options • Receiver public key encryption • Sender private key digital signature • Restrict option • Seamless interfaces • Users private/public keys are stored at the server machine

13. The Timing Diagram of SecMTP (1)

14. The Timing Diagram of SecMTP (2)

15. The State Diagram of Starting a SecMTP Connection

16. SMTP Extension Service for Secure Mail Transfer Protocol (SecMTP) • The name of the SMTP service extension is “Secure Mail Transfer Protocol” • The EHLO keyword value associated with the extension is SECMTP • No parameters are allowed with this EHLO keyword value

17. SMTP Extension Service for Secure Mail Transfer Protocol (SecMTP) • Three option parameters are added to the RCPT command: • SIGN: digitally sign message header consisting of a message digest and sender identity • ENCR: encrypt the message with receiver public key • STRICT: only transfer the message through properly authenticated and certified SecMTP servers • No additional SMTP verbs are defined by this extension

18. Example S: <waits for connection on TCP port 25> C: <opens connection> S: 220 foo.com SMTP service ready C: EHLO bar.com . . . C: STARTTLS C \& S: <negotiate a TLS session> C \& S: <check result of negotiation> C: EHLO S: 250 ... AUTH CRAM-MD5 DIGEST-MD5 ... C: AUTH CRAM-MD5 S: 334 ...

19. Example (cont.) C & S: <authentication session> S: 235 authentication successful C: EHLO S: 250 ... SECMTP ... C: SECMTP S: 220 welcome SecMTP service ready C: MAIL FROM:<Smith@bar.com> S: 250 OK C: RCPT TO:<Jones@foo.com> S: 250 OK C: RCPT SIGN S: 250 OK Digital Signature for Jones@foo.com

20. Example (cont.) C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Data data data... C: ...etc. etc. etc. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel

21. Discussion (1) • Advantages • Seamlessly integrate with existing email systems • Compatible with SMTP and current service extension • Does not require specific action from the users • Provide user-to-user level of security • Provide both best-effort and guaranteed security services

22. Discussion (2) • Shortcomings • Non-SecMTP clients need to examine the security information manually • Encryption and decryption are done at the server • Users must trust the end servers to provide security services • The SecMTP servers may become bottleneck • SecMTP compliant clients and servers are required to achieve full benefit of SecMTP

23. Conclusion • Secure communication -> TLS channels • Authentication and certification at servers -> AUTH and header • Confidentiality users -> Public key encryption • Authentication and integrity at users -> Digital signatures • Sender non-repudiation -> Digital signatures • Both sender and receiver Non-repudiation -> TTP • Guarantee security service -> STRICT option

24. Thank you !!!hathai@cs.dal.ca or hathai@acm.org