Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

[Alan DeKok <[e-mail]>]

On Aug 17, 2023, at 8:01 PM, Michael Richardson <[e-mail]> wrote:
> Alan DeKok <[e-mail]> wrote:
>>> section 2; paragraph 2, uses SHOULD several times without obvious
>>> exceptions.  Could be it is MUST?
> 
>>  I don't think we can mandate that the outer EAP identity is an NAI.
> 
> okay, then the exception for the SHOULD needs text.

  Sure.

>>  NULL ciphers suites.  IIRC this is based on a comment from Bernard
>> which pointed this out.
> 
> I think people need to be beat on the head here.

 OK, I'm happy to do that.  

>> All TEAP implementations SHOULD support resumption.  Using resumption
>> can significanly improve the scalability and stability of
>> authentication systems.
> 
> Again, if it's a SHOULD, then there is an exception :-)

  I'll add notes on "your network will catch on fire".

> So, if you consider the case where engineer argues with CTO as to why they
> need to spend the time, and the CTO is clueless, then it being
> blindingly obvious doesn't matter.  If the network will catch fire and die,
> then really, it's a MUST.

  Given I think all implementations will support resumption, I'm happy to make it a MUST.

> I'm not sure it's sane to use EAP-TLS for Inner method myself.

  I have similar doubts, but it's implemented in supplicants, so we can't really ban it.

  Given various other issues raised here, I'll add a new section "Limitations on inner EAP methods".

* don't use TTLS, PEAP, or FAST

* don't use EAP-GTC

* for TLS 1.3, use a client certificate outside of the tunnel in preference to EAP-TLS

> I wondered why the method exists, when EAP-PWD seems architecturally simpler.

  Passwords are stored "crypted' in the user DB.  Historically this meant using PAP based methods for authentication.  In contrast, MS-CHAP is incompatible with crypt'd password stores.

  RFC 8146 permits EAP-PWD to be used with crypted passwords, which seems better.

  However, the main reason to allow passwords is for OTP and TOTP based methods.   I'll add some text.

>>> section 3.5: I wonder if additional references to RFC6125 and the
>>> UTA-bis version of that might be more clear.  I think that this
>>> section is going to get beat on by security review.  I also suggest
>>> that rather than saying how it is to be matched, I suggest the section
>>> be more prescriptive in how certificates are expected to be formed.
>>> (I recognize that this text has not changed since 7170)
> 
>>  Do you have suggested text?  I'm wary of poking at things in this
>> area.
> 
> I think that you can poke at it now, or during IESG DISCUSS :-)
> I can suggest something, but not today. If you open a github and assign it to
> me, I will remember.

  Done.

https://github.com/emu-wg/rfc7170bis/issues/24

> [ restart ]
>
> I'm trying to understand a situation grave enough to cause a failure, yet not
> grave enough that the end points could essentially try again. (vs restarting
> from scratch, or failing over to another server)

  Exactly.  Suggestions are welcome.

>>> Also, I wonder if the word "peer" above means "Peer", or just either
>>> end.  To that end, I found "Peer" very confusing at times.
> 
>>  It means "TEAP peer", to match the earlier "TEAP server"
> 
> Okay, could it always be "Peer", and never "peer" then?

  I'll just make it explicitly "TEAP peer" to match the use of "TEAP server".

> Sure, but the question is: is it better to have 5 1K things, or
> 1 5K thing?   Assuming that the TEAP level TLVs can be broken up that way.

  The TEAP TLVs can be broken up into multiple TLS fragments.  However, the TLS layer ensures that their all of the data is presented to the TEAP application, or none of it is.

  i.e. the application should not have to do defragmentation itself.

  Alan DeKok.