Subject: draft-burdis-cat-srp-sasl-05: MDA name

From: Ken Murchison <[email-masked]>
Date: Fri, 07 Dec 2001 11:17:26 -0500

Keith, Raif,

What is the expected behavior of an implementation with respect to MDA
names?  Can we only support the "standard ASCII name" as defined by
[SCAN], or should we also support all of the aliases for each MDA?  In
either case, should the same rule(s) apply to the integrity layers?

Personally, I don't see the need to support the aliases, since you're
defining the SRP SASL spec and can dictate that the MDA names be the
"standard ASCII name" as defined by [SCAN].  I don't see how this would
hurt interoperability as long as its clearly defined in the spec.

Happy Holidays!
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: "Raif S. Naffah" <[email-masked]>
Date: Fri, 21 Dec 2001 19:52:55 +1100

hello Ken,

At 11:17 AM 12/7/01 -0500, Ken Murchison wrote:

>either case, should the same rule(s) apply to the integrity layers?...

i'm not sure we can fully answer this question right now! this is because 
it will depend on how SASL-SRP, and other similar "generic" mechanisms will 
be registered with IANA.

currently it was customary for a mechanism, described in a draft/RFC to 
have one name.  SASL-SRP and others --eg. SM2-- describe a family of 
concrete mechanisms, the name of which, in SASL-SRP's case, is dependant on 
the name of the underlying hash function.

this in a way is similar to the situation that faces the TLS WG: when they 
want to add support for new ciphersuites, they cannot allocate the final 
identifiers, unless/until the proposed suite(s) are approved.

there are different alternatives to answer this question, none of which is 
perfect.  assuming that such a generic mechanism, say SASL-SRP, becomes an RFC:

1. include in the RFC in an appendix, the 'current' list of fully qualified 
mechanism names, including the names of the underlying hash algorithms (and 
the reference(s) to their specifications) --so the reader would know what 
abc hash algorithm will be called/used, and which 
version/specification/variant of that abc algorithm is meant by that 
name.  the full list that would get included would be discussed/presented 
on this list, and may be also cc-ed to the SAAG.

2. separate the RFC into a "static" part and a "dynamic" one: eg. SRP SASL 
Mechanisms --Protocol, and SRP SASL Mechanisms --Algorithm Names and 
Specifications.  the latter may be an Informational document updated 
regularly or on an as-needed-basis.

(1) has the disadvantage of when amending the list of names+specifications, 
a new RFC has to be published to replace the previous one.

(2) the second diminishes the "status" of the "static" RFC by rendering it 
incomplete, though it offers the advantage of not requiring frequent 
updates (of the RFC part).

another alternative, say (3), would be to have the dynamic part an RFC in 
its own right, and use it for all SASL mechanisms that require such 
'dynamic' information.

other WGs in the IETF may also need 'standard' (as in pre-agreed) naming of 
primitives and algorithms --the one i can think of off the top of my head 
would be the SAAG.  if that is the case, it might be worth while 
investigating with other WGs the notion of a "Registry" for 
names/specifications of those things, that SASL-SRP and others do/may need.

>hurt interoperability as long as its clearly defined in the spec.

cheers;
rsn

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 21 Dec 2001 19:52:55 +1100

hello Ken,

cheers;
rsn

Date: Fri, 21 Dec 2001 19:52:55 +1100
To: Ken Murchison <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: [email-masked], [email-masked], SASL mailing list <[email-masked]>
Sender: [email-masked]

hello Ken,

cheers;
rsn

Date: Thu, 20 Dec 2001 22:47:34 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: Personal notes from unofficial SASL meeting at Salt-Lake City
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------37B9DDF1ADA512CCF2D3C63A
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

Comments/corrections/additions are welcome.
====
6 of us gathered at Salt-Lake to discuss outstanding issues.

Base SASL spec:

1). John showed a new text that should address the issue of character
set for authentication/authorization ids and passwords.
He proposed: Unicode with NUL character excluded. SASL mechanisms SHOULD
use UTF-8 to encode Unicode.

Also John noted that there is an issue of how to encode passwords with
characters from Unicode (that is likely to be an issue for Europe). John
will include new text in the next revision of SASL draft.

John also suggested that clients MUST use Unicode Normalization Form KC
and servers MAY check this.
This probably requires more discussion on the mailing list.

The question of binary authentication/authorization id (e.g. BER
encoding of a name) was also discussed, but the group agreed that a
protocol profile can describe how to encode them before passing to a
SASL mechanism.

2). John added more text about authorization id and proxy
authentication.

3). I've asked John to add non-normative reference to SM2.
John should add some text that says that a future document may define
how to write mechanisms that support reauthentication.

======================================
CRAM-MD5:

1). Specify that Unicode Normalization Form KC is used for userids and
password (NUL character is not allowed), encoded as UTF-8.

2). ABNF for challenge string: can we relax syntax to be a random string
from 0..9,a..z,... repertoire?
John agreed that client has no reason to verify the syntax of challenge,
so this is probably Ok.
We have to double check with ADs.
======================================
DIGEST-MD5:

[Chris Newman wasn't present, but I talked to him later during the IETF
week .]

