[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-sasl-gs2-14
Alexey Melnikov <alexey.melnikov@xxxxxxxxx> writes:
> In general I think the document is in a good shape. I have some minor,
> mostly editorial changes. I don't believe another WGLC would be needed
> after they are addressed.
Thanks for your comments!
> I've already sent a couple of comments to the mailing earlier (See
> <http://www.imc.org/ietf-sasl/mail-archive/msg04104.html> and
> <http://www.imc.org/ietf-sasl/mail-archive/msg04105.html>). Here are
> my remaining comments:
I'll look at these next.
> 1). SCRAM contains the following text about authorization identity,
> which I think is missing from GS2:
>
> Upon the receipt of this value the server verifies its
> correctness according to the used SASL protocol profile.
> Failed verification results in failed authentication exchange.
>
> I think this should also be mentioned in section 7.
I added it to section 4. Section 7 already contains this:
<t>Authorization of client principal (i.e., src_name in
GSS_Accept_sec_context) to requested authzid
failed.</t>
> 2). In Section 3:
>
> If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
> implementation need some other mechanism to map mechanism OIDs to
> SASL name internally. In this case, the implementation can only
> support the mechanisms for which it knows the SASL name. If the
> GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
> cannot map the OID to a SASL mechanism name using some other means,
> it cannot use the particular GSS-API mechanism since it does not know
> its SASL mechanism name.
>
> Is the last sentence still correct? I think this is out of sync with
> section 10, which now says:
>
> The output variable sasl_mech_name will hold the IANA registered
> mechanism name for the GSS-API mechanism, or if none is
> registered, a mechanism named computed from the OID as
> described in section 3.1 of this document.
I think the last sentence is still needed -- consider if the function
returns an error code (e.g., out of memory).
> 3). In section 5:
>
> If the client supports channel binding and the server does not appear
> to (i.e., the client did not see a -PLUS name) then the client MUST
>
> I know this is probably too subtle, but does "a -PLUS name" means "any
> SASL mechanism name ending with -PLUS, even if it is not the same base
> SASL mechanism we are talking about", or "the base SASL mechanism
> name"? I.e. should "a" be "the"?
I agree -- I changed "a" into "the".
> either fail authentication or it MUST chose the non-PLUS mechanism
> name and use a "y" gs2-cb-flag.
>
> [...]
>
> If the client supports channel binding and the server appears to
> support it (i.e., the client see a -PLUS name) then the client MUST
I changed "a" into "the" here too.
> Note that SCRAM also says:
>
> , or if the client wishes to use channel
> binding but the client does not negotiate
> mechanisms
>
>
> use a "p" gs2-cb-flag to indicate the channel binding type it is
> using.
Should this be added? I'm not sure.
> 4). In Section 6: Multiple missing commas in examples.
>
> According to the ABNF:
>
> gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
> ;; The GS2 header is gs2-header.
>
>> Example #2: a one and one half round-trip GSS-API context token
>> exchange, no channel binding.
>>
>> C: Request authentication exchange
>> S: Empty Challenge
>> C: n,<initial context token with standard
>> header removed>
>>
>>
> Should be "C: n,,<initial context token with standard"
Fixed.
>
>> S: Send reply context token as is
>> C: Send reply context token as is
>> S: Outcome of authentication exchange
>>
>> Example #3: a two round-trip GSS-API context token exchange, no
>> channel binding, no standard token header.
>>
>> C: Request authentication exchange
>> S: Empty Challenge
>> C: F,n,<initial context token without
>> standard header>
>>
>>
> C: F,n,,...
Fixed.
>> S: Send reply context token as is
>> C: Send reply context token as is
>> S: Send reply context token as is
>> C: Empty message
>> S: Outcome of authentication exchange
>>
>> Example #5: using channel binding.
>>
>> C: Request authentication exchange
>> S: Empty Challenge
>> C: p=tls-unique,<initial context token with standard
>>
>>
> C: p=tls-unique,,
Fixed.
>> header removed>
>> S: Send reply context token as is
>> ...
>>
>> Example #6: using non-standard channel binding (requires out-of-band
>> negotiation).
>>
>> C: Request authentication exchange
>> S: Empty Challenge
>> C: p=tls-server-end-point,<initial context token with standard
>>
>>
> C: p=tls-server-end-point,,
Fixed.
>> header removed>
>> S: Send reply context token as is
>> ...
>>
>>
> 5). Section 9 says:
>
> There's no requirement that any particular GSS-API name-types be
> used. However, typically SASL servers will have host-based acceptor
> principal names (see [RFC2743] section 4.1) and clients will
> typically have username initiator principal names (see [RFC2743]
> section 4.2).
>
> This might be trivial, but I am missing the following text from RFC 4752:
> ... targ_name equal to output_name from GSS_Import_Name called with
> input_name_type
> of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
> "service@hostname" where "service" is the service name specified in
> the protocol's profile, and "hostname" is the fully qualified host
> name of the server.
>
> So possibly reword this paragraph to read:
>
> There's no requirement that any particular GSS-API name-types be
> used. However, typically SASL servers will have host-based acceptor
> principal names (see [RFC2743] section 4.1) and clients will
> typically have username initiator principal names (see [RFC2743]
> section 4.2). When a host-based acceptor principal name is used
> ("service@hostname"), "service" is the service name specified in
> the protocol's profile, and "hostname" is the fully qualified host
> name of the server.
>
> ?
Nico?
> 6).
>
>> 10.1. gss_inquire_saslname_for_mech
>>
>> The C binding for the GSS_Inquire_SASLname_for_mech call is as
>> follows.
>>
>> OM_uint32 gss_inquire_saslname_for_mech(
>> OM_uint32 *minor_status,
>> const gss_OID desired_mech,
>> gss_buffer_t sasl_mech_name,
>> gss_buffer_t mech_name,
>> gss_buffer_t mech_description,
>
> Do the 3 output parameters need to be freed?
Not sure if this needs to be mentioned, I can't find much discussion in
RFC 2743 on this. Nico?
/Simon