Subject: digest-md5 realm

From: Lawrence Greenfield <[email-masked]>
Date: 29 Jul 1999 17:24:37 -0400

There appears to be a conflict in draft-leach-digest-sasl-03.txt.

In Section 2.1.1, the "realm" is optional and:

  This directive is optional; if not present, the client MUST solicit
  it from the user or have been configured to use a default; a
  plausible default might be the realm supplied by the user when
  they logged in to the client system. Multiple realm directives
  are allowed.

In Section 2.1.2, the "realm" in the response is:
  The realm containing the user's account. It MUST be one of the realms
  from the "digest-challenge", if any were provided. This directive is
  required unless the server did not provide any realms; otherwise, if
  not present, or not one of the ones in the "digest-challenge",
  authentication fails.

This seems to imply that if a realm was not sent with the challenge, a
client need not reply with a realm.

I assume the realm is actually required in the response?

Thanks,
Larry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 15:56:20 -0600

> client need not reply with a realm.

I don't agree. If realm was not sent with the challenge client MUST ask
user to type some realm (I still don't like that the user has no way 
to discover realm format. It would be much better if spec says that 
realm MUST be in the form of FQDN or <group>@<host> format)

This means that SASL API should have Realm callback.

The last phrase of section 2.1.2 is ambiguous. I would rather:

This directive is required unless the server did not provide any 
realms; otherwise, if not present in client response, or not one of the 
ones in the "digest-challenge", authentication fails.

> I assume the realm is actually required in the response?

IMHO, client MUST send any realm to server, because it is used in hash 
calculation.

-------------------
Alexey Melnikov
[email-masked]

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Jul 1999 17:33:28 -0500

That's funny; I just wrote to Paul and Chris about exactly this problem.

>>There appears to be a conflict in draft-leach-digest-sasl-03.txt.
[...]
>>This seems to imply that if a realm was not sent with the 
>>challenge, a client need not reply with a realm.

Yes, this is poorly written and you've got the meaning exactly right.

>I don't agree. If realm was not sent with the challenge client MUST 
>ask user to type some realm...

No. If a realm was not sent, the client can perfectly well answer 
with an empty string, or with no realm at all (which is equivalent to 
the empty string realm).

>>plausible default might be the realm supplied by the user when they 
>>logged in to the client system. Multiple realm directives are 
>>allowed.

This is obviously incorrect. If the realm is not present, the client 
MAY solicit it from the user, use a configured default (for example, 
a realm supplied when the user logged in to the client system), or 
use an empty string for the realm.

>>The realm containing the user's account. It MUST be one of the 
>>realms from the "digest-challenge", if any were provided. This 
>>directive is required unless the server did not provide any realms; 
>>otherwise, if not present, or not one of the ones in the 
>>"digest-challenge", authentication fails.

This is just poorly written. It's the word "otherwise" in that clause 
that screws it up. Replace this with:

The realm containing the user's account. If one or more realms was 
provided in the "digest-challenge", then the realm directive is 
required and the value must be one of the realms from the 
"digest-challenge", or the authentication fails. If no realm was 
provided in the "digest-challenge", then the realm directive is 
optional. If the client does send a realm, it MAY be solicited from 
the user, a configured default (for example, a realm supplied when 
the user logged in to the client system), or an empty string.

>IMHO, client MUST send any realm to server, because it is used in 
>hash calculation.

It can be the empty string. It is not required.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 17:07:28 -0600

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1 b1 Build (1)  -- Evaluation Copy
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"

On Thu, 29 Jul 1999 17:33:28 -0500 Pete Resnick <[email-masked]> 
wrote:

> Yes, this is poorly written

I agree

> and you've got the meaning exactly right.

I don't agree (see below).