1). Chris Newman promised to submit a revision in a couple of weeks.
Collected set of issues [attached] from John, Larry and myself was sent
to Chris.

2). Add AES cipher as separate document.
 I will submit the new draft shortly after IETF.

======================================
GSSAPI:

1). Move base-32 out of the document?

 John agreed to do that

2). Why generation of GSSAPI mechanism name is so complex?

 Do we really need ASN1?

 From GSSAPI C-Binding:

   typedef struct gss_OID_desc_struct {
      OM_uint32   length;
      void        *elements;
   } gss_OID_desc, *gss_OID;

   The elements field of this structure points to the ***first byte of
an
   octet string containing the ASN.1 BER encoding*** of the value
portion
   of the normal BER TLV encoding of the gss_OID.

3). How to list of GSSAPI mechanisms using GSSAPI?
 Server either has to know SASL names of all GSSAPI mechanisms it
supports or it can use gss_indicate_mechs that returns list of OIDs for
supported mechanisms.
John will add a reference to this function.

4). We've spent some time talking about the correct list of OIDs that
correspond to Kerberos V5 mechanism. Also Larry raised a question about
cipher negotiation and Kerberos V5.
Tom Yu from MIT clarified things by explaining that K5 mechanism allows
for DES and 3DES ciphers and that any new cipher (like AES) will force a
new OID. Tom also pointed out that there is a bug in OID for Kerberos
described in one of the Kerberos V5 RFCs [I forgot which one].

GSSAPI document should be ready for Last Call.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

--------------37B9DDF1ADA512CCF2D3C63A
Content-Type: text/plain; charset=koi8-r;
 name="Digest-collected-issues.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Digest-collected-issues.txt"

1). Security considerations:
 How does DIGEST-MD5 protect against downgrade of maxbuf, qop, qop-options?

2). Security considerations? :
  Ciphers can't have keys longer than 128 bit (i.e. length of MD5 output) [e.g. aes-192]
  128 bit key is probably fine.

3). DES and 3DES are mandatory to implement for privacy layer, change to 3DES?

4). 
>   Kcc = MD5({H(A1)[0..n],
>   "Digest H(A1) to client-to-server sealing key magic constant"})

Change "[0..n]" to "[0..n-1]" or "[1..n]".

>   The key for confidentiality protecting messages from server to client
>   is:

>   Kcs = MD5({H(A1)[0..n],
>   "Digest H(A1) to server-to-client sealing key magic constant"})

Change "[0..n]" to "[0..n-1]" or "[1..n]".

>   where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
>   for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"

Typo "rc4-*"

>   ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first
>   7 bytes; the key for "3des" is the first 14 bytes. The IV for "des"
>   and "3des" is the last 8 bytes of Kcc or Kcs.

5). is the quoted or unquoted version of the username, etc. used in calculating A1?

 Unquoted!

6). Tighten the syntax of the nonce and cnonce to prohibit quoted characters.  Should be:
    nonce-value = *qdtext
    cnonce-value = *qdtext

7). fix ABNF to allow utf-8 username-value and authzid-value
    the formal syntax restricts this to TEXT or "\" CHAR.
    the charset thing makes this difficult, as iso-8859-1 can be
    allowed in the username.

 ABNF is not strict enough, because it allows any 8bit data!

8). nc-value: shouldn't it be the server aborting the exchange?

======================================
Implementation:

1). des/3des doesn't interoperate

======================================
Editorial:

1). Issues with reauthentication step:
 Put into separate draft in order not to delay base mechanism?
(i.e. Do we have two independent implementations that interoperate?).

--------------37B9DDF1ADA512CCF2D3C63A--

Date: Sun, 09 Dec 2001 17:43:11 -0700
From: ietf guest <[email-masked]>
To: [email-masked]
Subject: SASL bar BOF in Salt-Lake
Sender: [email-masked]

If there are no objections, let's meet on Monday, at 19:30 near message
board.

Alexey

Date: Fri, 07 Dec 2001 11:17:26 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked], [email-masked]
CC: SASL mailing list <[email-masked]>
Subject: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Keith, Raif,

Happy Holidays!
Ken

Date: Fri, 07 Dec 2001 00:03:12 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL bar BOF at Salt-Lake?
Sender: [email-masked]

As we don't have an officially allocated slot I suggest we gather to
discuss status of the documents. Any preferences (and interest)?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Mon, 03 Dec 2001 18:50:56 -0800
To: Lyndon Nerenberg <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CRAM-MD5: syntax for challenge 
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:50 AM 2001-12-03, Lyndon Nerenberg wrote:
>But if everyone thinks the status quo is fine I'll
>leave it as is.

Unless there is consensus that the mechanism detailed in
RFC 2195 is broken, we shouldn't try to fix.

While it is clear that the mechanism has limited applicability,
I see no evidence that the mechanism is actually broken.

Kurt

Date: Mon, 03 Dec 2001 16:23:01 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: SASL mailing list <[email-masked]>
Subject: draft-burdis-cat-srp-sasl-05
Sender: [email-masked]

Keith,

