Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Alan DeKok <[e-mail]>]

On Mar 16, 2020, at 12:57 PM, Michael Richardson <[e-mail]> wrote:
> 1) "RADIUS can generally transport only about 4000 octets of EAP in a single
>   message."
> 
>   Can you explain this?  Radius over UDP would have fragment a 4000 octet
>   message, so why is the number 4000?  That's three fragments.  Is the
>   loss amount beyond this too high?  Or is it that common implementations
>   just don't support larger sizes?

  RFC 2865 says that the maximum RADIUS packet size is 4K octets.  Given some overhead for the packet header and other attributes, a reasonable limit for EAP is 4000 octets.

>   RFC6613 radius over TCP would not seem to have that limitation, but
>   I won't be surprised if it is less common. I've certainly used it
>   as it solves the the NAT and Radius key problem. (Alan?)

  RFC 6613 doesn't solve the 4K limit.  That's solved by RFC 7930.  I'm not aware of any products supporting that, tho.

> 2) the problem appears is documented to occur at 60Kbyte chain size.
>   With 6 intermediate certificates in the chain, that provides for
>   10KByte for each certificate, which seems rather generous to me.
>   I am not objecting to solving the problem as stated, but I want to
>   understand what the goals really are.
> 
>   The advice in section 4.1 is good.  Are full postal addresses in
>   intermediate CAs really the culprit here?

  It's the bloat of "meh, put everything into the certificate".

  The problem is that when certificate chains fail, the admins don't tell people.  They *might* ask a question on a public mailing list... or not.  But they won't share *what* they did to bloat the certificate chain.

  I've seen people run into this in the real world.  And then express great surprise when told "No, you can't really have 60K+ certificate chains.  This isn't HTTP."

  The advice here is necessarily vague, because we don't know exactly what the admins are doing.

> 3) section 4.2.2, about caching certificates from a previous TLS session
>   is interesting.  I'm unfamiliar with rfc7924, does it use a session
>   resumption ticket, or will any previous connection do?
>   (It seems that a session resumption process is not required?)
>   This might provide motivation Alan's question about why/how one
>   might resume an HTTPS TLS session over EAP-TLS.

  TLS 1.3 makes it easier to cache the certificates.  But you may have to exchange them at least once, which makes bootstrapping difficult.

> I was surprised to get to the end of the document without any suggestions
> about sending certificates by reference rather than value.

  Does TLS 1.3 support that?  I haven't looked in detail, TBH.

> This is the method that we have adopted on draft-selander-ace-ake-authz.
> We considered using the mathmesh UDF mechanism, but found a way that could
> instead send only the location while actually encrypting the ID as a privacy
> enhancement.
> I don't think such a thing would be desireable, and TLS 1.3 provides other
> equivalent privacy enhancements, but I want to suggest you consider a new
> certificate container which contains a reference.  IKEv2 already has that.

  Changing that may be very, very, difficult.

  Alan DeKok.