Subject: protocol progress...

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Apr 2002 12:34:10 +0100

Hi all,

Well, from reports of the sacred meeting it seems that though 
we've managed to bottom out all the previously known issues with 
the current draft, we still need to make some more changes to 
remove the dependence on SASL-SRP, given the uncertain future 
progress of that draft.

So if we want to progress the sacred protocol, we need to agree 
on some approach that doesn't suffer the same uncertainty.

Here's what appears to be a possible plan:-

1. remove srp dependencies from protocol document
2. make beep over tls mandatory to implement and pick 
   a "traditional" password based sasl scheme (hopefully
   with salt, iteration and digest - suggestions on a 
   postcard please!)
3. add/change security considerations to the effect that
   credential servers supporting the "must implement" 
   option do get to see a value that allows them to 
   mount a dictionary attack

As long as item 2 isn't controversial, this shouldn't take
very long.

What do we all think of doing this?

Sigh,
Stephen.

PS: I don't see much point in issuing a new protocol draft until
we sort this one out, let me know if you disagree with that.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Mon, 8 Apr 2002 15:14:18 +0100

Stephen,

Text such as the following is in the "APEX", "SOAP over BEEP" and other
BEEP profiles. Would you consider it or something similar for SACRED? 

It is much more likely BEEP implementions will automatically support a
common set of security considerations (so SACRED implementors will have
less work to do). 

Eamon

======================

Section 8 of
http://www.ietf.org/internet-drafts/draft-etal-beep-soap-06.txt

"8. Security Considerations

   Although service provisioning is a policy matter, at a minimum, all
   implementations must provide the following tuning profiles:

   for authentication: http://iana.org/beep/SASL/DIGEST-MD5

   for confidentiality: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)

   for both: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
      certificates)"

---

From: Tom Wu <[email-masked]>
Date: Tue, 09 Apr 2002 12:05:47 -0700

Stephen,

If uncertainty about the SASL-SRP draft is an issue, why not go with 
SRP/TLS, or some other strong password solution?  Item 2 requires a 
weakening in the previously agreed-to security requirements, which seems 
like a Bad Thing.

Tom

-- 
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg?  Sounds Swedish..."

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Apr 2002 12:08:31 +0100

Hi Tom,

Sorry for the slow response.

Tom Wu wrote:
> SRP/TLS, or some other strong password solution?  

What's the status of the SRP/TLS work?

> Item 2 requires a

I'm not sure that a zero-knowledge requirement was inclcuded, but in any
case I guess we have to either make progress or wait until whatever issues
bedevil SRP-SASL get solved.

Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 18 Apr 2002 10:45:52 -0500

Stephen,

> bedevil SRP-SASL get solved.

I think the requirement has centered on:

1) mutual authentication (in most cases), and
2) negotiate or derive a session key known only to credential server and
roaming client.

Strong-pw is a very good way to do that.  Don't think we can afford to give
ground on the requirements -- they seem pretty basic for credential exchange.

Other alternatives are:

 - TLS with any other SASL mechanism(s) that provide both 1) and 2).
 - SRP/TLS
 - sTLS with a client password :-(
 - other?

Best Regards,

Dale Gustafson

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Apr 2002 10:15:52 -0600

> > SRP/TLS, or some other strong password solution?

There are IPR issues with SRP in general, so from this prospective there is no
difference between SASL-SRP and SRP/TLS.
Am I wrong?

> I'm not sure that a zero-knowledge requirement was included, but in any

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

---

From: Tom Wu <[email-masked]>
Date: Sat, 20 Apr 2002 18:03:08 -0700

> difference between SASL-SRP and SRP/TLS.

Did you have a specific IPR issue that concerned you?  Stanford's 
royalty-free IPR statement is on file with the IETF.  We should be 
careful not to make decisions based on rumors.

Tom

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Sun, 21 Apr 2002 11:00:21 +0100

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?

If the technically excellent SRP were totally free from royalty-bearing
IPR claims, I would be happy to see it used, otherwise a different
solution is needed. 

Eamon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Apr 2002 06:36:55 -0600

> of those making the claims NOT prepared to offer royalty-free IPR on

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?

> IPR claims, I would be happy to see it used, otherwise a different

Alexey

---

From: Magnus Nystrom <[email-masked]>
Date: Mon, 22 Apr 2002 16:47:28 +0200 (W. Europe Daylight Time)

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.

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.

-- Magnus

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Apr 2002 11:12:10 -0400

> moment, and will continue to be so for some time

the IPR situation will be unclear as long as software patents exist.

everyone must make his/her own decision about whether to support a proposal, 
based not only on the technical merit of the proposal but also whether 
he/she thinks that any patents that might be claimed for the proposal 
will cause sufficient harm to make that proposal unacceptable.

IETF will not make that determiniation; it's up to the individual 
particpants.

Keith

---

From: Tom Wu <[email-masked]>
Date: Mon, 22 Apr 2002 10:19:18 -0700

> 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.

> and does offer some advantages over other password-based mechanisms such

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?

Tom

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 26 Apr 2002 18:56:29 +0200 (W. Europe Daylight Time)

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

-- Magnus

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 26 Apr 2002 19:09:07 +0200 (W. Europe Daylight Time)

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 passsword mechanism that we mandate must be as strong as
possible. But "possible" includes many aspects, and unfortunately not only
technical ones.

-- Magnus

-- Magnus

---

From: Dale Gustafson <[email-masked]>
Date: Fri, 26 Apr 2002 15:09:45 -0500

Hi Magnus,

Comments inline.

Best Regards,

--dg

Magnus Nystrom wrote:

> clearly the password mechanism that we mandate must be as strong as

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-masked]>                   [RFC2222]

GSSAPI                  IESG <[email-masked]>                   [RFC2222]

SKEY (OBSOLETE)         IESG <[email-masked]>                   [RFC2444]

EXTERNAL                IESG <[email-masked]>                   [RFC2222]

CRAM-MD5                IESG <[email-masked]>                   [RFC2195]

ANONYMOUS               IESG <[email-masked]>                   [RFC2245]

OTP                     IESG <[email-masked]>                   [RFC2444]

GSS-SPNEGO              Paul Leach <[email-masked]>        [Leach]

PLAIN                   IESG <[email-masked]>                   [RFC2595]

SECURID                 Magnus Nystrom <[email-masked]>[RFC2808]

NTLM                    Paul Leach <[email-masked]>        [Leach]

NMAS_LOGIN              Mark G. Gayman <[email-masked]>     [Gayman]

NMAS_AUTHEN             Mark G. Gayman <[email-masked]>     [Gayman]

DIGEST-MD5              IESG <[email-masked]>                   [RFC2831]

9798-U-RSA-SHA1-ENC     [email-masked]          [RFC3163]

9798-M-RSA-SHA1-ENC     [email-masked]          [RFC3163]

9798-U-DSA-SHA1         [email-masked]          [RFC3163]

9798-M-DSA-SHA1         [email-masked]          [RFC3163]

9798-U-ECDSA-SHA1       [email-masked]          [RFC3163]

9798-M-ECDSA-SHA1       [email-masked]          [RFC3163]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Apr 2002 15:45:54 -0600

Dale Gustafson wrote:

> ...

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.]

Alexey Melnikov

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 30 Apr 2002 10:43:19 -0500

Thanks, Alexey.

One additional comment, inline.

Best Regards,

Dale Gustafson

[ ... ]

>
> > Also, based on a cursory read, it appears that RFC-3163 is N/A since it

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?