for the WG's review.
a secdir review and my answers.
--- Begin Message ---
Topics:
Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
[secdir] secdir review of draft-ietf-abfab-gss-eap-08
--- End Message ---
--- Begin Message ---
[Stephen, I have a new draft ready.
I think we'll still need to ask the WG about the escaping issue, but
should I publish?]
>>>>> "Jeffrey" == Jeffrey Hutzelman <[email protected]> writes:
Jeffrey> ========================================
Jeffrey> Section 3.1 discusses the format of the GSS-API Mechanism Names
(MNs)
Jeffrey> used by the family of mechanisms defined in this document.
However, it
Jeffrey> sort of glosses over the notion that, in GSS-API jargon,
"Mechanism Name"
Jeffrey> means a name of an initiator or acceptor in a mechanism-specific
format,
Jeffrey> and _not_ the name of a mechanism, as one might otherwise assume.
I
Jeffrey> suggest the following change to the first paragraph of this
section:
Jeffrey> OLD:
Jeffrey> Before discussing how the initiator and acceptor names are
validated
Jeffrey> in the AAA infrastructure, it is necessary to discuss what
composes a
Jeffrey> name for an EAP GSS-API mechanism. GSS-API permits several
types of
Jeffrey> generic names to be imported using GSS_Import_name(). Once a
Jeffrey> mechanism is chosen, these names are converted into a mechanism
name
Jeffrey> form. This section first discusses the mechanism name form and
then
Jeffrey> discusses what name forms are supported.
Jeffrey> NEW:
Jeffrey> Before discussing how the initiator and acceptor names are
validated
Jeffrey> in the AAA infrastructure, it is necessary to discuss what
composes a
Jeffrey> name for an EAP GSS-API mechanism. GSS-API permits several
types of
Jeffrey> generic names to be imported using GSS_Import_name(). Once a
Jeffrey> mechanism is chosen, these names are converted into a
Jeffrey> mechanism-specific name form, called a "Mechanism Name". Note
that a
Jeffrey> Mechanism Name is the name of an initiator or acceptor, not the
name
Jeffrey> of a mechanism. This section first discusses the mechanism
name form
Jeffrey> and then discusses what name forms are supported.
Jeffrey> ----------------------------------------
I like this change.
Jeffrey> At the end of section 3.1, you write "Mechanisms MAY support the
Jeffrey> GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form", but not how names of
this form
Jeffrey> should be converted to GSS-EAP MNs. This results in ambiguities
and also
Jeffrey> some potential for unexpected results, including importing invalid
names.
Jeffrey> Some Kerberos principal names will be invalid as EAP-GSS MNs,
particularly,
Jeffrey> those using principal name forms which contain at-signs or realm
name forms
Jeffrey> contianing slashes (the latter are not likely to be a practical
problem,
Jeffrey> but the former might be). Others will be interpreted not as
intended, or
Jeffrey> may not be appropriate transformations (for example, user
"instances" with
Jeffrey> multiple principal name components).
Jeffrey> To address this, I would recommend the following:
Jeffrey> 1) Introduce an escaping syntax, such as the use of backslash as
in
Jeffrey> RFC1964 section 2.1.1, to allow representation of
name-strings which
Jeffrey> contain slash and at-sign characters.
I think we discussed this between IETF 79 and IETF 80.
However I'd appreciate feedback from the abfab chairs on whether we
already discussed this and on polling the WG if we did not.
Jeffrey> 3) Warn that direct import of Kerberos principal names may have
Jeffrey> unintended effects due to differences in name structure, and
that this
Jeffrey> feature, if implemented, should be used carefully (possibly
disabled
Jeffrey> by default).
Jeffrey> As an alternative to (1), you could continue to simply prohibit
names
Jeffrey> containing slashes and at-signs as parts of name-strings. In
this case,
Jeffrey> implementations which support import of
GSS_KRB5_NT_KRB5_PRINCIPAL_NAME
Jeffrey> names MUST verify that the imported name is valid and otherwise
fail the
Jeffrey> import.
I've added text noting there are difference and indicating that import
SHOULD fail if the name is not syntactically valid.
That's a SHOULD to give mechanisms flexibility if they have some
particular cleanup they want to apply to make some application work.
Jeffrey> ----------------------------------------
Jeffrey> I am a bit confused by section 3.2. You seem to be saying that the
Jeffrey> representation of names and components of names transported in
other
Jeffrey> protocols is up to the protocol in question, but that the
representation
Jeffrey> when a name is sent as part of this protocol is UTF-8. However,
the ABNF
Jeffrey> in section 3.1 permits only characters up to 0xff. Is it the
intent that
Jeffrey> MNs be treated as UTF-8 strings? If so, it would be better to
specify the
Jeffrey> MN form in two laters, first indicating that it is a UTF-8 string
and then
Jeffrey> using ABNF to define the permitted sequences of Unicode characters.
I disagree. I find the current construction easier to follow and would
rather not make this change.
Jeffrey> ----------------------------------------
Jeffrey> Why define a family of mechanisms parameterized by enctype,
instead of
Jeffrey> defining a single mechanism, specifying a mandatory-to-implement
enctype,
Jeffrey> and negotiating the enctype to be used as part of context
establishment?
Jeffrey> This would also work around a situation with SASL mechanism
naming, which
Jeffrey> is that you are effectively defining an entire family of GSs-API
mechs but
Jeffrey> specifying SASL mechanism names for only one member of that
family. This
Jeffrey> means that either other enctypes cannot be used at all, or else
they must
Jeffrey> forever have non-friendly names encoded as per RFC5801 section 3.1.
Jeffrey> Alternately, you could register a family of SASL mechansim names,
of the
Jeffrey> form EAP-<enc> and EAP-<enc>-PLUS, where <enc> is a numeric
enctype. This
Jeffrey> is a bit uglier than EAP-AES128[-PLUS], but prevents future
Jeffrey> interoperability problems due to SASL mechanism name mismatches
and at
Jeffrey> least is reversible, unlike the RFC5801 section 3.1 encoding.
I think this one is informed WG consensus. One reason to do things as we
have is that you run into an interop problem if policy or algorithm
evolution ever disables a mandatory enctype.
I think the implications have been discussed.
Since the SASL registry is FCFS, I don't see a problem with having to
register each enctype separately to get a friendly name.
Jeffrey> ----------------------------------------
Jeffrey> In section 5.4, may the acceptor's message include a vendor
subtoken?
Well, if it does, the initiator is required by this spec to ignore it.
Jeffrey> ----------------------------------------
Jeffrey> In section 5.5, what is a "protected result indication" ?
An EAP term.
Meaning you have cryptographic verification of whether the EAP method
succeded or failed.
Jeffrey> ----------------------------------------
Jeffrey> Is it possible for the Extensions state to involve more than one
round trip?
Not in this specification.
You could of course add an extension advertized either in the initial
or extensions state permitting that.
So we can get that in the future if we need it, but I see no reason for
the complexity now.
Jeffrey> ----------------------------------------
Jeffrey> In section 5.6.1, initiators should be REQUIRED to send zeros for
all flag
Jeffrey> bits other than GSS_C_MUTUAL_FLAG, in order to guarantee that
these bits
Jeffrey> are available for future extension.
Yep, thanks.
Jeffrey> ----------------------------------------
Jeffrey> The MIC token described in section 5.6 currently protects only the
Jeffrey> extension token containing it. Is there any value to protecting
the entire
Jeffrey> context establishment exchange?
This was extensively discussed in the WG.
We went through a couple of different protocols and implementations
here.
This is where we ended up.
Yes, there is value in protecting the exchange, but the state required
to do that simply with RFC 3961 operations gets messy.
For many of the same reasons we made a similar change in RFC 6113, we
went with what we have here.
Jeffrey> ----------------------------------------
Jeffrey> In section 6, the descriptions of the derivation of the GMSK and
CRK
Jeffrey> seem incomplete. In particular...
Jeffrey> - What happens if the EAP master session key is not large enough to
Jeffrey> satisfy the requirements of the GMSK enctype's
Jeffrey> random-to-key?
I'm fairly sure for existing RFC 3961 enctypes and for existing
key-deriving EAP methods, that never happens.
For completness I've added a requirement that in this case
authentication MUST fail.
Jeffrey> - What is the CRK enctype?
The GMSK enctype.
Jeffrey> - I think you mean to indicate that the CRK is the result of
applying
Jeffrey> the CRK enctype's random-to-key to the output of the indicated
truncate
Jeffrey> call. A mere string of random bits is not an RFC3961 protocol
key.
Jeffrey> - The definition of L is garbled. I think you mean it is the
length of
Jeffrey> data required by the CRK enctype's random-to-key.
I do for all of these.
Fixing.
Jeffrey> ----------------------------------------
Jeffrey> It is frequently important to GSS-API initiators that they are
talking to
Jeffrey> the expected acceptor. In the present mechanism, that requires
not only
Jeffrey> verifying the acceptor/NAS's identity with the EAP server (by
means of EAP
Jeffrey> channel bindings), but also verifying that the verified NAS
identity agrees
Jeffrey> with the GSS-API target name provided by the initiating
application, if
Jeffrey> any. This issue is discussed in detail in sections 3.4 and 3.5,
but could
Jeffrey> bear an additional mention in the security considerations.
There's a fairly lengthy discussion of channel binding already in the
security considerations section.
I've added a sentence explaining why channel binding is important.
Thanks.
I've addressed these where I agree with you. A couple cases I disagreed
or decided to leave it to the RFC-editor.
_______________________________________________
secdir mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
--- End Message ---
--- Begin Message ---
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.
This document defines a family of GSS-API mechanisms which wrap EAP,
allowing applications which use GSS-API or SASL for authentiation to take
advantage of EAP mechanisms. It is a core part of the ABFAB architecture,
which brings mechanism-agile federated authentication to a wide variety of
applications without requiring that a user's preferred (required)
authentication mechanism be supported by the services that he wishes to
use.
I've talked with the authors and others a lot about how ABFAB in general
and this mechanism in particular are supposed to work, so I'm already
comfortable with the general approach. Thus, this review will be confined
to particular protocol specifics and some editorial issues.
This protocol combines existing security protocols and frameworks in new
ways, and thus invokes all of the security issues surrounding EAP, the
GSS-API, the per-message services of RFC4121, the cryptographic framework
defined in RFC3961, and the AES enctype defined in RFC3962. It also
introduces new considerations related to layering, combination, and
involving additional parties in the authentication process. Many of
these are incorporated by reference to the relevant documents, while
others are discussed directly.
Overall, I think this is basically done. However, I did find a couple of
things, included in my comments below, which the authors should probably
address before the document is published. In particular, I believe there
is a potential gap in the MN format (though this may be deliberate), an
ambiguity in how import of Kerberos principal names should be handled, and
a missing step in key derivation. I also make suggestions related to
mechanism names and to integrity protection of the context establishment;
these may be things which the authors have already considered or don't
feel it is appropriate to pursue at this time.
-- Jeff
========================================
Section 3.1 discusses the format of the GSS-API Mechanism Names (MNs)
used by the family of mechanisms defined in this document. However, it
sort of glosses over the notion that, in GSS-API jargon, "Mechanism Name"
means a name of an initiator or acceptor in a mechanism-specific format,
and _not_ the name of a mechanism, as one might otherwise assume. I
suggest the following change to the first paragraph of this section:
OLD:
Before discussing how the initiator and acceptor names are validated
in the AAA infrastructure, it is necessary to discuss what composes a
name for an EAP GSS-API mechanism. GSS-API permits several types of
generic names to be imported using GSS_Import_name(). Once a
mechanism is chosen, these names are converted into a mechanism name
form. This section first discusses the mechanism name form and then
discusses what name forms are supported.
NEW:
Before discussing how the initiator and acceptor names are validated
in the AAA infrastructure, it is necessary to discuss what composes a
name for an EAP GSS-API mechanism. GSS-API permits several types of
generic names to be imported using GSS_Import_name(). Once a
mechanism is chosen, these names are converted into a
mechanism-specific name form, called a "Mechanism Name". Note that a
Mechanism Name is the name of an initiator or acceptor, not the name
of a mechanism. This section first discusses the mechanism name form
and then discusses what name forms are supported.
----------------------------------------
At the end of section 3.1, you write "Mechanisms MAY support the
GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form", but not how names of this form
should be converted to GSS-EAP MNs. This results in ambiguities and also
some potential for unexpected results, including importing invalid names.
Some Kerberos principal names will be invalid as EAP-GSS MNs, particularly,
those using principal name forms which contain at-signs or realm name forms
contianing slashes (the latter are not likely to be a practical problem,
but the former might be). Others will be interpreted not as intended, or
may not be appropriate transformations (for example, user "instances" with
multiple principal name components).
To address this, I would recommend the following:
1) Introduce an escaping syntax, such as the use of backslash as in
RFC1964 section 2.1.1, to allow representation of name-strings which
contain slash and at-sign characters.
2) Admonish implementations which support importing of names of type
GSS_KRB5_NT_KRB5_PRINCIPAL_NAME that when doing so they must process
the escaping described in RFC1964 section 2.1.1 and convert to a
canonical form in which only slash, backslash, and at-sign are
escaped.
3) Warn that direct import of Kerberos principal names may have
unintended effects due to differences in name structure, and that this
feature, if implemented, should be used carefully (possibly disabled
by default).
As an alternative to (1), you could continue to simply prohibit names
containing slashes and at-signs as parts of name-strings. In this case,
implementations which support import of GSS_KRB5_NT_KRB5_PRINCIPAL_NAME
names MUST verify that the imported name is valid and otherwise fail the
import.
----------------------------------------
I am a bit confused by section 3.2. You seem to be saying that the
representation of names and components of names transported in other
protocols is up to the protocol in question, but that the representation
when a name is sent as part of this protocol is UTF-8. However, the ABNF
in section 3.1 permits only characters up to 0xff. Is it the intent that
MNs be treated as UTF-8 strings? If so, it would be better to specify the
MN form in two laters, first indicating that it is a UTF-8 string and then
using ABNF to define the permitted sequences of Unicode characters.
----------------------------------------
Why define a family of mechanisms parameterized by enctype, instead of
defining a single mechanism, specifying a mandatory-to-implement enctype,
and negotiating the enctype to be used as part of context establishment?
This would also work around a situation with SASL mechanism naming, which
is that you are effectively defining an entire family of GSs-API mechs but
specifying SASL mechanism names for only one member of that family. This
means that either other enctypes cannot be used at all, or else they must
forever have non-friendly names encoded as per RFC5801 section 3.1.
Alternately, you could register a family of SASL mechansim names, of the
form EAP-<enc> and EAP-<enc>-PLUS, where <enc> is a numeric enctype. This
is a bit uglier than EAP-AES128[-PLUS], but prevents future
interoperability problems due to SASL mechanism name mismatches and at
least is reversible, unlike the RFC5801 section 3.1 encoding.
----------------------------------------
In section 5.4, may the acceptor's message include a vendor subtoken?
----------------------------------------
In section 5.5, what is a "protected result indication" ?
----------------------------------------
Is it possible for the Extensions state to involve more than one round trip?
----------------------------------------
In section 5.6.1, initiators should be REQUIRED to send zeros for all flag
bits other than GSS_C_MUTUAL_FLAG, in order to guarantee that these bits
are available for future extension.
----------------------------------------
The MIC token described in section 5.6 currently protects only the
extension token containing it. Is there any value to protecting the entire
context establishment exchange?
----------------------------------------
In section 6, the descriptions of the derivation of the GMSK and CRK
seem incomplete. In particular...
- What happens if the EAP master session key is not large enough to
satisfy the requirements of the GMSK enctype's random-to-key?
- What is the CRK enctype?
- I think you mean to indicate that the CRK is the result of applying
the CRK enctype's random-to-key to the output of the indicated truncate
call. A mere string of random bits is not an RFC3961 protocol key.
- The definition of L is garbled. I think you mean it is the length of
data required by the CRK enctype's random-to-key.
----------------------------------------
It is frequently important to GSS-API initiators that they are talking to
the expected acceptor. In the present mechanism, that requires not only
verifying the acceptor/NAS's identity with the EAP server (by means of EAP
channel bindings), but also verifying that the verified NAS identity agrees
with the GSS-API target name provided by the initiating application, if
any. This issue is discussed in detail in sections 3.4 and 3.5, but could
bear an additional mention in the security considerations.
========================================
I also found a number of editorial issues:
Abstract:
"... when using the EAP mechanism" should probably be "when using the
Extensible Authentication Protocol (EAP)", at which point the second
expansion of EAP could be removed.
Section 1, graf 6 (page 5): s/prospective/perspective/
Section 1.3, last graf (page 7): The phrase "security association
protocols" is used twice, where I believe "secure association protocols" is
intended.
Section 3.1 ABNF: This attempts to define name-char to match any character
except the slash (/) and at-sign (@), which are used to separate name
components. However, it incorrectly prohibits uppercase G (decimal 71, hex
0x47) instead of slash (decimal 47, hex 0x2f).
Section 3.1, graf 3 (page 10, after ABNF): In "specifications of this
mechanism MUST NOT prepare the user-or-service according to these rules",
I think you mean "implementations", not "specifications".
Section 3.1, bottom of page 10: s/proceeding/preceeding/
Section 3.3, last graf: "canonicalizing it to a mechanism" should be
"canonicalizing it to a mechanism name".
Section 3.5, graf 4 (bottom of page 13): In "The EAP server MUST assure",
s/assure/ensure/.
In section 5, the table describing the format of an innerToken shows
the first subtoken body as occupying octets 10..10+n, which is a total
of n+1 bytes. It should be 10+n-1, and the second subtoken type should
be at octets 10+n..10+n+3.
Sections 5.5.1, 5.5.2; the subtoken types are missing zeros.
Section 5.6; this state is variously called Extension (singular) or
Extensions (plural).
Section 7.2: The GSS mech parameters registry was indeed created by
RFC6542. Also, it might be clearer if the last two entries in the table
explicitly referred to "this RFC", so someone doesn't think you mean
RFC4121 section 5.
Section 7.3: The table should be sorted by type, not defining section.
Section 7.4: draft-ietf-radext-radius-extensions is up to -06, and the
relevant section is now 10.3, not 9.3.
Section 7.5: s/EAP-ES128/EAP-AES128/
Section 10.1: Do you need a normative reference to RFC3962?
_______________________________________________
secdir mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
--- End Message ---
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
