[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-sasl-gs2-14
Tom Yu wrote:
This message commences a WG Last Call on the following Internet-Draft:
Title : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
Author(s) : S. Josefsson, N. Williams Filename :
draft-ietf-sasl-gs2-14.txt Pages : 23 Date : 2009-06-27 This Last Call
will expire on 03 August 2009. This document is intended for the
Standards Track. Please review this document and send technical
feedback to the WG mailing list, and editorial comments to the authors.
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.
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:
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.
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.
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"?
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
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.
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"
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,,...
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,,
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,,
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.
?
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?