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

[Alan DeKok <[e-mail]>]

On Aug 17, 2023, at 5:02 PM, Michael Richardson <[e-mail]> wrote:
> Some people might find this URL useful:
> https://author-tools.ietf.org/diff?doc_1=RFC7170&doc_2=draft-ietf-emu-rfc7170bis%2F

  The diff is surprisingly good.

> Reading the document from top-to-bottom for the first time in awhile (to do
> the Shepherd write-up), paragraph two of the Introduction, where EAP-FAST is
> mentioned seems to be aged.  It's from 7170, but given that this is 7170bis, I wonder if the
> history is entirely accurate, or really still timely.

  It's worth removing the text saying "EAP-FAST is widely used", and just saying "TEAP is based on EAP-FAST with change"

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

  There is also a discussion of why we can't make the EAP Identity a "MUST NAI" in RFC 7542 Section 2.6: https://datatracker.ietf.org/doc/html/rfc7542#section-2.6

> }   Upon successful execution of TEAP, the EAP peer and
> }   EAP server both derive strong session key material that can then be
> }   communicated to the network access server (NAS) for use in
> }   establishing a link-layer security association.
> 
> I feel like a reference is in order (but 7170 didn't have one).

  This is the MSK as defined in RFC 3748.  I'll add a reference.

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

>>  The TEAP version is not protected by TLS and hence can be modified in
>>  transit.  In order to detect a modification of the TEAP version, the
> 
> I suggest:
> 
>>  The TEAP version is not protected by TLS and hence can be modified in
>>  transit.  In order to detect a bid-down attack, where the TEAP version is modified, the
> 
> (similar things are done in IKEv2, as well as in TLS; I don't know if a
> reference is worthwhile here)

  I'll change it.  It's probably not worth adding a reference.

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

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

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

 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.

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

  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.


>>  If a particular authentication method succeeds, the server SHOULD NOT
>>  attempt a subsequent authentication method.  For example, if a user
> 
> this seems to contradict the first paragraph that says that multiple
> authentications are allowed.

  Yes.  It should be:

... subsequent authentication method for the same Identity-Type.

  i.e. don't do "user" authentication twice.  It's dumb.

  IIRC, this text was added based on a corner case Eliot brought up earlier on the list.

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

> A most likely thing today for "Password" authentication is to use TOTP
> methods against a hardware token. (X9.9, SecureID, etc.)

  Sure.  I can add a reference to 6238.

> If I read correctly, a Crypto-Binding TLV is expected after every successful
> authentication method.  If multiple passes occur, I'm unclear what to do with
> the multiple bindings.
> I think that they ought to be incremental.
> They can be checked each time though.

  Yes.  The crypto binding is done each time, and is based on the accumulated IMCK.

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

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

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

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

> section 3.7.3: maybe reorganize into point form.
> It seems like a long if-then-else, and maybe a case-when format would be easier.
> The edits since 7170 don't seem sufficient to clarify this section.

  I'll take a look.  It's unclear to me how best to represent this.

> section 3.9.: what is "server unauthenticated provisioning"
> (sounds like TEAP-BRSKI?)

  Yes.

>>  TEAP peers MUST track whether or not server authentication has taken
>>  place.  When the server cannot be authenticated, the peer MUST NOT
>>  request any services from it.
> 
> so, if a TEAP (supplicant) peer can not validate the Server certificate, but
> it can get a MSK/EMSK that matches, then it can request "services" from it.
> (What are these services, if they aren't things that lead to an MSK? Ah,
> subsequent sections.  Forward reference to 3.9.3 please)

  Added.

> Mention is then made of "provisioning data" as a service.
> I think this section could use a rewrite.  I suggest using this section to
> say WHAT TO DO, and then in Security Considerations, tell us what happens
> when that advice is not followed.  That way implementers aren't dealing with
> a mix "DO X", with "watch out for Y"

  I'll take a look.

> 3.9.1: tls-unique vs TLS 1.3 again.
> I think, unless there are in-the-field, two interoperable, versions of this
> section, that it be removed from this document, and put into a new document.
> The text in 3.9.2 is new, and frankly not all that useful.
> CSRs are not that complex, because 99% of the information that could be
> included in a CSR is useless, and CAs throw it out.  I don't think this
> document needs to repeat the need for a CSP.

  I'll push that back to the WG 

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

  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.

  But I'm just the document editor here.  I'm not using TEAP in anger with client certificates.

>> 4.2.19.  Identity-Hint TLV
> 
> I think that this should be mentioned in section 3.
> Probably 3.2 or 3.4.

  I'll add some text.

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

  We also don't have to worry about fragmentation of application data.  RFC 8446 Section 5.1 says:

   fragment:  The data being transmitted.  This value is transparent and
      is treated as an independent block to be dealt with by the higher-
      level protocol specified by the type field.

  So the application (TEAP) gets all of the application data when all fragments have been received by TLS.

> 5.1 finally talks about TLS 1.3 exporters.
> 
> section 5.7 says: "negotiate down", and I think the common term in the
> literature is "bid-down attack", and I think reviewers will prefer that term.

  OK.

> s/Man-in-the-middle attacks/on-path active attacks/

  OK.

> 7.4.1 describes a mechanism where TLS 1.2 can use re-negotiation to get
> confidentiality of client certificates.  That shouldn't be introduced in the
> SC, but needs to be described much easlier, and then referenced.

  OK.  I'll 

> Also, there is BCP14 language in the SC, which I really prefer never to see.
> It should be in the main body.

  I'll take a look at rewriting that.

> Important nits:
>  -- The abstract seems to indicate that this document obsoletes RFC7170, but
>     the header doesn't have an 'Obsoletes:' line to match this.

  I'll add that.

>  == Outdated reference: draft-ietf-emu-tls-eap-types has been published as
>     RFC 9427

  There is a reference to 9427, but I missed updating an old one for the I-D.

> Some other nits worth looking at.
> 
> Normative references that probably could be informative:

  Done.

> Informative references that probably need to be normative:

  Done.

> MAYBE:
>   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>              "Randomness Requirements for Security", BCP 106, RFC 4086,
>              DOI 10.17487/RFC4086, June 2005,
>              <https://www.rfc-editor.org/info/rfc4086>.
>   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
>              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
>              <https://www.rfc-editor.org/info/rfc4648>.

  I think leaving those as informative is OK.

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

   Alan DeKok.