Subject: draft-burdis-cat-srp-sasl-07

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Oct 2002 15:01:22 -0400

Minor nit:

I'd like to see text added to section 4.1 similar to what can be found
in other mechanisms that support proxying (PLAIN, OTP, etc), eg:

"The client may leave the authorization identity empty to indicate that
it is the same as the authentication identity."

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 12:26:33 -0700

>it is the same as the authentication identity."

Actually, I like to change these statements to:
  The client should leave the authorization identity empty (or
  absent) unless it is attempting to assume an identity other
  than that indicated by the authentication identity.

This because the client should not assume that it can provide
an authorization identity form which the server will recognize
as representing the authentication identity.  Remember, the
form of the authorization identity is profile specific (and
these profiles often deferred the particulars to
implementations).

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 12:57:21 -0700

At 01:42 PM 2002-10-14, Keith Burdis wrote:
>On Monday 14 October 2002 19:26, Kurt D. Zeilenga wrote:
>> >I'd like to see text added to section 4.1 similar to what can be
>> > found in other mechanisms that support proxying (PLAIN, OTP, etc),
>> > eg:
>> >
>> >"The client may leave the authorization identity empty to indicate
>> > that it is the same as the authentication identity."
>>
>It seems a little odd that you are authorised using the authorisation 
>identity sometimes, except when it is empty in which case you're 
>authorised using the authentication identity.

It's not odd at all.  If you are assuming the identity of another
user, you need to assert a string representing that user.  However,
if you are not assuming the identity of another user, there is
no need to assert an explicit authorization identity.

>Isn't it better to be 
>explicit about the identity that should be used for authorisation 
>decisions?

No.  Because to assert the authorization identity associated with
your authentication identity, you need to know how the server
associates authentication identities to authorization identities.
You should not assume that authentication identity X is equivalent
to authorization identity X, because each X could be in separate
name spaces.

SASLbis needs to be clear that the purpose of the authorization
identity is proxy authorization and that when the client does
not wish to do proxy authorization, the authorization identity
should be absent or empty.

>How about:
>
>"The client MUST set the authorisation identity to the same value as the 
>authentication identity unless it is attempting to assume an identity 
>other than that indicated by the authentication identity."

This doesn't work with all mechanisms and all profiles.  You are
assuming that form of the authentication and authorization identities
are the same and that they are in same name space.

Consider for example, EXTERNAL.  The client doesn't even know
exactly what low-level credential the server is using, let alone
know how it maps that credential to an authorization identity.

What if you are using LDAP w/ DIGEST-MD5 (or whatever).  While
the authentication identity "foo" may be valid, foo is an
INVALID authorization identity.  LDAP authorization identities
are the form:
        u:userid / dn:DN

where userid is some UTF-8 identity (not necessarily the authentication
identity) and DN is a DN.

>Either way, I think the "should" should be a MUST :-)

A SHOULD is sufficient.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 19:00:12 -0700

At 06:32 PM 2002-10-14, Keith Burdis wrote:
>So, when you are NOT assuming the identity of another user then your 
>authorisation identity is _somehow associated_ with your authentication 
>identity, but when you ARE assuming the identity of another user then 
>you have to _specify_ the authorisation identity of the other user. 

Yes.

>Okay. This makes sense.
>But, then why is is necessary to know how the server associates 
>authentication identities to authorization identities in order to 
>assume the identity of another user? 

You don't.  You only need to know the authorization identity of
the user you are trying to assume.

>Agreed. It should also be clear on what is meant by proxy authorisation 
>and what an authorisation identity is and how it differs from an 
>authentication identity.
>
>> >How about:
>> >
>> >"The client MUST set the authorisation identity to the same value as
>> > the authentication identity unless it is attempting to assume an
>> > identity other than that indicated by the authentication identity."
>>
>Indeed I was.
>If the client doesn't know how the mapping works then how will it be 
>possible for it to assume the identity of another user?

It just asserts what it knows that user's authorization identity.

