SMTP AUTH design-team meeting notes

[John Gardiner Myers <jgmyers@xxxxxxxxxxxx>]

Notes from the SMTP AUTH design-team meeting at the 42nd IETF In
Chicago.

. Both client and server must clear extension state and reissue EHLO
  after negotiating a security layer, to protect against
  man-in-the-middle attacks occuring before the authentication.

. The behavior for 0-length initial responses is slightly different with
SMTP
  AUTH due to the fact that some server implementations strip trailing
white
  space in their lexical analyzer. Instead of leaving it blank, you need
to
  specify an equals sign (=), e.g.
        AUTH EXTERNAL =

. Reactive authentication. There is a desire to be able to start a
  mail transaction and only obtain authentication if the server
  notifies the client that authentication is required.

  After some discussion, there was consensus that by allowing change
  of authentication state within a transaction complicates the
  security model.  For example, one may have to revoke delivery to
  previous RCPT TO: when the authentication state changes because the
  authenticated user may be explicitly denied the ability to send to
  given RCPT TO.  For another example, the application of moderator
  redirection for lists may depend on authentication state, so a change
  of authentication state could change the interpretation of a previous
  address.

  There was also some concerns with implementing this in current
  systems.

  As such, AUTH will only be allowed outside of a mail transaction. If
  AUTH is used within a mail transaction then an error will be
  returned by the server.

  A server could choose to implement reactive authentication in the case
  where the authentication does not enable a security layer, announcing
  this support using an additional ESMTP extension.  None of the server
  implementors present were interested in supporting such an extension,
  so there is no effort to define such an extension.

. Use of MAIL FROM: addr AUTH=. AUTH= is used by a relay to pass
  the authentication of a particular mail transaction from the
  client relay to the next trusted hop.

  Ideally, everyone would present AUTH= if the message is considered
  authentic and leave it blank if authentication is not asserted for
  the message.  However, the problem arises that a client may not know
  its own authentication and so the server needs to fill it in.

  The client can not just leave the field blank and assume the server
  will fill it in.  A relay may omit the AUTH= parameter when relaying
unauthentic
  mail even if it has established an authenticated connection.

  One proposal that was rejected was to have submit (but not relay) 
  servers fill in the submit client's authentication.  Doing so would
  be vulnerable to a man in the middle attack where the attacker could
  redirect a connection from the SMTP relay port to the submit port,
  causing the transaction to be incorrectly authenticated as the relay
client.

  Thus, a client is required to send MAIL FROM: addr AUTH=SOMETHING
  when it wants the server to assert that the value of the
  authentication for the current message (AUTH=) is to be set to the
  authentication identity of the connection.

  SOMETHING is currently undefined. Possible suggestions are currently
  "*@*" or "<>". John will check into this and propose a solution.

  Under both cases, if AUTH= is omitted from the MAIL FROM: line, then
  that message is considered unauthentic even if the session was
  authenticated.

. Reply codes: There was some discussion of the reply codes in SMTP
  AUTH, specifically the value of the middle field. It was decided
  that the current 505 field (which was used by SMTP TLS draft) should
  be changed to 530 to be more consistent with other documents where
  the middle digit of '3' represents an authentication related return
  code.

. XSENDER - Netscape has an extension to retrieve the value of AUTH=
  from the IMAP server, advertised by the XSENDER capability. This is
  by having an additional FETCH item.

  After some discussion, it appeared that most people were not
  interested in adopting this extension.  Some prefered to store this
  information as part of message annotations, but there was not
concensus
  on this point.  There was also a desire to have a way to be able to
  retrieve additonal SMTP envelope information.