> with an empty string, or with no realm at all (which is equivalent to 

"No realm = Empty string realm" has reasonable meaning only if server 
supports empty string realm.

I see other way how client and server should treat "no realm".
For example, server is a proxy authentication server that may connect 
to multiple authentication servers according to realm parameter.
It might be the waste of tarffic to list all realms that server allows 
to connect to (and maybe server can't list them all). In this case 
server doesn't send realm at all.

This is reasonable example from my point of view and I don't want to 
force every server to list all realms.

> use an empty string for the realm.

I don't agree. Client MUST send realm to a server [until we all agree 
that no realm means that it is empty string], because realm is used to 
calculate hash!!! Client MAY request it from user or MAY obtain it from 
another source.

> It can be the empty string. It is not required.

It is REQUIRED to create hash. However it MAY be empty string.
If realm is empty string it should be sent as 'realm=""'.

-------------------
Alexey Melnikov
[email-masked]

---

From: Claus Assmann <[email-masked]>
Date: Thu, 29 Jul 1999 16:23:57 -0700

> supports empty string realm.

IMHO "No realm" != "Empty realm" (see below).

> force every server to list all realms.

Good, because it could be a real big list for MTAs etc
supporting a large set of virtual domains.

> calculate hash!!! Client MAY request it from user or MAY obtain it from 

IMHO the server could fall back to a default realm (e.g. it's FQDN)
if no realm is sent by the client.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Jul 1999 20:48:54 -0500

On 7/29/99 at 4:23 PM -0700, Claus Assmann wrote:

>>This is reasonable example from my point of view and I don't want 
>>to force every server to list all realms.
>
>Good, because it could be a real big list for MTAs etc supporting a 
>large set of virtual domains.

But in this case, there has to be an out-of-band agreement between 
client and server in order for the realm to validate (i.e., it's not 
possible on the wire to know if the chosen realm is legal). So 
perhaps my rewrite of 2.1.2 should be adjusted to:

The realm containing the user's account. If one or more realms was 
provided in the "digest-challenge", then the realm directive is 
required and the value must be one of the realms from the 
"digest-challenge", or the authentication fails. If no realm was 
provided in the "digest-challenge", then the realm directive is 
optional, though the server may still require a realm by some 
out-of-band site policy. In this case, the client MAY solicit the 
realm from the user or use a pre-configured default (for example, a 
realm supplied when the user logged in to the client system). In the 
absence of a realm directive, the realm is the empty string.

I would further rewrite the last part of 2.1.1 to:

This directive is optional. If it is not present, it indicates either 
that no realm needs to be provided by the client (in which case the 
empty string is the realm), or that there is an out-of-band agreement 
between the client and server as to which realm(s) will be accepted.

>if no realm is sent by the client.

I agree with Paul that this is a bad plan. A missing realm should be 
equivalent to an empty string realm. I see no engineering 
justification to make it otherwise.

pr

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 15:56:20 -0600

-------------------
Alexey Melnikov
[email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Jul 1999 17:33:28 -0500

[...]

pr

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 17:07:28 -0600

I agree

-------------------
Alexey Melnikov
[email-masked]

---

From: Claus Assmann <[email-masked]>
Date: Thu, 29 Jul 1999 16:23:57 -0700

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Jul 1999 20:48:54 -0500

pr

Date: Thu, 29 Jul 1999 20:48:54 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: digest-md5 realm
Sender: [email-masked]

pr

From: "Paul Leach (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: digest-md5 realm
Date: Thu, 29 Jul 1999 16:46:49 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Claus Assmann [mailto:[email-masked]]
> 

This won't work (in general). The realm used in the hash has to be exactly
the same by the client and the server, otherwise it won't check. If the
client uses a realm value, it might as well send it.

Paul

From: [email-masked]
Date: Thu, 29 Jul 1999 16:35:02 -0700
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Importance: normal
Subject: cc:Mail Link to SMTP Undeliverable Message: Unknown user: Angela Liang
Sender: [email-masked]

From: "Paul Leach (Exchange)" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, Pete Resnick <[email-masked]>
Cc: Lawrence Greenfield <[email-masked]>, [email-masked], Chris Newman <[email-masked]>
Subject: RE: digest-md5 realm
Date: Thu, 29 Jul 1999 16:23:12 -0700
Sender: [email-masked]

No realm in digest-response means to use the empty string in the calculation
of the hash.

If the server does not hold the empty string realm, then it MAY send a list
of the realms it does hold. However, the empty string realm is no different
in this respect than any other realm -- if the server does not send a list
of realms, then the client could choose a realm that the server doesn't
hold, in which case the authentication will just fail.

Paul

Date: Thu, 29 Jul 1999 16:23:57 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: digest-md5 realm
Reply-To: [email-masked]
Sender: [email-masked]

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 17:07:28 -0600
To: Pete Resnick <[email-masked]>
Subject: Re: digest-md5 realm
Cc: Alexey Melnikov <[email-masked]>, Lawrence Greenfield <[email-masked]>, [email-masked], Paul Leach <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

I agree

-------------------
Alexey Melnikov
[email-masked]

Date: Thu, 29 Jul 1999 17:33:28 -0500
To: Alexey Melnikov <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: digest-md5 realm
Cc: Lawrence Greenfield <[email-masked]>, [email-masked], Paul Leach <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

[...]

pr

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 1999 15:56:20 -0600
To: Lawrence Greenfield <[email-masked]>
Subject: Re: digest-md5 realm
Cc: [email-masked]
Sender: [email-masked]

-------------------
Alexey Melnikov
[email-masked]

Date: 29 Jul 1999 17:24:37 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: digest-md5 realm
Sender: [email-masked]

Thanks,
Larry

Date: Tue, 27 Jul 1999 14:07:45 -0700
To: "RL 'Bob' Morgan" <[email-masked]>, Pete Resnick <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: SMTP Auth, etc., support
Cc: [email-masked]
Sender: [email-masked]

>Which list is that, so those of who missed it can review the archive?

It happened on the [email-masked] list BUT THE DISCUSSION SHOULD 
MOVE HERE. That list was the wrong place for the discussion, and I've asked 
all parties to move it to here (Pete is the only one who has done so so 
far). I expect the other parties to show up here any time now.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jul 1999 15:10:54 -0600
To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: SMTP Auth, etc., support
Cc: [email-masked]
Sender: [email-masked]

On Tue, 27 Jul 1999 20:59:00 +0000 (   ) RL 'Bob' Morgan 
<[email-masked]> wrote:

> 
> > There has been a discussion going on about SMTP AUTH deployment over 
> > on one of the IMC lists. It seemed more appropriate to bring it over 
> > here.
> 
> Which list is that, so those of who missed it can review the archive?

List address is : [email-masked]
Send request to <[email-masked]> to subscribe
You can find archive at 
"http://www.imc.org/imc-mailconnect/mail-archive/"
-------------------
Alexey Melnikov
[email-masked]

Date: Tue, 27 Jul 1999 16:06:37 -0500
To: "RL 'Bob' Morgan" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SMTP Auth, etc., support
Cc: [email-masked]
Sender: [email-masked]

On 7/27/99 at 8:59 PM +0000, RL 'Bob' Morgan wrote:

>Which list is that, so those of who missed it can review the archive?

It's imc-mailconnect. The archive is at:

<http://www.imc.org/imc-mailconnect/mail-archive/>

pr

Date: Tue, 27 Jul 1999 20:59:00 +0000 (   )
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: SMTP Auth, etc., support
Sender: [email-masked]

> There has been a discussion going on about SMTP AUTH deployment over 
> on one of the IMC lists. It seemed more appropriate to bring it over 
> here.

Which list is that, so those of who missed it can review the archive?

 - RL "Bob"

Date: Mon, 26 Jul 1999 20:39:17 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: SMTP Auth, etc., support
Sender: [email-masked]

There has been a discussion going on about SMTP AUTH deployment over 
on one of the IMC lists. It seemed more appropriate to bring it over 
here.

Basically, it turns out that several of the SASL mechanisms currently 
deployed for SMTP AUTH have not been registered with IANA. These 
include:

LOGIN
PLAIN
DPA
NTLM

and a few that have Internet Drafts out now. Alexey Melnikov 
<[email-masked]> has been kind enough to put up 
a web page of current mechanisms and where they are documented at 
<http://www.demo.ru/homerus/mail/Sasl_info.html>.

I have volunteered to document and register LOGIN with Mark Crispin's 
help. The MS Outlook Express implementation may have something that 
needs to be added to the document, since it appears to like only 
particular challenges (JGM).

Chris Newman is going to ping IANA about PLAIN.

We are waiting for word from MS about DPA and NTLM.

Anyone have anything else to add?

pr

Date: Tue, 20 Jul 1999 09:15:06 -0400 (Eastern Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: [email-masked]
Subject: New version of draft-nystrom-securid-sasl-0X.txt available
Sender: [email-masked]

FYI,

A new draft version of the above I-D is now available at, e.g. ietf.org.
Comments and feedback is welcome and solicited.

Thanks,
-- Magnus

Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000

From: Paul Leach <[email-masked]>
To: "'Tony Hansen'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: small typo in draft-leach-digest-sasl-03.txt and some questio ns
Date: Fri, 9 Jul 1999 10:09:46 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: Tony Hansen [mailto:[email-masked]]
> Sent: Thursday, July 08, 1999 10:04 PM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]'
> Subject: Re: small typo in draft-leach-digest-sasl-03.txt and some
> questions

> I have a feeling that many implementations will get this wrong and it
> would be worth simplifying things now before we get much further. The
> simplification I have in mind is of course to "allow any name 
> value-pair
> to be quoted". It makes code, maintenance and the protocol description
> much simpler, all around.

That would make it incompatible with HTTP's Digest, which is a proposed
standard.

People who can't read BNF shouldn't implement protocols.

It also doesn't make the spec simpler -- since the value parts of AV pairs
are currenlty typed, we'd have to have one new AV pair type for each current
value type.

Paul

Date: Fri, 09 Jul 1999 01:03:41 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Paul Leach <[email-masked]>
CC: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: small typo in draft-leach-digest-sasl-03.txt and some questions
Sender: [email-masked]

Paul Leach wrote:
> 
> > From: Tony Hansen [mailto:[email-masked]]
> >
> > Are all name=value pairs permitted to have quotation marks around the
> > value?
> 
> That wasn't the intent. Only ones that need it because they might contain
> stuff that needs to be quoted.
> 
> > For example, can you write
> >
> >       nc="3"
> 
> Nope.
> 
> ...
> In my implementation, following the "be conservative in what you send and
> liberal in what you accept" rule, I'd probably allow any name value-pair to
> be quoted, and log something. But the spec clearly doesn't allow it.

I have a feeling that many implementations will get this wrong and it
would be worth simplifying things now before we get much further. The
simplification I have in mind is of course to "allow any name value-pair
to be quoted". It makes code, maintenance and the protocol description
much simpler, all around.

	Tony Hansen
	[email-masked]

Date: Thu, 08 Jul 1999 19:31:44 +0400
From: Alexey Melnikov <[email-masked]>
To: SASL mailing list <[email-masked]>
Subject: Other DIGEST-MD5 issues
Sender: [email-masked]

I've discussed UTF-8 to ISO-8859-1 conversion ambiguity with Chris
Newman:

-------- Original Message --------
Subject: Re: Some comments about DIGEST-MD5
Date: Thu, 10 Jun 1999 16:15:02 -0700 (PDT)
From: Chris Newman <[email-masked]>
To: Alexey Melnikov <[email-masked]>

On Fri, 11 Jun 1999, Alexey Melnikov wrote:
> This text says that you have to convert both UserName and Password into
> 8859-1
> if and only if both UserName and Password are both in 8859-1 character
> set.

That text is bogus, IMHO.  I have no intention of changing my code.

		- Chris

Date: 7 Jul 1999 22:07:21 -0400
From: Lawrence Greenfield <[email-masked]>
To: Paul Leach <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: DIGEST-MD5 SASL mechanism?
Sender: [email-masked]

   [...]
   However, I take your point. I'll admit I was loose with the terminology --
   it would have been more accurate to be something like the "MAC trailer"
   which is the pad, version, MAC, and sequence number.

I guess I sometimes have enough problems understanding these
specifications without the little confusions.

   [...] current:
   > SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
   >       SeqNum, msg)
   > CMAC(Ki, Kc, SeqNum, msg) =
   >     { 0x0001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..9]), SeqNum }
   > 
   > Of course, the 10 byte HMAC prefix is not a multiple of the 8 byte DES
   > block.

   [... my suggestion deleted ....]
   The simplest change is just to make the size of the pad big enough to (msg +
   10) (10 being the size of HMAC output) be a multiple of the block size.

   The reason for preferring the simplest change is that the DIGEST-SASL
   mechanism is holding up the LDAP RFCs.

While this could work with silly enough coding, I don't think that
this is really what we want.  Let's see what would come over the wire:

ciphertext 0x0001 ciphertext SeqNum
{msg,pad}         {pad,HMAC}

This means, in order to decrypt using a block cipher, I'll have to
extract the ciphertext corresponding to {msg,pad}, extract the
ciphertext corresponding to {pad,HMAC}, concatenate the two, perform
the decryption, take the last 10 bytes for the HMAC, and the remaining
non-pad bytes corresponding to the msg.  This seems overly complex.

If we could go:
{ msg, HMAC, pad, version, SeqNum }
  ----encrypt----
   
that would work.  Then it's also clear that I don't use the padding to
generate the checksum.

Another possible solution makes me ask this ignorant
question---perhaps it is obvious: why is the HMAC encrypted?

Larry

From: Paul Leach <[email-masked]>
To: "'Tony Hansen'" <[email-masked]>, [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: small typo in draft-leach-digest-sasl-03.txt and some questio ns
Date: Wed, 7 Jul 1999 17:12:45 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: Tony Hansen [mailto:[email-masked]]
> Sent: Monday, June 14, 1999 11:30 AM
> To: Paul Leach; [email-masked]
> Subject: small typo in draft-leach-digest-sasl-03.txt and 
> some questions
> 
> 
> qdstrval -> qdstr-val

Thanks for catching that.

> 
> Are all name=value pairs permitted to have quotation marks around the
> value?

That wasn't the intent. Only ones that need it because they might contain
stuff that needs to be quoted.

> For example, can you write 
> 
> 	nc="3"

Nope.

> If so, I don't see it from the ABNF.

That's why you don't see it.

> 
> Along a similar vein, I don't see how the qop-spec shown in 
> the example
> 
> 	qop="auth"
> 
> can be produced from the ABNF. (The ABNF lists 
> 
>         qop              = "qop" "=" qop-value
> 
> but qop-value doesn't have quotes around them, since qop-value is also
> used in qop-list within qop-options, which explicitly shows 
> the quotes.)

Yup, it's a bug in the example. Good catch.

In my implementation, following the "be conservative in what you send and
liberal in what you accept" rule, I'd probably allow any name value-pair to
be quoted, and log something. But the spec clearly doesn't allow it.

Paul

From: Paul Leach <[email-masked]>
To: "'Lawrence Greenfield'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: DIGEST-MD5 SASL mechanism?
Date: Wed, 7 Jul 1999 15:48:55 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Wednesday, July 07, 1999 1:20 PM
> To: Paul Leach
> Cc: [email-masked]'
> Subject: Re: DIGEST-MD5 SASL mechanism?
> 
> 
> [...]
>    > 
>    > - the MAC is defined including the "variable length 
> padding prefix",
>    >   but the padding is treated as part of the message.
> 
>    No, it is just encrypted with the message, it isn't part 
> of the message. The
>    MAC for encrypted messages is the padding concatenated 
> with the MAC for
>    unencrypted messages.
> 
> This really doesn't make sense.  A "MAC" is a message authentication
> code; padding is not part of the message authentication.

If I wanted to be technical: sure it is, in the sense that if the pad bytes
contain the incorrect value, the MAC won't check. However, it indeed isn't a
traditional MAC such as HMAC or keyed MD5.

However, I take your point. I'll admit I was loose with the terminology --
it would have been more accurate to be something like the "MAC trailer"
which is the pad, version, MAC, and sequence number.

> 
> Further, you don't cover what happens if the HMAC length is not a
> multiple of the cipher blocksize.

Duh. Oops. Drat. Good catch.

> 
> draft 03 specifies the encryption as follows:
> 
> SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
>       SeqNum, msg)
> CMAC(Ki, Kc, SeqNum, msg) =
>     { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum }
> 
> From your message, I've corrected this to:
> 
> SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
>       SeqNum, msg)
> CMAC(Ki, Kc, SeqNum, msg) =
>     { 0x0001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..9]), SeqNum }
> 
> Of course, the 10 byte HMAC prefix is not a multiple of the 8 byte DES
> block.

Someone made me change it; it used to be 8 bytes. That's when the version
number was 4 bytes. And everything worked -- but there was an objection that
the MAC wasn't long enough.
(Of course, it's still true that we'd be screwed with any cipher with a
block size longer than 8 bytes.)

> 
> I would propose encoding instead as follows:
> 
> SEAL(Ki, Kc, SeqNum, msg) = 
>    CIPHER(Kc, { msg, pad, CMAC(Ki, SeqNum, msg) } )
> 
> CMAC(Ki, SeqNum, msg) =
>    { 0x0001, HMAC(Ki, (SeqNum, msg))[0..9], SeqNum }
> 
> where pad is 1 or more bytes containing the amount of padding needed
> to make msg + CMAC be a multiple of the block size.

The simplest change is just to make the size of the pad big enough to (msg +
10) (10 being the size of HMAC output) be a multiple of the block size.

The reason for preferring the simplest change is that the DIGEST-SASL
mechanism is holding up the LDAP RFCs.

> 
> Is there a reason that the sequence number and version field were left
> unencrypted?  In order to minimize the amount of easy cribs?

Although not decribed, the same basic algorithm works for packet flows which
can be recieved out of order (because they are sent over UDP or because of
multiplexing a single TCP connection, as the HTTP/NG folks have talked about
doing. Stream ciphers are problematic in this case. To accomodate them, when
handling out-of-order delivery, each packet, instead of using Ke for the
encryption key, uses HMAC(Ke, SeqNum). This requires the SeqNum to be in the
clear.

The version number beng in the clear is a holdover from an existing protocol
with which I have experience which I thought would be useful to leave in the
clear. The idea it could affect the decryption somehow in future versions,
or indicate different MAC, or that rekeying was needed after a certain
amount of traffic. However, I agree that it's not so important.

Paul

Date: 7 Jul 1999 16:19:39 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: DIGEST-MD5 SASL mechanism?
Sender: [email-masked]

[...]
   > 
   > - the MAC is defined including the "variable length padding prefix",
   >   but the padding is treated as part of the message.

   No, it is just encrypted with the message, it isn't part of the message. The
   MAC for encrypted messages is the padding concatenated with the MAC for
   unencrypted messages.

This really doesn't make sense.  A "MAC" is a message authentication
code; padding is not part of the message authentication.

Further, you don't cover what happens if the HMAC length is not a
multiple of the cipher blocksize.

draft 03 specifies the encryption as follows:

SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
      SeqNum, msg)
CMAC(Ki, Kc, SeqNum, msg) =
    { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum }

>From your message, I've corrected this to:

SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
      SeqNum, msg)
CMAC(Ki, Kc, SeqNum, msg) =
    { 0x0001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..9]), SeqNum }

Of course, the 10 byte HMAC prefix is not a multiple of the 8 byte DES
block.

I would propose encoding instead as follows:

SEAL(Ki, Kc, SeqNum, msg) = 
   CIPHER(Kc, { msg, pad, CMAC(Ki, SeqNum, msg) } )

CMAC(Ki, SeqNum, msg) =
   { 0x0001, HMAC(Ki, (SeqNum, msg))[0..9], SeqNum }

where pad is 1 or more bytes containing the amount of padding needed
to make msg + CMAC be a multiple of the block size.

Is there a reason that the sequence number and version field were left
unencrypted?  In order to minimize the amount of easy cribs?

Larry

From: Paul Leach <[email-masked]>
To: "'Lawrence Greenfield'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: DIGEST-MD5 SASL mechanism?
Date: Tue, 6 Jul 1999 10:06:08 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Sunday, July 04, 1999 7:00 PM
> To: [email-masked]
> Subject: DIGEST-MD5 SASL mechanism?
> 
> 
> Hi,
> 
> I'm attempting to clean up our implementation of DIGEST-MD5, and have
> some questions that I'm unable to answer from
> draft-leach-digest-sasl-03.txt.  I was wondering if anyone else has
> attempted to implement this or has thought about it.
> 
> Specifically, I'm wondering about how to correctly implementing
> privacy protection with block ciphers such as DES or 3DES and other
> issues related to privacy and integrity protection.
> 
> The text I'm having trouble with is quoted below.
> 
> There appear to be several ambiguities in this:
> 
> - a "2-byte message type number" conflicts with "0x00000001"