Is there any technical reason why the authorization id (I) is sent in a
separate exchange from the authentication id (U)?  I notice in draft -03
that they used to be sent in the same exchange, but U was pulled out in
draft -04 to make SRP a client-first mechanism instead of a server-first
mech.  Why weren't they moved together?

The reason that I ask is that I'm working on a SRP plugin for the CMU
SASL implementation (using Tim Martin's work as a very good and almost
complete starting point).  I ran into a problem which technically
appears to be an issue with the SASL C API, but can easily be resolved
with a minor change to the SRP exchanges.

I won't get into the details of the C API problem unless someone
needs/wants to know, but I'd like to suggest that 'I' be sent with 'U',
ie:

Client  ---  { utf8(U) | utf8(I) } ------------------->  Server

Client  <--- { mpi(N) | mpi(g) | os(s) | utf8(L) }  ---  Server

Client  ---  { mpi(A) | utf8(o) }  ------------------->  Server

...

I don't see how this change would have any negative impact, and it would
also bring SRP more in line with the other SASL mechs that allow for
proxying (PLAIN and OTP) which send the authid and authzid in the
initial client request.

Regards,
Ken

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: CRAM-MD5: syntax for challenge 
Date: Mon, 03 Dec 2001 11:53:23 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Certainly if the server does 
> not have a unique hostname you may have an issue. Say the server is behind 
> a firewall with NAT, then you might have [10.0.1.1] as part of the 
> challenge. Is that what you are concerned with?

I was more concerned about the DHCP dynamics, however NAT could be
an issue as well.

--lyndon

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: CRAM-MD5: syntax for challenge 
Date: Mon, 03 Dec 2001 11:50:36 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

Sorry, I meant to say server, not client. In server environments
it's becoming more common to use DHCP configuration (e.g. ADSL and
cable modems). But if everyone thinks the status quo is fine I'll
leave it as is.

--lyndon

Date: Mon, 03 Dec 2001 11:01:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: CRAM-MD5: syntax for challenge
Sender: [email-masked]

--On Sunday, December 2, 2001 8:15 PM -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

> RFC2195 defines the challenge as having the syntax of a message-id,
> and gives some guidance for building the contents. I don't think
> the currently recommended scheme is as robust as it could be. Mobile
> clients configured via DHCP tend to re-use hostnames and IP addresses;
> this diminshes the uniqueness of the host part of the message-id. I'm
> leaning towards taking out the recommendation, and instead say the
> contents of the challenge must be a random sequence of printable
> characters. I would also like to impose a minimum length on the
> challenge.

The challenge is sent (and thus generated) by the server, so I don't see 
why the 'DHCP-ness' of the client is an issue. Certainly if the server does 
not have a unique hostname you may have an issue. Say the server is behind 
a firewall with NAT, then you might have [10.0.1.1] as part of the 
challenge. Is that what you are concerned with?

-- 
Cyrus Daboo

Date: Sun, 02 Dec 2001 23:09:08 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: CRAM-MD5: syntax for challenge
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> >I'm leaning towards taking out the recommendation, and instead say the
> >contents of the challenge must be a random sequence of printable
> >characters. I would also like to impose a minimum length on the
> >challenge.
>
> I would suggest not mucking with it.

 I tend to agree with Lyndon. Because challenge string is only used inside
MD5 (example from the draft below)
     MD5((tanstaaftanstaaf XOR opad),
               MD5((tanstaaftanstaaf XOR ipad),
               <[email-masked]>))

then it is irrelevant what format challenge has. This change allows
implementations to generate a more unpredictable challenge.

However I don't agree to impose any restrictions on length, as this will
make some existing implementations non compliant. This should be SHOULD,
not MUST.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Sun, 02 Dec 2001 20:03:10 -0800
To: Lyndon Nerenberg <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CRAM-MD5: syntax for challenge
Cc: [email-masked]
Sender: [email-masked]

At 07:15 PM 2001-12-02, Lyndon Nerenberg wrote:
>RFC2195 defines the challenge as having the syntax of a message-id,
>and gives some guidance for building the contents. I don't think
>the currently recommended scheme is as robust as it could be. Mobile
>clients configured via DHCP tend to re-use hostnames and IP addresses;
>this diminshes the uniqueness of the host part of the message-id.

It's the server/s FQDN, so why does it matter that the client
is using DHCP or not?

>I'm leaning towards taking out the recommendation, and instead say the
>contents of the challenge must be a random sequence of printable
>characters. I would also like to impose a minimum length on the
>challenge.

I would suggest not mucking with it.

Kurt

To: [email-masked]
Subject: CRAM-MD5: syntax for challenge
Organization: ACI Worldwide - Advanced Technology Group
Date: Sun, 02 Dec 2001 20:15:33 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

RFC2195 defines the challenge as having the syntax of a message-id,
and gives some guidance for building the contents. I don't think
the currently recommended scheme is as robust as it could be. Mobile
clients configured via DHCP tend to re-use hostnames and IP addresses;
this diminshes the uniqueness of the host part of the message-id. I'm
leaning towards taking out the recommendation, and instead say the
contents of the challenge must be a random sequence of printable
characters. I would also like to impose a minimum length on the
challenge.

--lyndon