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

[Jeffrey Hutzelman <[e-mail]>]

On Wed, 2012-07-18 at 12:05 -0400, Sam Hartman wrote:

>     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.

OK, but then what does it mean?  Is it intended to be UTF-8?


>     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.

OK, fair enough.

> Since the SASL registry is FCFS, I don't see a problem with having to
> register each enctype separately to get a friendly name.

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

Of course, it's possible to work around that problem, if implementations
which know about the friendly name also support and advertise the
unfriendly one.  If you're OK with that, I guess I am too.




>     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.

Oh, that's true.

>     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.

OK.


>     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.

OK.  That's what I thought I got from the text, but I wanted to be sure.

>     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.

OK; this is definitely one of the places where I expected to find the
issue had already been discussed.  Good enough for me.


>     Jeffrey> - What is the CRK enctype?
> 
> The GMSK enctype.

Please say that explictly.


>     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.

The sentence I'd add is about the importance of insuring that the
acceptor name used at the GSS-API layer corresponds to the name
authenticated by EAP channel bindings.

> I've addressed these where I agree with you. A couple cases I disagreed
> or decided to leave it to the RFC-editor.

I assume you're referring to the editorial issues.

-- Jeff