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

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Jul 2012 12:08:53 -0400

for the WG's review.
a secdir review and my answers.

Subject: Topics

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

Subject: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], The IESG <[email-masked]>, secdir <[email-masked]>
Date: Wed, 18 Jul 2012 12:05:29 -0400

[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-masked]> 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-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Subject: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
From: Jeffrey Hutzelman <[email-masked]>
To: The IESG <[email-masked]>, secdir <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Wed, 18 Jul 2012 00:50:05 -0400

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-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Jul 2012 13:06:05 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

Yes.

    >> I think the implications have been discussed.

    Jeffrey> OK, fair enough.

    >> register each enctype separately to get a friendly name.

    Jeffrey> The only problem is that if someone starts using that enctype with this
    Jeffrey> mechanism before the friendly name is registered, they end up using the
    Jeffrey> unfriendly name, and then you eventually have a false interop problem,
    Jeffrey> where two implementations both support that enctype but don't know it.
    Jeffrey> Avoiding this is why we wanted friendly names registered when the
    Jeffrey> mechanism is defined, but RFC5801 doesn't really contemplate mechanism
    Jeffrey> families like this one.  

My assumption is that a implementation  will only include things for
which it has a friendly name in indicate_mechs output.