[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Simon Josefsson wrote:
4.1. SASL Tokens
All top-level SASL packets for the GS2 mechanism family follow the
following format:
I would suggest avoid using the term SASL packet, as it usually refers to
SASL security layer. Something like "SASL authentication exchange packets"
would be better here.
RFC 4422 seems to use the term "messages" here, so I changed this
into:
<section title="SASL Authentication Exchange Message Format">
<section title="SASL Messages">
<t>All top-level SASL authentication exchange messages for the GS2
mechanism family follow the following format:</t>
Looks good to me.
[...]
The server passes the first client response to GSS_Accept_sec_context
I suggest s/first/initial, as "initial client response" is a SASL term.
GS2 should support a missing "initial client response", so it is
actually the first context token received by the server which should
be used. Does this looks better?
<t>The server passes the first context token to
GSS_Accept_sec_context as input_token, setting
Yes.
At least "first context token" doesn't bring association with "initial
client response".
the chan_binding set to NULL, and acceptor_cred_handle
equal to output_cred_handle from GSS_Acquire_cred called with
desired_name equal to output_name from GSS_Import_name 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.
The text about acceptor_cred_handle got replaced with the following in GS1:
and a suitable acceptor_cred_handle (see below).
and later:
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
GSS-API mechanism for which this SASL mechanism is registered
(*). Servers MAY use
GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY
use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
for the server's principal name(s) (**) and the
GSS-API mechanism for which this SASL mechanism is registered.
(*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
GSS-API mechanism as an input parameter. The OID set can be created
by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can
be freed by calling the GSS_Release_oid_set.
(**) - Use of server's principal names having
GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
where "service" is the service name specified in the protocol's
profile, is RECOMMENDED.
Upon successful establishment of the security context (i.e.
GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
verify that the negotiated GSS-API mechanism is indeed the registered
one. This is done by examining the value of the mech_type
parameter returned from the GSS_Accept_sec_context call. If the
value differ SASL authentication MUST be aborted.
(I've edited the text not to reference Kerberos)
Thanks, this seems good for GS2, but I wonder about the value of this
in GSSAPI. It seems to make my RFC 2222 conforming implementation
violate the first SHOULD. I'll bring this up separately...
In the last paragraph, I changed a SHOULD into MUST, since the last
MUST in that paragraph implies that the first SHOULD is followed.
Actually the second MUST is conditional on the first SHOULD. So I don't
see why the SHOULD has to change into a MUST.
If I remember correctly the SHOULD here is to accommodate
implementations which only support a single GSS-API mechanism.
And the text quoted above is followed by additional text which is not
currently in GS2:
Upon successful establishment of the security context and if the
server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
credential handle, the server SHOULD also check using the
GSS_Inquire_context that the target_name used by the client matches:
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
where "service" is the service name specified in the application
protocol's profile.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
examines the context to ensure that it provides a level of protection
permitted by the server's security policy.
Thanks, I added this, but changed the SHOULD into MUST, because
otherwise it seems we open up to a mitm.
No, the SHOULD is here because the server could have used a specific
principal during GSS_Import_Name. In such case there would be no need to
do the check.
I didn't include this part:
In particular, if the
integ_avail flag is not set in the context, then no security layer
can be offered or accepted. If the conf_avail flag is not set in the
context, then no security layer with confidentiality can be offered
or accepted.
Because I think it interacts badly with the no-integrity cases that
GS2 has to support. This should likely be revisited later on.
I don't understand, can you explain?
[...]
bitmask and local policy.
Four input formats to the GSS_Wrap function are defined.
This is confusing. Maybe "two pairs of input formats"?
I changed it to:
<t>Two pairs of input formats to the GSS_Wrap function are
defined. The first pair is used when the client sends the
GSS_Wrap token first and the server responds. The other pair is
used when the server sends the GSS_Wrap token first and the
client responds.</t>
Looks good.
[...]
4.3.2. GSS_Wrap input for server responses
[...]
The "server_qop" field integer indicate the selected quality of
protection.
I suggest to add:
It must be one of the values specified by the client in
"client_qops"/"client_cbqops"
And similar text for "client_qop" in 4.3.4.
Actually, no. I think it would be useful to be able to specify a
different value, if you can't support any of the proposed values. It
is then up to the other side to reject the selection or not.
I suggest you document this, as this differs from GS1.
The messages is integrity protected, so there is no downgrade attack,
that I can see.
Alexey