>Surely it needs to be able to map from an authentication identity to an authorisation 
>identity in order to specify the new user's authorisation identity.

No.  It just need to know what that user's authorization identity.

>If not, then how does it know the new user's authorisation identity?

by prior knowledge.

>> where userid is some UTF-8 identity (not necessarily the
>> authentication identity) and DN is a DN.
>
>If I authenticate as foo what identity am I authorised as?

Profile, implementation, or deployment specific.

Kurt

---

From: Keith Burdis <[email-masked]>
Date: Tue, 15 Oct 2002 04:56:16 +0000

Thanks for the explanations Kurt.

If Ken is happy with your wording and no-one else has any further 
comment on this we'll add it to the next version of the draft.

  - Keith

On Tuesday 15 October 2002 02:00, Kurt D. Zeilenga wrote:
> >authorisation identity is _somehow associated_ with your
> > authentication identity, but when you ARE assuming the identity of
> > another user then you have to _specify_ the authorisation identity
> > of the other user.
>
> Yes.
>
> >> >Isn't it better to be
> >Agreed. It should also be clear on what is meant by proxy
> > authorisation and what an authorisation identity is and how it
> > differs from an authentication identity.
> >
> >> >How about:
> >> >
> >> >"The client MUST set the authorisation identity to the same value
> >> > as the authentication identity unless it is attempting to assume
> >> > an identity other than that indicated by the authentication
> >> > identity."
> >>
> >> assuming that form of the authentication and authorization
> >> identities are the same and that they are in same name space.
> >
> >Indeed I was.
> >
> >Surely it needs to be able to map from an authentication identity to
> > an authorisation identity in order to specify the new user's
> > authorisation identity.
>

---

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 15 Oct 2002 19:45:52 +1000

Kurt suggests:

   "The client should leave the authorization identity empty
   (or absent) unless it is attempting to assume an identity
   other than that indicated by the authentication identity."

how can an implementor of a mechanism enforce this?

shouldn't this wording/requirement be part of the Profile?

cheers;
rsn

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Oct 2002 09:47:30 -0400

> comment on this we'll add it to the next version of the draft.

I'm comfortable with what Kurt suggests, as it is good policy.  I just
wanted to make it clear that the authzid COULD be left empty.  I also
agree that SASLbis should be more clear on the fact that the sole
purpose of authzid is proxying.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Oct 2002 08:02:36 -0700

>how can an implementor of a mechanism enforce this?

The client implementor, by not accepting an authzid from the user
unless that user has asked to do proxy authorization and then not
encoding an authzid to the server, can implement this.

Note that "implementor" applies not just to the programmer
writing a plugin to some SASL library.  The term applies
broadly to set of developers responsible for implementing
a protocol peer.

>shouldn't this wording/requirement be part of the Profile?

No.  Because that would make the semantics of a present
authzid specific (as opposed to just the form).

The needs to be in RFC 2222bis, and is:
  As a client might not have the same information as the server,
  clients SHOULD NOT themselves try to derive authorization
  identities from authentication identities when clients could
  instead transmit an authorization identity of the empty string. 

Mechanism specifications need to echo it or, at least, not
make statements which are counter it.

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 16 Oct 2002 05:12:39 +1000

On Wednesday 16 October 2002 01:02, Kurt D. Zeilenga wrote:
> The client implementor...
>

but we _are_ writing specifications for this class of implementors; i.e. 
those writing plugins.  therefore a wording based on what you later 
suggests be added to rfc-2222b makes more sense to me:

   "The Client SHOULD NOT derive a value for the authorization
   identity, if one was not specified by the Profile that uses
   this mechanism."

>   instead transmit an authorization identity of the empty string.

if you meant that the above should be added to rfc-2222bis, then i 
second it.

> make statements which are counter it.

agreed.

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Oct 2002 12:38:25 -0700

At 12:12 PM 2002-10-15, Raif S. Naffah wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: RIPEMD160
>
>those writing plugins.

