Re: protocol progress...

Thanks, Alexey.

One additional comment, inline.

Best Regards,

Dale Gustafson



Alexey Melnikov wrote:

> Dale Gustafson wrote:
>
> > ...

[ ... ]

>
> > Also, based on a cursory read, it appears that RFC-3163 is N/A since it
> > provides authentication only.  If anyone knows of others that should be considered,
> > please send info.

In a separate post, Magnus clarified that he is suggesting use of the DIGEST-MD5 protocol
"inside" the sTLS session.  That is, first a plain/vanilla TLS session (cert-based, server
side auth. only) is established and shifts into encrypted mode.  Then the client and server
applications perform the digest-md5 protocol exchanges necessary to achieve mutual
authentication whereby the client and server both prove that they know the same
pre-established password, etc.

I'm a little surprised there hasn't been more comment on this.  Also, I do think we'd have
to carefully analyze the security implications of this more complex combination.

In any event, if that's the technique we use, then the auth. protocol need only provide a
mutual authentication capability and my comment on RFC3163 is no longer meaningful -- this
suggests we could consider additional mutual-auth. protocols including those that are not
able to provide a privacy service.

Comments?



> >
> > Excerpt from IANA sasl-mechanism list follows:
>
> FYI, some other mechanisms also listed on the web page:
>
>  http://www.sendmail.org/~ca/email/mel/Links.html
>
> [Some links are broken as drafts expired.]
>
> > SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS
> > ----------------------------------------------------------
> >
> > (last updated 2001 August 17)
> >
> > [ ... ]
> >
> > MECHANISMS              OWNER                                  REFERENCE
> > ----------              -----                                  ---------
> >
> > KERBEROS_V4             IESG <[email protected]>                   [RFC2222]
> >
> > GSSAPI                  IESG <[email protected]>                   [RFC2222]
> >
> > SKEY (OBSOLETE)         IESG <[email protected]>                   [RFC2444]
> >
> > EXTERNAL                IESG <[email protected]>                   [RFC2222]
> >
> > CRAM-MD5                IESG <[email protected]>                   [RFC2195]
> >
> > ANONYMOUS               IESG <[email protected]>                   [RFC2245]
> >
> > OTP                     IESG <[email protected]>                   [RFC2444]
> >
> > GSS-SPNEGO              Paul Leach <[email protected]>        [Leach]
> >
> > PLAIN                   IESG <[email protected]>                   [RFC2595]
> >
> > SECURID                 Magnus Nystrom <[email protected]>[RFC2808]
> >
> > NTLM                    Paul Leach <[email protected]>        [Leach]
> >
> > NMAS_LOGIN              Mark G. Gayman <[email protected]>     [Gayman]
> >
> > NMAS_AUTHEN             Mark G. Gayman <[email protected]>     [Gayman]
> >
> > DIGEST-MD5              IESG <[email protected]>                   [RFC2831]
> >
> > 9798-U-RSA-SHA1-ENC     [email protected]          [RFC3163]
> >
> > 9798-M-RSA-SHA1-ENC     [email protected]          [RFC3163]
> >
> > 9798-U-DSA-SHA1         [email protected]          [RFC3163]
> >
> > 9798-M-DSA-SHA1         [email protected]          [RFC3163]
> >
> > 9798-U-ECDSA-SHA1       [email protected]          [RFC3163]
> >
> > 9798-M-ECDSA-SHA1       [email protected]          [RFC3163]
>
> Alexey Melnikov
> __________________________________________
> R & D, ACI Worldwide/MessagingDirect
> Richmond, Surrey, UK
> Phone: +44 20 8332 4508
>
> I speak for myself only, not for my employer.
> __________________________________________