Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08

[Sam Hartman <[e-mail]>]

[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 <[e-mail]> 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.