EAP-TLS: Update specification references to RFC 5216 and 9190
The previously used references were pointing to an obsoleted RFC and draft versions. Replace these with current versions. Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This commit is contained in:
parent
74ae4cf757
commit
63f311b107
5 changed files with 7 additions and 7 deletions
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
* hostapd / EAP-TLS (RFC 2716)
|
||||
* hostapd / EAP-TLS (RFC 5216, RFC 9190)
|
||||
* Copyright (c) 2004-2008, Jouni Malinen <j@w1.fi>
|
||||
*
|
||||
* This software may be distributed under the terms of the BSD license.
|
||||
|
|
|
@ -367,14 +367,14 @@ int eap_server_tls_phase1(struct eap_sm *sm, struct eap_ssl_data *data)
|
|||
sm->cfg->ssl_ctx, data->conn);
|
||||
|
||||
/*
|
||||
* https://tools.ietf.org/html/draft-ietf-emu-eap-tls13#section-2.5
|
||||
* RFC 9190 Section 2.5
|
||||
*
|
||||
* We need to signal the other end that TLS negotiation is done. We
|
||||
* can't send a zero-length application data message, so we send
|
||||
* application data which is one byte of zero.
|
||||
*
|
||||
* Note this is only done for when there is no application data to be
|
||||
* sent. So this is done always for EAP-TLS but notibly not for PEAP
|
||||
* sent. So this is done always for EAP-TLS but notably not for PEAP
|
||||
* even on resumption.
|
||||
*/
|
||||
if (data->tls_v13 &&
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue