Subject: Comments on draft-burdis-cat-srp-sasl-04

From: [email-masked]
Date: Mon, 7 May 2001 17:53:15 -0700 (PDT)

-There is no way for the server to say "You must negotiate a security layer" (i.e. you may negotiate a encryption or integrity layer but not no layer). I propose adding an option like "cleartext=false" to the options string.

-There is no way for the client and server to negotiate a max buffer size for the integrity/encryption layers (DIGEST-MD5, KERBEROS_V4, and GSSAPI all have this capability)

-What should the server use as it's authorization identity if it is the same as the authentication identity? Empty string or the authid? There should be one right way to do it spelled out in the spec to avoid interopability problems.

-In section 4.5 there is an extra paren at the end of the line
"bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )))"

-There should be a section 4.7 to wrap up the discussion of the authentication and give implementors that warm fuzzy feeling that they're done :) Also, this section should say something about the client and server send nothing for the remaining steps.

-Section 5.2 gives no details about the wire format of the sequence number q. I assume it's 4 bytes in network byte order?

-The last word in 5.3 should be something besides "exchange". Maybe "connection"?

-I found section 5.3 kinda unclear in general. I took me a couple readings to realize you re-initialize the hmac with K each time (not once in the beggining or something). Some clarification here couldn't hurt.

-Section 5.4 ends with the word "or". Presumably this wasn't intended.

-I think section 6 (the example) would be more useful if it also contained the exchange base64 decoded to ascii for easy reading.

Thanks,
Tim

---

From: Keith Burdis <[email-masked]>
Date: Tue, 08 May 2001 18:41:55 +0200

Quoting [email-masked]:

> -There is no way for the server to say \"You must negotiate a security
> layer\" (i.e. you may negotiate a encryption or integrity layer but not
> no layer). I propose adding an option like \"cleartext=false\" to the
> options string.

This is a valid point. However, I think that \"cleartext=false\" would only imply 
that encryption is necessary, since using only integrity protection will still 
involve transmiting cleartext data. Perhaps we could include a \"mandatory\" 
option, so the server could send:

  \"mandatory=integrity,mandatory=confidentiality\"

or just:

  \"mandatory=integrity\"

for example. It doesn\'t make sense for a client to send this option since it is 
only able to choose options that the server makes available. Of course it can 
choose to abort the connection if the server does not offer an option that it 
requires.

> -There is no way for the client and server to negotiate a max buffer
> size for the integrity/encryption layers (DIGEST-MD5, KERBEROS_V4, and
> GSSAPI all have this capability)

This could be handled by a \"maxbuffersize\" option. The server sends its maximum 
buffer size as \"maxbuffersize=???\". The client may send this option with a 
value smaller than or equal to this size. If the client doesn\'t send the option 
then it is assumed that the server\'s maxbuffersize is being used. Of course, 
the specified buffer sizes can not be greater than the maximum sizes already 
specified in the draft. Should we specify a default maxbuffersize that is used 
when the server does not specify this option, or should we make the option 
mandatory? If we specify a default the value then the client could send this 
option with a value less than or equal to the default, even if the server 
doesn\'t send this option. I\'d go for making the option mandatory.

> -What should the server use as it\'s authorization identity if it is the
> same as the authentication identity? Empty string or the authid? There
> should be one right way to do it spelled out in the spec to avoid
> interopability problems.

Agreed. I\'d be inclined to say the client should explicitly state that the 
authorisation identity is the same as the authentication identity, if it wishes 
this to be so.

> \"bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )))\"

Okay. We\'ll fix that.

> -There should be a section 4.7 to wrap up the discussion of the
> authentication and give implementors that warm fuzzy feeling that
> they\'re done :) Also, this section should say something about the client
> and server send nothing for the remaining steps.

Hmm. I like the idea of warm and fuzzy users :-) but I am not sure what you 
mean by \"the client and server send nothing for the remaining steps\" ?
After authentication the client and server exchange protocol data, perhaps 
filtered through a security layer. Perhaps stating this wouldn\'t be a bad idea.

> -Section 5.2 gives no details about the wire format of the sequence
> number q. I assume it\'s 4 bytes in network byte order?

Section 2 states \"All data is encoded and sent in network byte order (big-
endian)\". The introduction to section 5 states \"q is a four-octet scalar 
quantity representing a sequence number\". Scalars are described in section 3.1.

> -The last word in 5.3 should be something besides \"exchange\". Maybe
> \"connection\"?

\"connection\" sounds good.
 
> -I found section 5.3 kinda unclear in general. I took me a couple
> readings to realize you re-initialize the hmac with K each time (not
> once in the beggining or something). Some clarification here couldn\'t
> hurt.

It would appear so. In our implementation we initialise the hmac with K once in 
the beginning when we create the security layer (Java input and output streams).

> -Section 5.4 ends with the word \"or\". Presumably this wasn\'t intended.

Indeed it wasn\'t. Well spotted.

> -I think section 6 (the example) would be more useful if it also
> contained the exchange base64 decoded to ascii for easy reading.

Sounds reasonable. Another possibility would be to include an ACAP example, 
like RFC2831 does, since it doesn\'t base64 encode the protocol data.

> Tim

Thanks very much for your input. One point to note is that the use of options 
as name=value pairs was Tim\'s idea. It has proven to be much better than the 
original bit string I proposed, as can be seen by the flexibility of easily 
adding the above features.

  - Keith
--
Keith Burdis                        
---

---

From: Keith Burdis <[email-masked]>
Date: Tue, 08 May 2001 18:41:55 +0200

or just:

  \"mandatory=integrity\"

Okay. We\'ll fix that.

 

  - Keith
--
Keith Burdis                        
---