1 / 11

RFC2222bis-13: Addressing Substantive and Editorial Issues with Authentication Outcome

This RFC2222bis-13 submission addresses substantive issues with the Authentication Outcome section and proposes improvements to the Empty Server Challenge Requirement. It also discusses security considerations, mech downgrade detection, and IANA considerations for registration of the family of mechanisms.

ttenorio
Télécharger la présentation

RFC2222bis-13: Addressing Substantive and Editorial Issues with Authentication Outcome

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC2222bis

  2. Summary • Rfc2222bis-13 to be submitted tomorrow • Addresses substantive issues • Addresses editorial/nits • Recommend WGLC upon announcement

  3. Authentication Outcome (Section 3.6) • Add: “The outcome message provided by the server can provide a way for the client to distinguish between errors which are best dealt with by re-prompting the user for her credentials, errors which are best dealt with by telling the user to try again later, and errors where the user must contact a system administrator for resolution (see The SYS and AUTH POP Response Codes [RFC3206] specification for an example). This distinction is particularly useful during scheduled server maintenance periods as it reduces support costs. It is also important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user.”

  4. Empty Server Challenge Requirement • Retroactively declares current DIGEST-MD5 mechanism invalid. • Forces server-first mechanisms with fast re-connect feature to either have extra empty round-trip or use two mechanisms. • SASL implementor who coded according to requirement can not interoperate with SMTP LOGIN installed base.

  5. With Requirement (incompatible change to DIGEST-MD5 spec) C: AUTH DIGEST-MD5 <initial-resp> S: OK <server-success-data> C: AUTH DIGEST-MD5 S: <MUST-be-empty> C: <empty-no-initial-resp> S: <server-challenge> C: <response> S: OK <server-success-data>

  6. Without Requirement (DIGEST-MD5 spec as documented) C: AUTH DIGEST-MD5 <initial-resp-reconn> S: OK <success-data> C: AUTH DIGEST-MD5 S: <server-challenge> C: <response> S: OK <success-data>

  7. Workaround C: AUTH DIGEST-MD5-RECON <initial-resp> S: OK <success-data> C: AUTH DIGEST-MD5 S: <server-challenge> C: <response> S: OK <success-data>

  8. SMTP LOGIN (non-standard, undocumented) Netscape Variant: C: AUTH LOGIN <username> S: <arbitrary-server-challenge> C: <password> S: OK Microsoft Variant: C: AUTH LOGIN S: “Username:” C: <username> S: “Password:” C: <password> S: OK

  9. mech downgrade detection • Upon detection, SHOULD close connection.

  10. Security Considerations • Separately discussion • Downgrade Attacks • Hijack Attacks • challenge/response modification -> denied access / retries (to additional ciphertext)

  11. IANA Considerations • Registration of family of mechanisms

More Related