I disagree.  We should avoid distinguishing the "application"
from the "library" from the "plugin".  Requirements are
stated upon peers of an application protocol incorporating
SASL and SASL mechanisms into the application protocol's
technical specification by normative reference.

>therefore a wording based on what you later 

No profile today says how to derive values for the authorization
identity.

I believe that the authorization identity provided should not
be a derived value.  It should be whatever value the client
has been instructed to use by user.  The client should only
validate that value is in the proper form (as specified
in the application profile).  If the user provides a value,
the client should use it.  If the user doesn't provide a
value, the client should not attempt to derive a value from
the authentication credentials.

RFC 2222bis needs further clarification in this area.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 05:31:41 +1000

On Wednesday 16 October 2002 05:38, Kurt D. Zeilenga wrote:
> >...
> ...
> has been instructed to use by user...

fair enough.  how about this:

   "The Client SHOULD NOT derive a value for the authorization
   identity.  If one was not specified by the Profile a 0-long
   string should be used."

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Oct 2002 12:40:59 -0700

>   identity.  If one was not specified by the Profile a 0-long

I don't understand the second sentence.  How does a profile
provide an authorization identity value?  The profile only
specifies the form of the authorization identity.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 06:16:02 +1000

On Thursday 17 October 2002 05:40, Kurt D. Zeilenga wrote:
> provide an authorization identity value?

i can think of 2 possible ways:

1. as one of the parameters it uses when instantiating the mechanism,
2. as an argument to a set(...) method in the mechanism API.

>...  The profile only

...and the value!  the SASL specs (a) mandates how this entity is passed 
to the mechanism, and (b) what the intended use of that entity is for 
- --draft-myers-saslrev-02.txt, page 4, section 4.2, para. 1.

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Oct 2002 14:05:24 -0700

Your post I find even more confusing.  I think you are using
the term "profile" to refer to something other than the
portion of the application protocol's technical specification
which details how the SASL technical specification is to be
incorporated into the application protocol.

> >   identity.  If one was not specified by the Profile a 0-long

If I try to read between the lines, I think you are trying
to suggest something like:
	The client SHOULD NOT derive a value for the authorization
	identity.  If the user (or application entity) has not
	provided a value, an empty (or absent) authorization
	identity SHOULD be transferred.

This would be fine.  If you trying to suggest something else,
you'll need to try again as obviously you lost me.

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 21:32:30 +1000

On Thursday 17 October 2002 07:05, Kurt D. Zeilenga wrote:
> ...I think you are using

no i'm not.  i intentionally avoided inventing new words and used the 
term Profile the way it is described in the SASL RFC (and revised 
draft, section 3, 2nd and 3rd paragraphs).

i also referred to the authorisation identity as a "string" as stated in 
the same document section 4.2, 1st paragraph.

we can add the above to the draft if that helps removing any ambiguity.

> This would be fine...

if other people on this list think that "user (or application entity)" 
is clearer than "Profile", and so is "an empty (or absent) 
authorization identity" compared to "0-long string" then it's fine by 
me.

thanks + cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 17 Oct 2002 07:40:53 -0700

>draft, section 3, 2nd and 3rd paragraphs).

Section 3 describes a "profile" a particular kind of technical
specification.   However, you are using "profile" to refer to a
portion of a client's implementation.  That is, you are
confusing layering of specification with possible layering
within a client implementation.  This is clear from your mention
of APIs and such.

>the same document section 4.2, 1st paragraph.

