On Mon, Oct 26, 2020 at 12:51 PM Jorge Vergara
wrote:
> This is a detailed one so I’ve tried to go over it carefully. Most of it
> looks good but I’m unsure about this part:
>
>
>
> > If an inner method fails or MAC verification
>
> fails then S-IMCK is not used in further calculation.
>
>
>
> It
On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey wrote:
>
>
> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar
> wrote:
>
>> Few comments:
>> 1) It seems that the server MUST send Crypto-Binding TLV after a single
>> EAP authentication method, after each of EAP authentications methods in a
>> sequence,
On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar
wrote:
> Few comments:
> 1) It seems that the server MUST send Crypto-Binding TLV after a single
> EAP authentication method, after each of EAP authentications methods in a
> sequence, after no inner method but not after
> Basic-Password-Authentication.
On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar
wrote:
> >It should say:
> >
> > EAP method messages are carried within EAP-Payload TLVs defined in
> > Section 4.2.10. Upon method completion, the server MUST send an
> > Intermediate-Result TLV indicating the result.
>
> Jouni explained in errata
On Mon, Oct 26, 2020 at 1:25 AM Oleg Pekar
wrote:
> It Should say:
>>
>> S-IMCK[j] = first 40 octets of IMCK[j]
>> CMK[j] = last 20 octets of IMCK[j]
>> where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].
>> If no inner EAP method has been run the S-IMCK and CMK are ge
This is a detailed one so I’ve tried to go over it carefully. Most of it looks
good but I’m unsure about this part:
> If an inner method fails or MAC verification
fails then S-IMCK is not used in further calculation.
It is a valid scenario that multiple authentication methods run and some fail,
[Trimming]
> On 26 Oct 2020, at 16:26, Michael Richardson wrote:
>
>
>>> While this degenerate case of Authentication Server + OCSP Signer on the
>>> same
>>> machine is kinda dumb from a overall security point of view, it's still
>>> better than raw public keys.
>
>> Yes. Let’s think about
Michael:
>> I am aware of some places that generate an OCSP response for the entire
>> population of certificates, and those responsed are distributed to many
>> locations. I am not aware of anyone that distributes the OCSP
>> responder signature private key to multiple locations.
>
> Does anyon
Russ Housley wrote:
>>> The second is, I think, that the EAP server (Authentication Server),
would run
>>> an OCSP responder locally so that it can mint it's own staples.
>>> AFAIK, each certificate can point to a different OCSP signer.
>>
>> Does anyone actually do that?
Eliot Lear wrote:
>> No. There are several steps before we get to raw public keys.
>>
>> The first is that the duration of the Staples could be lengthed to
accomodate
>> anticipated down time for the (now) critical OCSP responder.
>> A second part is that perhaps staples cou
>> The second is, I think, that the EAP server (Authentication Server), would
>> run
>> an OCSP responder locally so that it can mint it's own staples.
>> AFAIK, each certificate can point to a different OCSP signer.
>
> Does anyone actually do that?
I am aware of some places that generate an
> On 26 Oct 2020, at 15:19, Michael Richardson wrote:
>
> Signed PGP part
>
> Eliot Lear wrote:
>>> The EAP server is expected to frequently request a OCSP response from
>>> the OCSP responder (a server typically run by the certificate
>>> issuer). The OCSP response is then added to the Serve
Eliot Lear wrote:
>> The EAP server is expected to frequently request a OCSP response from
>>the OCSP responder (a server typically run by the certificate
>>issuer). The OCSP response is then added to the Servers Certificate
>>message as long as it is valid. Before the OCSP respon
John Mattsson wrote:
> 1. Basically all TLS implementations support OSCP, and a majority
> support OSCP stapling (Certificate Status Request). Mbed is an
> exception rather than the rule.
Is this for server and client certificates, or just server certificates?
It seems that getting t
Thanks, John. Please see below:
> On 26 Oct 2020, at 13:58, John Mattsson
> wrote:
>
> Hi Eliot,
>
> The EAP server is expected to frequently request a OCSP response from the
> OCSP responder (a server typically run by the certificate issuer). The OCSP
> response is then added to the Server
Hi Eliot,
The EAP server is expected to frequently request a OCSP response from the OCSP
responder (a server typically run by the certificate issuer). The OCSP response
is then added to the Servers Certificate message as long as it is valid. Before
the OCSP response is close to expiring, the EA
Hi John,
My question is one of pragmatics. In an offline industrial environment, what
is expected of the server to accomplish the stapling? Especially if the
request is nonced.
Eliot
> On 26 Oct 2020, at 13:08, John Mattsson
> wrote:
>
> Hi,
>
> When this was discussed in the group, it w
Hi,
When this was discussed in the group, it was decided to not only mandate
revocation checking, but to also mandate OCSP stapling as is it often the only
viable solution to let an offline peer check the revocation status of the
server. We had a discussion on must-staple, and the decision was
>It should say:
>
> EAP method messages are carried within EAP-Payload TLVs defined in
> Section 4.2.10. Upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result.
Jouni explained in errata 5767 that not all EAP methods are EAP
authentication methods, to
Few comments:
1) It seems that the server MUST send Crypto-Binding TLV after a single EAP
authentication method, after each of EAP authentications methods in a
sequence, after no inner method but not after
Basic-Password-Authentication. Shouldn't we close this gap for the sake of
simplicity and str
>
> It Should say:
>
> S-IMCK[j] = first 40 octets of IMCK[j]
> CMK[j] = last 20 octets of IMCK[j]
> where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].
> If no inner EAP method has been run the S-IMCK and CMK are generated as
> above from S-IMCK[0].
Joe, for me it sti
21 matches
Mail list logo
