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

[Sean Turner <[e-mail]>]

I've got some nits to enter, but it looks like I won't have to pick 
these up.

spt

On 7/18/12 12:05 PM, Sam Hartman wrote:
>
> [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.
>