The user doesn't necessarily provide a "string".  The user can
provide the value of the authorization identity in any form which
the client implementation is capable of producing a string for
transfer (conforming to the form specified in the application
protocol's SASL profile).

>we can add the above to the draft if that helps removing any ambiguity.

There likely needs to be some clarification added.

>is clearer than "Profile",

I think "user (or application identity)" more clearly refers to
the user of the client implementation and not the client implementation
itself (or portion of).

>and so is "an empty (or absent) 

I think empty (or absent) is better because some mechanisms
are specification designed such that no authorization identity
is sent when empty.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 12:26:33 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 12:57:21 -0700

A SHOULD is sufficient.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Oct 2002 19:00:12 -0700

Yes.

by prior knowledge.

Kurt

---

From: Keith Burdis <[email-masked]>
Date: Tue, 15 Oct 2002 04:56:16 +0000

- Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 15 Oct 2002 19:45:52 +1000

Kurt suggests:

cheers;
rsn

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Oct 2002 09:47:30 -0400

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Oct 2002 08:02:36 -0700

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 16 Oct 2002 05:12:39 +1000

agreed.

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Oct 2002 12:38:25 -0700

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 05:31:41 +1000

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Oct 2002 12:40:59 -0700

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 06:16:02 +1000

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Oct 2002 14:05:24 -0700

Kurt

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 17 Oct 2002 21:32:30 +1000

thanks + cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 17 Oct 2002 07:40:53 -0700

Date: Thu, 17 Oct 2002 07:40:53 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Date: Thu, 17 Oct 2002 21:32:30 +1000
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

thanks + cheers;
rsn

Date: Wed, 16 Oct 2002 14:05:24 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

Kurt

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Date: Thu, 17 Oct 2002 06:16:02 +1000
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

cheers;
rsn

Date: Wed, 16 Oct 2002 12:40:59 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Date: Thu, 17 Oct 2002 05:31:41 +1000
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

cheers;
rsn

Date: Tue, 15 Oct 2002 12:38:25 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: authzid in 2222bis (was: draft-burdis-cat-srp-sasl-07)
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Date: Wed, 16 Oct 2002 05:12:39 +1000
Cc: [email-masked], Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

agreed.

cheers;
rsn

Date: Tue, 15 Oct 2002 08:02:36 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Cc: [email-masked], Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

Kurt

Date: Tue, 15 Oct 2002 09:47:30 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Sender: [email-masked]

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Date: Tue, 15 Oct 2002 19:45:52 +1000
Cc: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

Kurt suggests:

cheers;
rsn

From: Keith Burdis <[email-masked]>
Reply-To: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Date: Tue, 15 Oct 2002 04:56:16 +0000
Cc: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

  - Keith

> Profile, implementation, or deployment specific.

Date: Mon, 14 Oct 2002 19:00:12 -0700
To: Keith Burdis <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Cc: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

Yes.

by prior knowledge.

Kurt

Date: Mon, 14 Oct 2002 12:57:21 -0700
To: Keith Burdis <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Cc: Ken Murchison <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

A SHOULD is sufficient.

Date: Mon, 14 Oct 2002 12:26:33 -0700
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07
Cc: SASL mailing list <[email-masked]>
Sender: [email-masked]

Kurt

Date: Mon, 14 Oct 2002 15:01:22 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: draft-burdis-cat-srp-sasl-07
Sender: [email-masked]

Minor nit:

Ken

Date: Mon, 14 Oct 2002 10:36:03 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: HTTP Authentication BOF?
Sender: [email-masked]

I would like to arrange for a HTTP Authentication BOF. If there is
enough interest in this, I will request a formal slot. Discussion would
be mostly concentrated on
http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-04.txt, but
I would be happy to discuss any other related documents, e.g.
draft-brezak-spnego-http-04.txt.

Please, send comments to me directly.

Cheers,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

Date: Mon, 14 Oct 2002 09:31:48 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

On Mon, 14 Oct 2002, Alexey Melnikov wrote:

> I currently see no interest in official BOF (correct me if I am wrong).
> So I suggest we hold an informal meeting to progress various documents
> (SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
> there is an almost empty slot on Tuesday, November 19 from 14:15 till
> 15:15.

For my purposes 17:00-18:00 on Tuesday would be best, figuring that S/MIME
likely won't use the whole two+ hours, and allowing for possible dinner
discussion.

 - RL "Bob"

Date: Mon, 14 Oct 2002 10:00:57 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

Alexey Melnikov wrote:

> I currently see no interest in official BOF (correct me if I am wrong).
> So I suggest we hold an informal meeting to progress various documents
> (SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
> there is an almost empty slot on Tuesday, November 19 from 14:15 till
> 15:15.

Hmm, after checking the most recent agenda I see that this conflicts with
Kerberos WG meeting.
I am open to suggestions.

> Comments?

Cheers,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

Date: Mon, 14 Oct 2002 07:25:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL (informal) meeting in Atlanta
Sender: [email-masked]

I currently see no interest in official BOF (correct me if I am wrong).
So I suggest we hold an informal meeting to progress various documents
(SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
there is an almost empty slot on Tuesday, November 19 from 14:15 till
15:15.

Comments?

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-melnikov-rfc2831bis-01
From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Oct 2002 02:14:55 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> The sequence number is an unsigned number initialized to zero after
> initial or subsequent authentication, and incremented by one for each
> message sent/successfully verified. (Note, that there are two independent
> counters for sending and receiving.) The sequence number wraps around to
> 0 after 2**32-1.
>
> I've also added
>
> The receiver's sequence counter is incremented if they match.
>
> at the end of the next paragraph starting with "Upon receipt ...".
>
> Any comments?

Looks good, thanks.  The main unclear point I was thinking of was if
the sequence number was reset to 0 after subsequence authentication or
not.

Date: Wed, 09 Oct 2002 08:09:50 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-rfc2831bis-01
Sender: [email-masked]

Simon Josefsson wrote:

> The draft does not describe how the sequence numbers are used in
> integrity/confidentiality protection, here is some proposed text.
>
> In section 2.3, add the following to the sentence beginning with
> "where MD5 is as":
>
>    The sequence number is an unsigned counter set to 0 after initial
>    or subsequent authentication and incremented with 1 after each
>    successfully generated or verified MAC, wrapping around to 0 when
>    exceeding its 4-byte

Actually the current text says:

The sequence number is initialized to zero, and  incremented by one for
each message sent.

I will change it to:

The sequence number is an unsigned number initialized to zero after
initial or subsequent authentication, and incremented by one for each
message sent/successfully verified. (Note, that there are two independent
counters for sending and receiving.) The sequence number wraps around to
0 after 2**32-1.

I've also added

The receiver's sequence counter is incremented if they match.

at the end of the next paragraph starting with "Upon receipt ...".

Any comments?

> In section 2.4, add the following to the sentence beginning with
> "The MAC block is":
>
>    The sequence number is an unsigned counter set to 0 after initial
>    or subsequent authentication and incremented with 1 after each
>    successfully generated or verified SEAL, wrapping around to 0 when
>    exceeding its 4-byte size.

Same changes as above.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

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

To: [email-masked]
Subject: Comments on draft-melnikov-rfc2831bis-01
From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Oct 2002 03:02:25 +0200
Sender: [email-masked]

The draft does not describe how the sequence numbers are used in
integrity/confidentiality protection, here is some proposed text.

In section 2.3, add the following to the sentence beginning with
"where MD5 is as":

   The sequence number is an unsigned counter set to 0 after initial
   or subsequent authentication and incremented with 1 after each
   successfully generated or verified MAC, wrapping around to 0 when
   exceeding its 4-byte

In section 2.4, add the following to the sentence beginning with
"The MAC block is":

   The sequence number is an unsigned counter set to 0 after initial
   or subsequent authentication and incremented with 1 after each
   successfully generated or verified SEAL, wrapping around to 0 when
   exceeding its 4-byte size.

From: "Raif S. Naffah" <[email-masked]>
To: SASL WG <[email-masked]>
Subject: SM2 presentation
Date: Thu, 3 Oct 2002 09:40:19 +1000
Sender: [email-masked]

hello there,

for those who are interested, i've prepared a powerpoint presentation 
about SM2 -- <http://www.fl.net.au/~raif/java/atlanta.zip>.

Alexey Melnikov has kindly accepted to present SM2 during the Atlanta 
gathering if/when the occasion arises.

cheers;
rsn

ps. if you have problems downloading the above, pls. drop me a note in 
private.