Subject: Realms (DIGEST-MD5 and otherwise)

From: Lawrence Greenfield <[email-masked]>
Date: 27 Aug 1999 18:54:13 -0400

Hi,

I've been thinking about multiple realms on servers a lot lately, and
it would simplify implementations as well as users if we can impose
some rules on valid realm strings.

I would propose that realms be DNS-style and should be in all
uppercase letters (and implementations may be free to uppercase realms
for the user).  This follows the conventions of Kerberos.  Allowing
any arbitrary, case-sensitive string that users might have to type in
is especially annoying.

Allowing @'s in realms is especially confusing, since it makes it
hard for a server to refer to a user as user@REALM.

Could we add this restriction to DIGEST-MD5 and propose it as a
guideline for future mechanisms?

Larry

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 1999 00:01:49 -0600

> any arbitrary, case-sensitive string that users might have to type in

I 100% agree with you.
BTW, I've raised this question during Minneapolis DIGEST lunch. 
Probably I haven't explain the problem clearly.

The only problem I see is that DIGEST-MD5 should be compatible with 
HTTP digest. The later allows to use any text string as realm (and I've
seen implementations that use such HTTP realms)

> hard for a server to refer to a user as user@REALM.

I will not argue about using '@' in realm, but I would suggest that 
realm may contain something like "group specifier". So the 
proposed syntax of realm would be 
[<group>.]<fqn>

> guideline for future mechanisms?

Keeping in mind compatibility with HTTP this should be SHOULD, not MUST.
-------------------
Alexey Melnikov
[email-masked]

* This e-mail message was sent with Execmail V5.0 *

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 1999 00:01:49 -0600

I 100% agree with you.

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Aug 1999 00:01:49 -0600
To: Lawrence Greenfield <[email-masked]>
Subject: Re: Realms (DIGEST-MD5 and otherwise)
Cc: [email-masked]
Sender: [email-masked]

I 100% agree with you.

Date: 27 Aug 1999 18:54:13 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Realms (DIGEST-MD5 and otherwise)
Sender: [email-masked]

Hi,

Larry

From: "[email-masked]" <[email-masked]>
Bcc:
Reply-To: 
Subject: Free Internet Stock Newsletter
Date: Sun, 08 Aug 1999 04:37:54 -0400 (EDT)
Sender: [email-masked]

We are offering a new internet and small cap 
newsletter at no charge. We will deliver to you 
via email on a weekly basis a market re-cap and 
selected small cap stock ideas. If you are interested
in this service, click here ( mailto:[email-masked] )
to start receiving ideas for today's investor.     

************************************************************************
Removal Instructions:For removal just click on the link
below, and leave remove in the subject line and your name
will be removed within 48 hours of your request. Thank You
for your time.

( mailto:[email-masked] )

Under bill s.1618 TITLE III passed by the 105th U.S. Congress
this letter can not be considered spam as we include: Contact
information and a Remove Link.
************************************************************************  
*************
99208

Date: 12 Aug 1999 19:40:52 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: digest-md5 issues
Sender: [email-masked]

   The version is 0x0001 -- i.e., two bytes, not one.

Whoops, my mistake.  Can't add.

Sorry,
Larry

From: "Paul Leach (Exchange)" <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: RE: digest-md5 issues
Date: Thu, 12 Aug 1999 16:15:05 -0700
Sender: [email-masked]

The version is 0x0001 -- i.e., two bytes, not one.

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Thursday, August 12, 1999 3:33 PM
> To: [email-masked]
> Subject: digest-md5 issues
> 
> 
> I talked with Paul Leach today, and he told me of the following
> pending changes to digest-md5, which we'll be implementing in upcoming
> versions of our library.
> 
> For integrity protection the trailer is:
> 
> MAC(Ki, SeqNum, msg) = { HMAC(Ki, (SeqNum, msg))[0..9], 0x01, SeqNum }
> 
> For confidentiality protection, the encoding will be:
> 
> { msg, pad, HMAC, version, seq }
> 
> where msg, pad, and HMAC are encrypted, and the padding is sufficient
> to make the plaintext a multiple of the block length.
> 
> The version is 0x01; the sequence number is four bytes; both are
> transmitted in the clear.
> 
> Finally, we discussed realms and agreed that Pete Resnick summed up
> the discussion pretty well: servers may send a list of realms, and if
> they do, the client must pick one of them.  If the server sends no
> realms, the client may pick one (via some other agreement).
> 
> If the client sends no realm, the server assumes it's the empty
> string.
> 
> Paul promises a new draft will be coming out just as soon as he can
> copy and paste his entire document and the network catches up with
> him.  :^) (It's possible I'm confused; I'm sure the techology at
> Microsoft is state-of-the-art.)
> 
> Larry
> 

Date: 12 Aug 1999 18:32:58 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: digest-md5 issues
Sender: [email-masked]

I talked with Paul Leach today, and he told me of the following
pending changes to digest-md5, which we'll be implementing in upcoming
versions of our library.

For integrity protection the trailer is:

MAC(Ki, SeqNum, msg) = { HMAC(Ki, (SeqNum, msg))[0..9], 0x01, SeqNum }

For confidentiality protection, the encoding will be:

{ msg, pad, HMAC, version, seq }

where msg, pad, and HMAC are encrypted, and the padding is sufficient
to make the plaintext a multiple of the block length.

The version is 0x01; the sequence number is four bytes; both are
transmitted in the clear.

Finally, we discussed realms and agreed that Pete Resnick summed up
the discussion pretty well: servers may send a list of realms, and if
they do, the client must pick one of them.  If the server sends no
realms, the client may pick one (via some other agreement).

If the client sends no realm, the server assumes it's the empty
string.

Paul promises a new draft will be coming out just as soon as he can
copy and paste his entire document and the network catches up with
him.  :^) (It's possible I'm confused; I'm sure the techology at
Microsoft is state-of-the-art.)

Larry