Sorry -- didn't update the example when changing the spec. Should be
"0x0001"

> 
> - the MAC is defined including the "variable length padding prefix",
>   but the padding is treated as part of the message.

No, it is just encrypted with the message, it isn't part of the message. The
MAC for encrypted messages is the padding concatenated with the MAC for
unencrypted messages.

> 
> - the padding  appears to be ambigious.  it is impossible to
>   determine upon receipt of the message whether padding was or was not
>   inserted versus a message that happened to end with something that
>   looked like padding.

There is always at least 1 pad byte: "the padding prefix is one or more
octets each containing the number of padding bytes". I tried to not have any
extra padding if the message happened to be a multiple of the cipher
blocksize, but couldn't figure out a way.
 
> 
> - it is unclear whether the encipherment of the {msg,pad} should be
>   done before or after the encipherment of the HMAC.

Before.  The definition in section 2.4 is
    SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
SeqNum, msg)

So, the CIPHER happens before the CMAC.

> 
> Thanks,
> Larry
> 
> ----
> [from section 2.4]
> 
>    The MAC is a variable length padding prefix followed by 16 bytes
>    formatted as follows: a 2-byte message type number in 
> network byte order
>    with value 1, the first 10 bytes of the HMAC-MD5 [RFC 2104] of the
>    message and the 4-byte sequence number in network byte 
> order. If the
>    blocksize of the chosen cipher is not 1 byte, the padding 
> prefix is one
>    or more octets each containing the number of padding bytes 
> such that
>    length of the message plus the length of the padding prefix is a
>    multiple of the blocksize.
> 
>    SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
>          SeqNum, msg)
>    CMAC(Ki, Kc, SeqNum, msg) =
>        { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, 
> msg))[0..7]), SeqNum }
> 

