On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Feb 1, 2021, at 2:32 PM, Joseph Salowey <j...@salowey.net> wrote: > > > > > > > > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <al...@deployingradius.com> > wrote: > > On Feb 1, 2021, at 11:26 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > Yes, this is what I have in mind. So, maybe there's never any need for > the server to say "I won't say anything more" after just one round trip? > > > > I think so, yes. > > > > That means of course EAP-TLS will always require 4.5 round trips. > > > > [Joe] I don't follow why this means 4.5 round trips would be required. > > If the CloseNotify signal is sent by the server *after* it receives the > client certs, then another round trip is required. At least, according to > Figure 1 of draft-13. > > The CloseNotify can't be sent with the EAP-Success, because the > EAP-Success can't carry data. So the packet flow looks something like this: > > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require CloseNotify. > EAP-TLS Peer EAP-TLS Server > > EAP-Request/ > <-------- Identity > EAP-Response/ > Identity (Privacy-Friendly) --------> > EAP-Request/ > EAP-Type=EAP-TLS > <-------- (TLS Start) > EAP-Response/ > EAP-Type=EAP-TLS > (TLS ClientHello) --------> > EAP-Request/ > EAP-Type=EAP-TLS > (TLS ServerHello, > TLS EncryptedExtensions, > TLS CertificateRequest, > TLS Certificate, > TLS CertificateVerify, > <------- TLS Finished) > EAP-Response/ > EAP-Type=EAP-TLS > (TLS Certificate, > TLS CertificateVerify, > TLS Finished) --------> > > EAP-Request/ > EAP-Type=EAP-TLS > <-------- (TLS CloseNotify) > > EAP-Response/ > EAP-Type=EAP-TLS > (TLS Ack) --------> > <-------- EAP-Success
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
