Subject: Re: SRP and SM2

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 May 2001 00:55:43 -0600

"Raif S. Naffah" wrote:

> At 03:38 PM 4/22/01 -0700, Paul Leach wrote:
> > >
> > > As noted in section 7.4 of the SM2 draft, the "subsequent
> > > authentication" described in RFC 2831 maps nicely on to the
> > > SM2 exchange.  I suggest removing section 2.2 of RFC 2831 in
> > > favour of SM2.
> >
> >Since there are many existing implementations of RFC 2831, why not
> >rewrite SM2 to reuse the fast reconnect mechanism of RFC 2831 instead of
> >telling everyone to drop it and switch to a different mechanism.
>
> because SM2 is intended to be independent of any specific underlying
> mechanism.  while i can see how the fast reconnect mechanism of 2831 can be
> mapped to the SM2 session re-use, i fail to see the same for a mechanism
> such as SRP.
>
> again as Keith noted, it should not be impossible to amend SRP --or for
> that matter any non-trivial SASL mechanism-- to improve its performance
> if/when it offers a confidentiality service.  the aim of SM2 is to do that,
> in a generic way, for all SASL mechanisms,

I like the idea behind SM2 (it definitely makes sense and Java API shows a nice
way to implement SM2-<YYY> assuming the existence of an implementation of
<YYY>).
However I see the following problem with SM2 document (correct me if I am
wrong): every mechanism that can be used in reauthentication mode has to
describe
 1). Parameters that describe Security Context (they are mechanism dependent)
 2). Evidence (again mechanism dependent).
i.e. the specification of SASL mechanism <YYY> must define 1) and 2) in order
to be used under SM2.
(For example, currently there is no way to implement SM2-GSSAPI, because GSSAPI
doesn't define what 1) and 2) are). Assuming people agree that SM2 is a good
idea, this leaves 2 alternatives:
 1). Whenever a new SASL mechanism is written that can take advantage of
reauthentication, SM2 spec is updated to include 1). and 2). for this
mechanism. (IMHO, this is waste of effort)
 2). Put the description of SM2 into SASL spec, or at least publish SM2 ASAP as
an independent RFC. This has to be done *before* any other mechanism starts
using it. Otherwise we end up rewriting several SASL mechanisms in order to
include reauthentication support based on SM2.

Comments?

> including 2831 if its authors so desire.

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
I don't represent the opinion of TSA/ACI!
__________________________________________

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 03 May 2001 06:52:27 +1000

>way to implement SM2-<YYY> assuming the existence of an implementation of

glad to read that :-)

>i.e. the specification of SASL mechanism <YYY> must define 1) and 2) in order

correct (to both points).

>mechanism. (IMHO, this is waste of effort)

agree that this would be a waste of effort.

>include reauthentication support based on SM2.

this option (meaning either one of the two alternatives) makes more sense 
to me.  if anything we (authors of the SM2 draft) can do, can be done to 
facilitate this, we are happy to oblige.

> > including 2831 if its authors so desire.

cheers;
rsn

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 May 2001 00:55:43 -0600

Comments?

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 03 May 2001 06:52:27 +1000

glad to read that :-)

cheers;
rsn