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

Sean Turner <turners@ieca.com> Wed, 18 July 2012 18:52 UTC

Return-Path: <turners@ieca.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B017011E8132 for <secdir@ietfa.amsl.com>; Wed, 18 Jul 2012 11:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.357
X-Spam-Level:
X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APrbOuSqyq3S for <secdir@ietfa.amsl.com>; Wed, 18 Jul 2012 11:52:51 -0700 (PDT)
Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.94.11]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD211E8150 for <secdir@ietf.org>; Wed, 18 Jul 2012 11:52:50 -0700 (PDT)
Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 4FFF0B8CC20B5; Wed, 18 Jul 2012 13:53:42 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 36AECB8CC2057 for <secdir@ietf.org>; Wed, 18 Jul 2012 13:53:42 -0500 (CDT)
Received: from [71.191.15.186] (port=34944 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <turners@ieca.com>) id 1SrZNV-0000ke-4l; Wed, 18 Jul 2012 13:53:41 -0500
Message-ID: <50070634.2090506@ieca.com>
Date: Wed, 18 Jul 2012 14:53:40 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
References: <1342587005.7190.56.camel@minbar.fac.cs.cmu.edu> <tsl1uk9njg6.fsf@mit.edu>
In-Reply-To: <tsl1uk9njg6.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [71.191.15.186]:34944
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: draft-ietf-abfab-gss-eap.all@tools.ietf.org, secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2012 18:52:57 -0000

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 <jhutz@cmu.edu> 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.
>