Date: 4 Jul 1999 22:00:04 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: DIGEST-MD5 SASL mechanism?
Sender: [email-masked]

Hi,

I'm attempting to clean up our implementation of DIGEST-MD5, and have
some questions that I'm unable to answer from
draft-leach-digest-sasl-03.txt.  I was wondering if anyone else has
attempted to implement this or has thought about it.

Specifically, I'm wondering about how to correctly implementing
privacy protection with block ciphers such as DES or 3DES and other
issues related to privacy and integrity protection.

The text I'm having trouble with is quoted below.

There appear to be several ambiguities in this:

- a "2-byte message type number" conflicts with "0x00000001"

- the MAC is defined including the "variable length padding prefix",
  but the padding is treated as part of the message.

- the padding  appears to be ambigious.  it is impossible to
  determine upon receipt of the message whether padding was or was not
  inserted versus a message that happened to end with something that
  looked like padding.

- it is unclear whether the encipherment of the {msg,pad} should be
  done before or after the encipherment of the HMAC.

Thanks,
Larry

----
[from section 2.4]

   The MAC is a variable length padding prefix followed by 16 bytes
   formatted as follows: a 2-byte message type number in network byte order
   with value 1, the first 10 bytes of the HMAC-MD5 [RFC 2104] of the
   message and the 4-byte sequence number in network byte order. If the
   blocksize of the chosen cipher is not 1 byte, the padding prefix is one
   or more octets each containing the number of padding bytes such that
   length of the message plus the length of the padding prefix is a
   multiple of the blocksize.

   SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
         SeqNum, msg)
   CMAC(Ki, Kc, SeqNum, msg) =
       { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum }