Re: protocol progress...

Hi Magnus,

Comments inline.

Best Regards,

--dg


Magnus Nystrom wrote:

> I would like to explain my second statement below a little bit, because I
> feel it was not properly formulated. Clearly we need to protect against
> off-line dictionary attacks, or SACRED would be next to useless. This can
> be done, however, in several ways. Either by strong password protocols
> such as SRP, or, to a certain extent at least, by layering a weaker
> password protocol on top of a secure transport such as TLS. And yes,
> clearly the password mechanism that we mandate must be as strong as
> possible. But "possible" includes many aspects, and unfortunately not only
> technical ones.

If you mean sending user-id/password within an established TLS session, that is likely
more secure than using SASL protocols to create the secure session layer.  Some might
argue that the server authentication technique provided by TLS is not adequate for the
SACRED application.

It's been suggested that one or more SASL authentication methods might be able to
provide an adequate SACRED security service { server authentication, client
authentication, session key negotiation/derivation, roaming user support, ... } such
that basic attack scenarios would not be practical.  Is that really true?

I've not taken the time to go through all the SASL-based RFCs (and active drafts) to
create a more complete list of candidate algorithms but here's the current list from
IANA.  Perhaps others would care to comment on which algorithms appear to be suitable
for use with SACRED.  Recall that CRAM-MD5 and DIGEST-MD5 have been suggested to
date.  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.

Excerpt from IANA sasl-mechanism list follows:



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]


>
>
> -- Magnus
>
> On Fri, 26 Apr 2002, Magnus Nystrom wrote:
>
> >
> > Hi Tom,
> >
> > Without having validated the statement, I cite RFC 2831:
> >
> > "Offline dictionary attacks are defeated if the client chooses a fresh
> >  nonce for each authentication, as this specification requires."
> >
> > Regarding your second point, and despite the fact that I am sympathetic to
> > it, I don't think that was a requirement in RFC 3157. But I could well be
> > wrong (don't have proper access to it right now).
> >
> > BR,
> > -- Magnus
> >
> > On Mon, 22 Apr 2002, Tom Wu wrote:
> >
> > > Magnus Nystrom wrote:
> > > > Phoenix Technologies' statement can be found at:
> > > >
> > > > http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt
> > > >
> > > > I think we will have to accept that the IPR situation is unclear at the
> > > > moment, and will continue to be so for some time. As long as we base our
> > > > security on a framework like SASL, however, it will always be possible to
> > > > revisit this issue later on without extensive re-architecturing.
> > >
> > > As Keith pointed out, it is up to the individual WG member to evaluate
> > > the validity of IPR claims.  My own examination of the relevant patent
> > > and the circumstances surrounding it indicates that it does not have
> > > sufficient merit to prevent royalty-free implementation of RFC 2945.
> > >
> > > > Going back to Stephen's original posting therefore, one possible existing
> > > > SASL mechanism could be Digest-MD5, documented in RFC 2831. Digest-MD5
> > > > is not encumbered, offer security services such as integrity protection,
> > > > and does offer some advantages over other password-based mechanisms such
> > > > as CRAM-MD5.
> > >
> > > But it is still vulnerable to offline password-guessing.  Has there been
> > > some recently-established consensus to loosen the security requirements
> > > to accommodate a weaker authentication mechanism?
> > >
> > > > -- Magnus
> > >
> > > Tom
> > >
> > > > On Mon, 22 Apr 2002, Alexey Melnikov wrote:
> > > >
> > > >
> > > >>Eamon O'Tuathail wrote:
> > > >>
> > > >>
> > > >>>Tom,
> > > >>>
> > > >>>
> > > >>>>Stanford's royalty-free IPR statement is on file with the IETF.
> > > >>>>
> > > >>>True, and that is much appreciated, but ...
> > > >>>
> > > >>>.. has any company/organization other than Stanford make IPR claims
> > > >>>about SRP? If so, what are those claims, how valid are they, and are any
> > > >>>of those making the claims NOT prepared to offer royalty-free IPR on
> > > >>>them?
> > > >>>
> > > >>That is exactly the case. I am not in any shape or form an expert on IPR
> > > >>issues, but I've got impression that some organization (other than Stanford)
> > > >>has IPR claims for SRP. Can somebody clarify that?
> > > >>
> > > >>
> > > >>>If the technically excellent SRP were totally free from royalty-bearing
> > > >>>IPR claims, I would be happy to see it used, otherwise a different
> > > >>>
> > >
> > >
> > >
> > > --
> > > Tom Wu
> > > Principal Software Engineer
> > > Arcot Systems
> > > (408) 969-6124
> > > "The Borg?  Sounds Swedish..."
> > >
> > >
> >
> > -- Magnus
> >
> >
>
> -- Magnus