Subject: Comment on draft-ietf-cat-sasl-gssapi-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Apr 2001 10:36:18 -0600

1).

>4.    SPNEGO
...
>   Since SASL is capable of negotiating amongst GSSAPI mechansims, the
Typo: mechanisms
>   only reason for a server or client to support the "GSS-SPNEGO"
>   mechanism is to allow a policy of only using mechanisms below a
>   certain strength if those mechanism's negotiation is protected.  In
>   such a case, a client or server would only want to negotiate those
>   weaker mechnisms through SPNEGO.  In any case, there is no down-
Typo: mechanisms
>   negotiation security consideration with using the strongest
mechanism
>   and set of options the implementation supports, so for
>   interoperability that mechanism and set of options MUST be
negotiable
>   without using the "GSS-SPNEGO" mechanism.

2).

> 5.    Base32 encoding
...
>   Special processing is performed if fewer than 40 bits are available
...
>   the data is performed using the "=" character.  Since all base32
>   input is an integral number of octets, only the following cases can
>   arise: (1) the final quantum of encoding input is an integral
>   multiple of 40 bits; here, the final unit of encoded output will be
>   an integral multiple of 4 characters with no "=" padding, (2) the
"multiple of 8 characters"?

>   final quantum of encoding input is exactly 8 bits; here, the final
>   unit of encoded output will be two characters followed by six "="
>   padding characters, (3) the final quantum of encoding input is
>   exactly 16 bits; here, the final unit of encoded output will be four

>   characters followed by four "=" padding characters, (4) the final
>   quantum of encoding input is exactly 24 bits; here, the final unit
of
>   encoded output will be five characters followed by five"=" padding
"will be five characters followed by *three* "=""

>   characters, or (5) the final quantum of encoding input is exactly 32

>   bits; here, the final unit of encoded output will be seven
characters
>   followed by one "=" padding character.
>
>   Because it is used only for padding at the end of the data, the
>   occurrence of any "=" characters may be taken as evidence that the
>   end of the data has been reached (without truncation in transit).
No
>   such assurance is possible, however, when the number of octets
>   transmitted was a multiple of three and no "=" characters are
was a multiple of eight?

>   present.
>
>   Any characters outside of the base32 alphabet are to be ignored in
>   base32-encoded data.

I don't recall whether I've asked this question before, but I don't
understand the intention of the last sentence.
A generator MUST never generate text containing characters outside of
base32 alphabet. Any parser must not crash when parsing invalid input,
this is the question of quality of implementation.

3).

>6.1.  Client side of authentication protocol exchange
>
>   The client calls GSS_Init_sec_context, passing in
...
>   the fully qualified host name of the server.  If the client will be
>   requesting a security layer, it MUST also supply to the
>   GSS_Init_sec_context a mutual_req_flag of TRUE, a
replay_det_req_flag
>   of TRUE,

Your forgot sequencing flag ;-) [sequence_req_flag].

> and an integ_req_flag of TRUE.  If the client will be
>   requesting a security layer providing confidentiality protection, it

>   MUST also supply to the GSS_Init_sec_context a conf_req_flag of
TRUE.

As I wrote earlier, something like the following will completely satisfy
me:

"The client MAY specify other context service indicator flags".

4).

> 6.2.  Server side of authentication protocol exchange
...
>   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
...
>   output_message to the client in a challenge.  The server must then
>   pass the resulting response to GSS_Unwrap and interpret the first
>   octet of resulting cleartext as the bit-mask for the selected
>   security layer, the second through fourth octets as the netowrk byte

Typo: network
>   order maximum size output_message to send to the client, and the
>   remaining octets as the authorization identity.  The server must

Otherwise the document looks good :-).

__________________________________________
Alexey Melnikov - Software Developer
Research and Development
ACI Worldwide (formerly MessagingDirect Ltd.)
phone           780.424.4922 x357
__________________________________________
All opinions are mine only, not of the TSA/ACI!
__________________________________________