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

[Michael Richardson <[e-mail]>]

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.

    >> Figure 2: should TLV Encapsulation be narrower than TLS, so show that
    >> it fits into TLS? Ditto Inner EAP Method fits into TLV.

    >   Sure, but then the text doesn't fit into the fields any more.  And
    > making the box wider will overflow the line width.  So I think it's not
    > terrible, and OK as is.

Agreed, it's not terrible.

    >>> be used in the case when the inner method provides mutual
    >>> authentication, key generation, and resistance to man-in-the-middle
    >>> and dictionary attacks.  TLS ciphersuites that do not provide
    >>
    >> can you give an example of an inner method that does not do this?

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

    >> Section 3.3: it might be useful to reviewers not steeped in EAP and
    >> roaming to understand how often *TLS* resumption is used in practice
    >> (maybe eduroam have some server stats they could share?), and how it
    >> is important when roaming from AP to AP.  (I understand that *TEAP* is
    >> not well used in eduroam yet, but EAP-TLS is)

    >   How about this:

    > 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 :-)

    >   RFC9190 says systems SHOULD implement resumption, so we probably
    > can't make it a MUST here.

You can always turn SHOULD into MUST.  If it's just Quality of implementation
issue, those people ignore MUSTs anyway.

    >  I also don't know if it's worth getting into details as to why
    > resumption is useful.  It's either blindingly obvious as to why, or
    > your network catches fire and dies.

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.

    >> If I did run EAP-TLS as an Inner method (whether once or twice), could
    >> I use resumption?

    >   Uh... why didn't anyone mention this before?  TEAP is a near-endless
    > source of surprises and corner cases.

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

    >   My $0.02 is to disallow inner resumption.  It makes zero sense.  If
    > you want faster authentication, resume the outer session.  How about
    > after the added paragraph quoted above:

....

    > In contrast, TEAP implementations SHOULD NOT perform resumption for
    > inner methods.  If the user or machine needs to be authenticated, it
    > should use a full authentication method.  If the user or machine needs
    > to do resumption, it can perform a full authentication once, and then
    > rely on the outer TLS session for resumption.

That sounds fine to me.

    >> It might be worth saying that 3.4.2 is a TEAP-TLV thing, and not
    >> EAP-PWD.

    >   I'm not sure why.  EAP-PWD is substantially different, and does a
    > crypto exchange.  The TEAP password authentication just sends a bare
    > password inside of the TLS tunnel.

Well, it took me a bit to understand.
I wondered why the method exists, when EAP-PWD seems architecturally simpler.

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

    >> section 3.6: tls-unique is replaced by TLS Exporter in TLS 1.3.  I
    >> think that there is missing TLS 1.3 text here.

    >   That text is in RFC9427.  Maybe "For TLS 1.2 and earlier, do this.
    > For TLS 1.3, see RFC 9427"

Yes.

    >> section 3.7.2:
    >>> The EAP-Response packet sent by the peer may encapsulate a TLS
    >>> ClientHello handshake message, in which case the TEAP server MAY
    >>> allow the TEAP conversation to be restarted, or it MAY contain a TEAP
    >>> response with a zero-length message, in which case the server MUST
    >>> terminate the conversation with an EAP Failure
    >>
    >> What are some situations where a peer would expect to do a restart?
    >> Some kind of temporary resource exhaustion or something?
    >> ENORANDOMNUMBERSLEFTPLEASEWAITFORMORENEUTRINOS ??

    >   Is "I dunno" a good response here?

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)

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

    >>> It is NOT RECOMMENDED to use certificates provisioned via TEAP with
    >>> any other protocol which uses TLS.
    >>
    >> Honestly, this renders the entire point of the provisioning aspect of
    >> this probably moot.

    >   I'm wary of provisioning a client cert with TEAP, and then using it
    > for ????

Yes, that's certainly a concern.
And for random laptops users, it's probably a bad thing.
But I know Eliot wants to use this for IoT identity provisioning.

    >   But that being said, it also doesn't make a lot of sense to
    > authenticate (somehow?) and then get a client certificate.  The main
    > benefit of the client certificate is that you can now change your
    > password at will, and you don't need to update the EAP configuration.

What's a password?

    >> Section 4.3, about TLV rules.  Given that EAP fragments, but is
    >> subject to RADIUS and other layers dropped packets..  And that TLS
    >> assumes a TCP-like transport for its records, there is a question
    >> about whether one should pack more TLVs into a single TLS record, and
    >> let EAP fragment, or put fewer TLVs in, and have fewer fragments.  Is
    >> there any advice here?  We can't put certain things together, but can
    >> we split them out more?  What if we care more about loss due to lost
    >> fragments, vs round-trips?

    >   RADIUS defines retransmission rules.  I don't think we need to worry
    > here about lost fragments.

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.

    >> I suggest when listing the contributors for 7170, that they be listed
    >> using the markdown contributors: method, as that results in XML that
    >> is machine parseable.  There is also a {{{First Last}}} for kramdown
    >> that results in XML.

    >   Sure.  I can't find much in the way of actual examples...

author:
...

contributor:
  - name: First Last
    email: [e-mail]

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-acceptable-urls/blob/master/opsawg-mud-acceptable-urls.md?plain=1#L32


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide