Re: [Emu] Proposed Resolution to TEAP Errata 5770

[Joseph Salowey]

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 is a valid scenario that multiple authentication methods run and some
> fail, but the overall TEAP authentication succeeds. For example, if two
> inner EAP Authentication methods run and the first fails but the seconds
> succeeds, the calculation needs to be valid. Based on the old text, that
> authentication method is omitted from calculations. This is what current
> implementations do.
>
>
>
> My editorial comment based on some other errata would be to that text
> needs to specify “authentication” methods (per Jouni’s other errata) since
> the Identity method doesn’t factor in here. I think it would also be
> beneficial to be specific about the behavior of basic username and password
> authentication here. Oleg made some comments to this effect on another
> email. Our implementation doesn’t support basic username and password
> authentication so I don’t have any prior experience here.
>
>
[Joe] Yes I think it is fine to say EAP authentication method.   I
have been convinced that the spec requires crypto-binding with the basic
password authentication.   I'll need to add this in.


>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Saturday, October 24, 2020 5:18 PM
> *To:* EMU WG 
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> Jorge Vergara 
> *Subject:* Proposed Resolution to TEAP Errata 5770
>
>
>
> Errata 5770: https://www.rfc-editor.org/errata/eid5770
> 
>
> Proposed Status: Verified
>
> Revision:
>
>
>
> Section 5.2 Says:
>
>
>
> On the sender of the Crypto-Binding TLV side:
>
>  If the EMSK is not available, then the sender computes the Compound
>  MAC using the MSK of the inner method.
>
>  If the EMSK is available and the sender's policy accepts MSK-based
>  MAC, then the sender computes two Compound MAC values.  The first
>  is computed with the EMSK.  The second one is computed using the
>  MSK.  Both MACs are then sent to the other side.
>
>  If the EMSK is available but the sender's policy does not allow
>  downgrading to MSK-generated MAC, then the sender SHOULD only send
>  EMSK-based MAC.
>
>On the receiver of the Crypto-Binding TLV side:
>
>  If the EMSK is not available and an MSK-based Compound MAC was
>  sent, then the receiver validates the Compound MAC and sends back
>  an MSK-based Compound MAC response.
>
>  If the EMSK is not available and no MSK-based Compound MAC was
>  sent, then the receiver handles like an invalid Crypto-Binding TLV
>  with a fatal error.
>
>  If the EMSK is available and an EMSK-based Compound MAC was sent,
>  then the receiver validates it and creates a response Compound MAC
>  using the EMSK.
>
>  If the EMSK is available but no EMSK-based Compound MAC was sent
>  and its policy accepts MSK-based MAC, then the receiver validates
>  it using the MSK and, if successful, generates and returns an MSK-
>  based Compound MAC.
>
>  If the EMSK is available but no EMSK Compound MAC was sent and its
>  policy does not accept MSK-based MAC, then the receiver handles
>  like an invalid Crypto-Binding TLV with a fatal error.
>
>
>
> If the ith inner method does not generate an EMSK or MSK, then IMSKi
> is set to zero (e.g., MSKi = 32 octets of 0x00s).  If an inner method
> fails, then it is not included in this calculation.
>
>
>
> It Should Say:
>
>
>
> On the sender of the Crypto-Binding TLV side:
>
>  If the EMSK is not available, then the sender computes the Compound
>  MAC using the CMK generated from MSK (CMK-MSK) of the inner method.
>
>  If the EMSK is available and the sender's policy accepts MSK-based
>  MAC, then the sender computes two Compound MAC values.  The first
>  is computed with the CMK generated from the EMSK (CMK-EMSK).  The
>
>  second one is computed using the CMK-MSK.  Both MACs are
>
>  then sent to the other side.  This also means the sender must generate
>
>  both EMSK and MSK based S-IMCKs.
>
>  If the EMSK is available but the sender's policy does not allow
>  downgrading to CMK-MSK MAC, then the sender SHOULD only send
>  a MAC computed from the CMK-EMSK.
>
>On the receiver of the Crypto-Binding TLV side:
>
>  If the EMSK is not available and an CMK-MSK Compound MAC was
>  sent, then 

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

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, after no inner method but not after
>> Basic-Password-Authentication. Shouldn't we close this gap for the sake of
>> simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
>> this case, the same as in no inner method case). Is
>> Basic-Password-Authentication treated as a case of no inner method?
>> Technically it is already correct but still may not be clear enough.
>>
>> This also affects section "4.2.13. Crypto-Binding TLV":
>>
>> The Crypto-Binding TLV MUST be exchanged and verified before the final
>> Result TLV exchange, regardless of whether there is an inner EAP
>> method authentication or not.
>>
>> Shouldn't we mention "inner EAP method or basic password authentication"?
>>
>
> [Joe] There are two cases where CryptoBinding is used, after completion of
> an EAP authentication exchange and with the Result-TLV exchange.   Since
> password based authentication does not generate a key there is no need for
> crypto binding.  It is just treated as a TLV.
>
>

[Joe] Section 4.2.11 contradicts this - "An Intermediate-Result TLV
indicating success MUST be accompanied by a Crypto-Binding TLV."  I think
we need to use the 0 MSK with the basic password authentication.


>
>> 2) [Minor] It is written both "EAP methods **and** basic password
>> authentication" and "EAP methods **or**basic password authentication" in
>> different sections above. Shouldn't we use the same all the time?
>>
>> [Joe] It should be consistent. Re-worded slightly:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> each individual EAP authentication method or basic password authentication
> in TEAP Phase 2.
>
> And
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages for inner EAP authentication methods or basic
> password authentication.
>
>
>>
>> On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey  wrote:
>>
>>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>>> Status: Verified
>>> Revision:
>>>
>>> Section 3.3.2 says:
>>>
>>> Upon receiving the response, the server
>>>indicates the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>>
>>> It Should say:
>>>
>>> Upon receiving the response, the server MUST
>>>indicate the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>>
>>> Section 3.6 says:
>>>
>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>> the individual EAP methods in TEAP Phase 2.
>>>
>>> It Should say:
>>>
>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>> the individual EAP methods and basic password authentication in TEAP Phase
>>> 2.
>>>
>>> Section 4.2.11 says:
>>>
>>> The Intermediate-Result TLV provides support for acknowledged
>>> intermediate Success and Failure messages between multiple inner EAP
>>> methods within EAP.
>>>
>>> It Should say:
>>>
>>> The Intermediate-Result TLV provides support for acknowledged
>>> intermediate Success and Failure messages between multiple inner EAP
>>> methods or basic password authentication within EAP.
>>>
>>> Section C.1 says:
>>>
>>> <- Crypto-Binding TLV (Request),
>>> Result TLV (Success),
>>> (Optional PAC TLV)
>>>
>>>Crypto-Binding TLV(Response),
>>>Result TLV (Success),
>>>(PAC-Acknowledgement TLV) ->
>>>
>>> It should say:
>>>
>>> <- Intermediate-Result-TLV (Success),
>>> Crypto-Binding TLV (Request),
>>> Result TLV (Success),
>>> (Optional PAC TLV)
>>>
>>>Intermediate-Result-TLV (Success),
>>>Crypto-Binding TLV(Response),
>>>Result TLV (Success),
>>>(PAC-Acknowledgement TLV) ->
>>>
>>> Section C.2 Says:
>>> <- Result TLV (Failure)
>>>
>>> Result TLV (Failure) ->
>>>
>>> It Should Say:
>>>
>>> <- Intermediate-Result-TLV (Failure),
>>>  Result TLV (Failure)
>>>
>>> Intermediate-Result-TLV (Failure),
>>>Result TLV (Failure) ->
>>>
>>>
>>> Notes:
>>>
>>> Section 3.3.2 implies that Intermediate-Result TLV is used after each
>>> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
>>> in C.1 does not show this. The proposed change in this errata adds the
>>> Intermediate-Result TLV indication here. Similar change should be done in
>>> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
>>> include Result TLV) since the language in 3.3.2 describe the indication to
>>> be 

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Joseph Salowey]

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. Shouldn't we close this gap for the sake of
> simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
> this case, the same as in no inner method case). Is
> Basic-Password-Authentication treated as a case of no inner method?
> Technically it is already correct but still may not be clear enough.
>
> This also affects section "4.2.13. Crypto-Binding TLV":
>
> The Crypto-Binding TLV MUST be exchanged and verified before the final
> Result TLV exchange, regardless of whether there is an inner EAP
> method authentication or not.
>
> Shouldn't we mention "inner EAP method or basic password authentication"?
>

[Joe] There are two cases where CryptoBinding is used, after completion of
an EAP authentication exchange and with the Result-TLV exchange.   Since
password based authentication does not generate a key there is no need for
crypto binding.  It is just treated as a TLV.


>
> 2) [Minor] It is written both "EAP methods **and** basic password
> authentication" and "EAP methods **or**basic password authentication" in
> different sections above. Shouldn't we use the same all the time?
>
> [Joe] It should be consistent. Re-worded slightly:

3. The Intermediate-Result TLVs carry success or failure indications of
each individual EAP authentication method or basic password authentication
in TEAP Phase 2.

And

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages for inner EAP authentication methods or basic
password authentication.


>
> On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey  wrote:
>
>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>> Status: Verified
>> Revision:
>>
>> Section 3.3.2 says:
>>
>> Upon receiving the response, the server
>>indicates the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> It Should say:
>>
>> Upon receiving the response, the server MUST
>>indicate the success or failure of the exchange using an
>>Intermediate-Result TLV.
>>
>> Section 3.6 says:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> the individual EAP methods in TEAP Phase 2.
>>
>> It Should say:
>>
>> 3. The Intermediate-Result TLVs carry success or failure indications of
>> the individual EAP methods and basic password authentication in TEAP Phase
>> 2.
>>
>> Section 4.2.11 says:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages between multiple inner EAP
>> methods within EAP.
>>
>> It Should say:
>>
>> The Intermediate-Result TLV provides support for acknowledged
>> intermediate Success and Failure messages between multiple inner EAP
>> methods or basic password authentication within EAP.
>>
>> Section C.1 says:
>>
>> <- Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> It should say:
>>
>> <- Intermediate-Result-TLV (Success),
>> Crypto-Binding TLV (Request),
>> Result TLV (Success),
>> (Optional PAC TLV)
>>
>>Intermediate-Result-TLV (Success),
>>Crypto-Binding TLV(Response),
>>Result TLV (Success),
>>(PAC-Acknowledgement TLV) ->
>>
>> Section C.2 Says:
>> <- Result TLV (Failure)
>>
>> Result TLV (Failure) ->
>>
>> It Should Say:
>>
>> <- Intermediate-Result-TLV (Failure),
>>  Result TLV (Failure)
>>
>> Intermediate-Result-TLV (Failure),
>>Result TLV (Failure) ->
>>
>>
>> Notes:
>>
>> Section 3.3.2 implies that Intermediate-Result TLV is used after each
>> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
>> in C.1 does not show this. The proposed change in this errata adds the
>> Intermediate-Result TLV indication here. Similar change should be done in
>> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
>> include Result TLV) since the language in 3.3.2 describe the indication to
>> be used for both success and failure cases.
>>
>> In addition to this change in C.1, it would be good to clarify the
>> specification globally to avoid confusion about this case since almost all
>> discussion regarding Intermediate-Result TLV currently is in the context of
>> inner EAP authentication. 3.3.2 should have a MUST statement similar to
>> 3.3.1. 3.6 should cover success or failure indications of basic pa

Re: [Emu] Proposed Resolution for Errata 5845

[Joseph Salowey]

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 5767 that not all EAP methods are EAP
> authentication methods, to be exact. In the proposed fix for errata 5767
> you have already suggested that for Section 3.3.1 text:
>
> >Section 3.3.1
> >
> >It should say:
>
> >   EAP method messages are carried within EAP-Payload TLVs defined in
> >   Section 4.2.10.  Upon completion of each EAP authentication method in
> >   the tunnel, the server MUST send an Intermediate-Result TLV
> >   indicating the result.
>
>
[Joe] Yes, I think you are correct.


>
>
> On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey  wrote:
>
>> Errata 5845: https://www.rfc-editor.org/errata/eid5845
>> Proposed Status: Verified
>> Revision:
>>
>> Section 3.3.1 says:
>>
>>EAP method messages are carried within EAP-Payload TLVs defined in
>>Section 4.2.10.  If more than one method is going to be executed in
>>the tunnel, then upon method completion, the server MUST send an
>>Intermediate-Result TLV indicating the result.
>>
>> 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.
>>
>> Notes:
>>
>> Description of whether Intermediate-Result TLV is supposed to be used in
>> the case where only a single inner EAP authentication method is used.
>> Section 3.3.1 says "more than one method is going to be executed in the
>> tunnel, then upon method completion, the server MUST send an
>> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
>> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
>> cryptographic binding after each successful EAP method in a sequence of one
>> or more EAP methods", 4.2.13 says "It MUST be included with the
>> Intermediate-Result TLV to perform cryptographic binding after each
>> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
>> example exchange with a single inner EAP authentication method with use of
>> Intermediate-Result TLV.
>>
>> It looks like the majority of the places discussion this topic implies
>> that there is going to be an Intermediate-Result TLV after each inner EAP
>> authentication method and the text in 3.3.1 is the only clear case of
>> conflicting (or well, at least misleading if one were to claim it does not
>> explicitly say MUST NOT for the one inner EAP authentication method case).
>> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
>> exchanged after each EAP authentication method and the proposed text change
>> to 3.3.1 covers that.
>>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5775

[Joseph Salowey]

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 generated as
>> above from S-IMCK[0].
>
>
> Joe, for me it still doesn't sound as exact enough instructions. We should
> explain how to generate S-IMCK and CMK for no inner method case with more
> details.
>
>
[Joe]  Good catch,  S-IMCK[0] is only 40 octets.   Looking at this I think
it makes more sense to Change

If the ith inner method does not generate an EMSK or MSK, then IMSKi
   is set to zero (e.g., MSKi = 32 octets of 0x00s).


To:

If the jth inner method does not generate an EMSK or MSK, or no inner

  method has been run then IMSK[j] is set to zero (32 octets of 0x00s).




> The Crypto-Binding TLV MUST be exchanged and verified before the
>>  final Result TLV exchange, regardless of whether there is an inner
>>  EAP method authentication or not.
>
> This still remains an open question whether we MUST send Crypto-Binding
> TLV after Basic-Password-Authentication exchange or not. Is
> Basic-Password-Authentication treated just as a case of no inner EAP
> authentication method? It is also discussed in the errata 5844 thread.
>
> [Joe] I don't think so, but let's discuss on the 5844 thread.


> Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you
> think it is unnecessary? So if one peer doesn't export a specific inner
> method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK
> - then the Crypto-Binding TLV exchange will fail naturally. Maybe it's
> worth saying exactly that if the inner method exports MSK or EMSK then each
> peer MUST use it and not Zero-MSK.
>

[Joe]  It doesn't seem to me that the Zero-MSK flag is necessary, I'd
rather not add new signals if we do not need them now.  If a method
generates an MSK then I think it must be used.   We can add a sentence
saying that to the above revision.

 If the jth inner method does not generate an EMSK or MSK, or no inner

 method has been run then IMSK[j] is set to zero (32 octets of 0x00s).

 If a method generates an MSK or EMSK the zero IMSK MUST NOT be used.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5770

[Jorge Vergara]

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, 
but the overall TEAP authentication succeeds. For example, if two inner EAP 
Authentication methods run and the first fails but the seconds succeeds, the 
calculation needs to be valid. Based on the old text, that authentication 
method is omitted from calculations. This is what current implementations do.

My editorial comment based on some other errata would be to that text needs to 
specify “authentication” methods (per Jouni’s other errata) since the Identity 
method doesn’t factor in here. I think it would also be beneficial to be 
specific about the behavior of basic username and password authentication here. 
Oleg made some comments to this effect on another email. Our implementation 
doesn’t support basic username and password authentication so I don’t have any 
prior experience here.

Jorge Vergara

From: Joseph Salowey 
Sent: Saturday, October 24, 2020 5:18 PM
To: EMU WG 
Cc: Oleg Pekar ; Jouni Malinen ; Jorge 
Vergara 
Subject: Proposed Resolution to TEAP Errata 5770

Errata 5770: 
https://www.rfc-editor.org/errata/eid5770
Proposed Status: Verified
Revision:

Section 5.2 Says:

On the sender of the Crypto-Binding TLV side:

 If the EMSK is not available, then the sender computes the Compound
 MAC using the MSK of the inner method.

 If the EMSK is available and the sender's policy accepts MSK-based
 MAC, then the sender computes two Compound MAC values.  The first
 is computed with the EMSK.  The second one is computed using the
 MSK.  Both MACs are then sent to the other side.

 If the EMSK is available but the sender's policy does not allow
 downgrading to MSK-generated MAC, then the sender SHOULD only send
 EMSK-based MAC.

   On the receiver of the Crypto-Binding TLV side:

 If the EMSK is not available and an MSK-based Compound MAC was
 sent, then the receiver validates the Compound MAC and sends back
 an MSK-based Compound MAC response.

 If the EMSK is not available and no MSK-based Compound MAC was
 sent, then the receiver handles like an invalid Crypto-Binding TLV
 with a fatal error.

 If the EMSK is available and an EMSK-based Compound MAC was sent,
 then the receiver validates it and creates a response Compound MAC
 using the EMSK.

 If the EMSK is available but no EMSK-based Compound MAC was sent
 and its policy accepts MSK-based MAC, then the receiver validates
 it using the MSK and, if successful, generates and returns an MSK-
 based Compound MAC.

 If the EMSK is available but no EMSK Compound MAC was sent and its
 policy does not accept MSK-based MAC, then the receiver handles
 like an invalid Crypto-Binding TLV with a fatal error.

If the ith inner method does not generate an EMSK or MSK, then IMSKi
is set to zero (e.g., MSKi = 32 octets of 0x00s).  If an inner method
fails, then it is not included in this calculation.

It Should Say:

On the sender of the Crypto-Binding TLV side:

 If the EMSK is not available, then the sender computes the Compound
 MAC using the CMK generated from MSK (CMK-MSK) of the inner method.

 If the EMSK is available and the sender's policy accepts MSK-based
 MAC, then the sender computes two Compound MAC values.  The first
 is computed with the CMK generated from the EMSK (CMK-EMSK).  The
 second one is computed using the CMK-MSK.  Both MACs are
 then sent to the other side.  This also means the sender must generate
 both EMSK and MSK based S-IMCKs.

 If the EMSK is available but the sender's policy does not allow
 downgrading to CMK-MSK MAC, then the sender SHOULD only send
 a MAC computed from the CMK-EMSK.

   On the receiver of the Crypto-Binding TLV side:

 If the EMSK is not available and an CMK-MSK Compound MAC was
 sent, then the receiver validates the Compound MAC and sends back
 an CMK-MSK Compound MAC response.

 If the EMSK is not available and no CMK-MSK Compound MAC was
 sent, then the receiver handles like an invalid Crypto-Binding TLV
 with a fatal error.

 If the EMSK is available and a CMK-EMSK Compound MAC was sent,
 then the receiver validates it and creates a response Compound MAC
 using the CMK-EMSK.

 If the EMSK is available but no CMK-EMSK Compound MA

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Eliot Lear]

[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 who OCSP is protecting in this case.  It’s
>> protecting the client from the Authentication Server, in theory.
> 
> Yes, from compromises of the Authentication Server via loss of control of 
> private key.

And so the authentication server and OCSP signer being on the same device 
itself represents both a scaling problem and a security problem.  Just imagine 
having to manage all of that.

> 
>>> If the OCSP signer is moved to some TPM then
>>> there is a win.  Not all TPMs can provide the performance required to handle
>>> the server certificate, but resigning an OCSP Staple once every ten minutes
>>> or something shouldn't be a problem.
> 
>> If this is the case, then a public key could be moved into the the TPM just 
>> as easily.
> 
> If the TPM can accomodate thousands of signatures per minute, which fTPMs
> probably can accomodate (same CPU, just different context), then sure.
> Many older, i2c interfaced physical-TPMs do not accomodate that rate.

I’ll admit to only secondary interest in performance.  That is- one can 
optimize around this.  But managing naked public keys of servers themselves is 
not scalable from a key management perspective.


>>> The third is, I think, that the EAP server runs an entirely self-contained
>>> private CA.  The OCSP responder is now clearly an integral part of the local
>>> system.
> 
>> Again, what threat are we protecting against?
> 
> The self-contained CA might have a passphrase, so there is some accomodation
> updating the signing key for new algorithms, etc.  while the trust anchor
> which is distributed is appropriate pessimistic.
> 


I guess the issue I’m having is that stapling is requiring more connectivity 
than may be present, and making it a MUST means that we are making very VERY 
broad deployment assumptions.  It is WAY too early for that.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Russ Housley]

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 anyone put different OCSP signers into different certificates?
> I.e. shard the work?

This could be done by including different AIA certificate extensions, but I am 
not aware of anyone that does so.

> I think that splitting the OCSP reponses to many locations might solve the
> industrial situation well.

One could put multiple id-ad-ocsp entries in the AuthorityInfoAccess extension, 
but this could lead to a relying party trying each one in turn, resulting in a 
long timeout interval.

Russ

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Michael Richardson]

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?

> 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 anyone put different OCSP signers into different certificates?
I.e. shard the work?

I think that splitting the OCSP reponses to many locations might solve the
industrial situation well.
I think that there is also some significant space to tune the validity
periods.

But, I agree with Eliot: the OCSP responder is new.

It seems that maybe SHOULD would appropriate on OCSP.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Michael Richardson]

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 could be provisioned in advance 
for the
>> server to cover for planned maintenance periods.  I don't imagine this 
is in
>> any protocol, but could be added.

> But to what end?  We don’t even know if these devices can reasonably
> deal with any secure notion of time.  Even checking cert expiry is a
> bit questionable in some cases, especially if the cert has been seen
> before, and the device is of someone critical value.  And it’s not
> clear what the value is with a lengthy expiry.

okay, but this is clearly a problem regardless.
Devices without known good time can't do very many useful things, and
probably just could ignore the staple.
But, laptops and mobiles do have good time, and they can do the right thing.

>> 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 dunno, but it is possible as far as I can tell.

>> 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 who OCSP is protecting in this case.  It’s
> protecting the client from the Authentication Server, in theory.

Yes, from compromises of the Authentication Server via loss of control of 
private key.

>> If the OCSP signer is moved to some TPM then
>> there is a win.  Not all TPMs can provide the performance required to 
handle
>> the server certificate, but resigning an OCSP Staple once every ten 
minutes
>> or something shouldn't be a problem.

> If this is the case, then a public key could be moved into the the TPM 
just as easily.

If the TPM can accomodate thousands of signatures per minute, which fTPMs
probably can accomodate (same CPU, just different context), then sure.
Many older, i2c interfaced physical-TPMs do not accomodate that rate.

>> The third is, I think, that the EAP server runs an entirely 
self-contained
>> private CA.  The OCSP responder is now clearly an integral part of the 
local
>> system.

> Again, what threat are we protecting against?

The self-contained CA might have a passphrase, so there is some accomodation
updating the signing key for new algorithms, etc.  while the trust anchor
which is distributed is appropriate pessimistic.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Russ Housley]

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

Russ

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Eliot Lear]

> 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 Servers Certificate
>>> message as long as it is valid. Before the OCSP response is close to
>>> expiring, the EAP server requests a new OCSP response from the OCSP
>>> responder.
> 
>> Right.  What this is saying is that a local deployment MUST run an OCSP
>> responder.  If that OCSP responder is unavailable, then what?  Now
>> imagine we are discussing critical infrastructure where the responder
>> is not in the same room, and there are network connectivity problems.
>> The device joining the network needs local access and that is it.  Does
>> that mean it should not use EAP-TLS?  Or are we saying that they MUST
>> use naked public keys?
> 
> 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 could be provisioned in advance for the
> server to cover for planned maintenance periods.  I don't imagine this is in
> any protocol, but could be added.

But to what end?  We don’t even know if these devices can reasonably deal with 
any secure notion of time.  Even checking cert expiry is a bit questionable in 
some cases, especially if the cert has been seen before, and the device is of 
someone critical value.  And it’s not clear what the value is with a lengthy 
expiry.


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

> 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 who OCSP is protecting in this case.  It’s protecting 
the client from the Authentication Server, in theory.


> If the OCSP signer is moved to some TPM then
> there is a win.  Not all TPMs can provide the performance required to handle
> the server certificate, but resigning an OCSP Staple once every ten minutes
> or something shouldn't be a problem.

If this is the case, then a public key could be moved into the the TPM just as 
easily.

> 
> The third is, I think, that the EAP server runs an entirely self-contained
> private CA.  The OCSP responder is now clearly an integral part of the local
> system.

Again, what threat are we protecting against?

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Michael Richardson]

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 response is close to
>>expiring, the EAP server requests a new OCSP response from the OCSP
>>responder.

> Right.  What this is saying is that a local deployment MUST run an OCSP
> responder.  If that OCSP responder is unavailable, then what?  Now
> imagine we are discussing critical infrastructure where the responder
> is not in the same room, and there are network connectivity problems.
> The device joining the network needs local access and that is it.  Does
> that mean it should not use EAP-TLS?  Or are we saying that they MUST
> use naked public keys?

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 could be provisioned in advance for the
server to cover for planned maintenance periods.  I don't imagine this is in
any protocol, but could be added.

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.
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.  If the OCSP signer is moved to some TPM then
there is a win.  Not all TPMs can provide the performance required to handle
the server certificate, but resigning an OCSP Staple once every ten minutes
or something shouldn't be a problem.

The third is, I think, that the EAP server runs an entirely self-contained
private CA.  The OCSP responder is now clearly an integral part of the local
system.

Do we need to write an Operational Considerations document here?

> For many devices the manufacturers will be unable to predict whether a
> device will or will not have direct access to anything.  It specific to
> deployment circumstances.  Also, running an OCSP server is something
> that will be very new for many enterprises.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Michael Richardson]

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 the client certificate staple would be difficult for
offline clients :-)

> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

Also, consider that an mbedtls EAP client could just not process the OCSP+Staple
for now.  That would be non-compliant, but it would work.
(The opposite for the server is not the case)

> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of
> the Certificate Status Request extension (i.e. OCSP stapling).

> - I do not think there is any wiggle room at all in the current version 
of the draft:

> "When EAP-TLS is used with TLS 1.3, the peer and server MUST use 
Certificate Status Requests [RFC6066]
> for the server's certificate chain"

> Note that in the current draft it is unspecified how the server checks
> the revocation status of the client's certificate:

> "When EAP-TLS is used with TLS 1.3, the server MUST check the
> revocation status of the certificates in the client's certificate chain."

So, OCSP would comply work, but insisting on stapling would be dumb.

> - My view is that OSCP stapling is a very good fit for EAP in
> particular and is well-supported enough to be mandated. Mandating
> stapling for EAP-TLS 1.3 from the start avoids having to rely on the
> X.509 must-staple extension. Any implementation not supporting OCSP
> stapling should implement it together with TLS 1.3. I do not think the
> requirent should be softened, but if it is, my view is that is should
> be softened as little as possible.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Eliot Lear]

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 Servers Certificate message as long as it is 
> valid. Before the OCSP response is close to expiring, the EAP server requests 
> a new OCSP response from the OCSP responder.
> 

Right.  What this is saying is that a local deployment MUST run an OCSP 
responder.  If that OCSP responder is unavailable, then what?  Now imagine we 
are discussing critical infrastructure where the responder is not in the same 
room, and there are network connectivity problems.  The device joining the 
network needs local access and that is it.  Does that mean it should not use 
EAP-TLS?  Or are we saying that they MUST use naked public keys?

> I assume you mean the client is offline? If use cases where none of the 
> entities can contact the OCSP responder is in scope, OCSP stapling does not 
> work.

Right.  So then what?  Fail?

For many devices the manufacturers will be unable to predict whether a device 
will or will not have direct access to anything.  It specific to deployment 
circumstances.  Also, running an OCSP server is something that will be very new 
for many enterprises.

Eliot
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[John Mattsson]

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 EAP server requests a new OCSP 
response from the OCSP responder.

I assume you mean the client is offline? If use cases where none of the 
entities can contact the OCSP responder is in scope, OCSP stapling does not 
work.

OCSP Nonce does not work with OCSP stapling. If you want you revocation data to 
be real-time you need to make an online OCSP request-response to the OCSP 
responder.

John

-Original Message-
From: Eliot Lear 
Date: Monday, 26 October 2020 at 13:16
To: John Mattsson 
Cc: "emu@ietf.org" 
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

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 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 to 
> mandate stapling in the draft instead of waiting for support of the X.509 
> must-staple extension. OCSP and OCSP stapling are quite well supported 
> already and should be even more well-supported in a few years:
> 
> 1. Basically all TLS implementations support OSCP, and a majority support 
> OSCP stapling (Certificate Status Request). Mbed is an exception rather than 
> the rule.
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> 2. All browsers (desktop and mobile) support OCSP stapling.
> 
> https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).
> 
> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
> Certificate Status Request extension (i.e. OCSP stapling).
> 
> 
> - I do not think there is any wiggle room at all in the current version of 
> the draft:
> 
>  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
> Status Requests [RFC6066]
>for the server's certificate chain"
> 
>  Note that in the current draft it is unspecified how the server checks the 
> revocation status of the client's certificate:
> 
>  "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation 
> status of the certificates in the
>client's certificate chain."
> 
> 
> - The X.509 must-staple extension 
> (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
> for server certificates in the current EAP-TLS 1.3 draft as stapling is 
> already a must. OSCP stapling is not very useful for client certs. I do not 
> know if the X.509 must-staple extension is well supported or not. It could 
> become relevant for server certs if the requirements are softened.
> 
> 
> - My view is that OSCP stapling is a very good fit for EAP in particular and 
> is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 
> from the start avoids having to rely on the X.509 must-staple extension. Any 
> implementation not supporting OCSP stapling should implement it together with 
> TLS 1.3. I do not think the requirent should be softened, but if it is, my 
> view is that is should be softened as little as possible.
> 
> Cheers,
> John
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Eliot Lear]

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 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 to 
> mandate stapling in the draft instead of waiting for support of the X.509 
> must-staple extension. OCSP and OCSP stapling are quite well supported 
> already and should be even more well-supported in a few years:
> 
> 1. Basically all TLS implementations support OSCP, and a majority support 
> OSCP stapling (Certificate Status Request). Mbed is an exception rather than 
> the rule.
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> 2. All browsers (desktop and mobile) support OCSP stapling.
> 
> https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).
> 
> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
> Certificate Status Request extension (i.e. OCSP stapling).
> 
> 
> - I do not think there is any wiggle room at all in the current version of 
> the draft:
> 
>  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
> Status Requests [RFC6066]
>for the server's certificate chain"
> 
>  Note that in the current draft it is unspecified how the server checks the 
> revocation status of the client's certificate:
> 
>  "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation 
> status of the certificates in the
>client's certificate chain."
> 
> 
> - The X.509 must-staple extension 
> (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
> for server certificates in the current EAP-TLS 1.3 draft as stapling is 
> already a must. OSCP stapling is not very useful for client certs. I do not 
> know if the X.509 must-staple extension is well supported or not. It could 
> become relevant for server certs if the requirements are softened.
> 
> 
> - My view is that OSCP stapling is a very good fit for EAP in particular and 
> is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 
> from the start avoids having to rely on the X.509 must-staple extension. Any 
> implementation not supporting OCSP stapling should implement it together with 
> TLS 1.3. I do not think the requirent should be softened, but if it is, my 
> view is that is should be softened as little as possible.
> 
> Cheers,
> John
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[John Mattsson]

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 to mandate 
stapling in the draft instead of waiting for support of the X.509 must-staple 
extension. OCSP and OCSP stapling are quite well supported already and should 
be even more well-supported in a few years:

1. Basically all TLS implementations support OSCP, and a majority support OSCP 
stapling (Certificate Status Request). Mbed is an exception rather than the 
rule.

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

2. All browsers (desktop and mobile) support OCSP stapling.

https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).

3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
Certificate Status Request extension (i.e. OCSP stapling).


- I do not think there is any wiggle room at all in the current version of the 
draft:

  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
Status Requests [RFC6066]
for the server's certificate chain"

  Note that in the current draft it is unspecified how the server checks the 
revocation status of the client's certificate:
  
  "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation 
status of the certificates in the
client's certificate chain."


- The X.509 must-staple extension 
(https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
for server certificates in the current EAP-TLS 1.3 draft as stapling is already 
a must. OSCP stapling is not very useful for client certs. I do not know if the 
X.509 must-staple extension is well supported or not. It could become relevant 
for server certs if the requirements are softened.


- My view is that OSCP stapling is a very good fit for EAP in particular and is 
well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 from 
the start avoids having to rely on the X.509 must-staple extension. Any 
implementation not supporting OCSP stapling should implement it together with 
TLS 1.3. I do not think the requirent should be softened, but if it is, my view 
is that is should be softened as little as possible.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution for Errata 5845

[Oleg Pekar]

>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 be exact. In the proposed fix for errata 5767
you have already suggested that for Section 3.3.1 text:

>Section 3.3.1
>
>It should say:

>   EAP method messages are carried within EAP-Payload TLVs defined in
>   Section 4.2.10.  Upon completion of each EAP authentication method in
>   the tunnel, the server MUST send an Intermediate-Result TLV
>   indicating the result.



On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey  wrote:

> Errata 5845: https://www.rfc-editor.org/errata/eid5845
> Proposed Status: Verified
> Revision:
>
> Section 3.3.1 says:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
> 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.
>
> Notes:
>
> Description of whether Intermediate-Result TLV is supposed to be used in
> the case where only a single inner EAP authentication method is used.
> Section 3.3.1 says "more than one method is going to be executed in the
> tunnel, then upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
> cryptographic binding after each successful EAP method in a sequence of one
> or more EAP methods", 4.2.13 says "It MUST be included with the
> Intermediate-Result TLV to perform cryptographic binding after each
> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
> example exchange with a single inner EAP authentication method with use of
> Intermediate-Result TLV.
>
> It looks like the majority of the places discussion this topic implies
> that there is going to be an Intermediate-Result TLV after each inner EAP
> authentication method and the text in 3.3.1 is the only clear case of
> conflicting (or well, at least misleading if one were to claim it does not
> explicitly say MUST NOT for the one inner EAP authentication method case).
> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
> exchanged after each EAP authentication method and the proposed text change
> to 3.3.1 covers that.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Oleg Pekar]

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 structure? (Only Zero-MSK Crypto-Binding TLV is possible in
this case, the same as in no inner method case). Is
Basic-Password-Authentication treated as a case of no inner method?
Technically it is already correct but still may not be clear enough.

This also affects section "4.2.13. Crypto-Binding TLV":

The Crypto-Binding TLV MUST be exchanged and verified before the final
Result TLV exchange, regardless of whether there is an inner EAP
method authentication or not.

Shouldn't we mention "inner EAP method or basic password authentication"?

2) [Minor] It is written both "EAP methods **and** basic password
authentication" and "EAP methods **or**basic password authentication" in
different sections above. Shouldn't we use the same all the time?


On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey  wrote:

> Errata 5844: https://www.rfc-editor.org/errata/eid5844
> Status: Verified
> Revision:
>
> Section 3.3.2 says:
>
> Upon receiving the response, the server
>indicates the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> It Should say:
>
> Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> Section 3.6 says:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> the individual EAP methods in TEAP Phase 2.
>
> It Should say:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> the individual EAP methods and basic password authentication in TEAP Phase
> 2.
>
> Section 4.2.11 says:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages between multiple inner EAP methods within EAP.
>
> It Should say:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages between multiple inner EAP methods or basic
> password authentication within EAP.
>
> Section C.1 says:
>
> <- Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> It should say:
>
> <- Intermediate-Result-TLV (Success),
> Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Intermediate-Result-TLV (Success),
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> Section C.2 Says:
> <- Result TLV (Failure)
>
> Result TLV (Failure) ->
>
> It Should Say:
>
> <- Intermediate-Result-TLV (Failure),
>  Result TLV (Failure)
>
> Intermediate-Result-TLV (Failure),
>Result TLV (Failure) ->
>
>
> Notes:
>
> Section 3.3.2 implies that Intermediate-Result TLV is used after each
> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
> in C.1 does not show this. The proposed change in this errata adds the
> Intermediate-Result TLV indication here. Similar change should be done in
> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
> include Result TLV) since the language in 3.3.2 describe the indication to
> be used for both success and failure cases.
>
> In addition to this change in C.1, it would be good to clarify the
> specification globally to avoid confusion about this case since almost all
> discussion regarding Intermediate-Result TLV currently is in the context of
> inner EAP authentication. 3.3.2 should have a MUST statement similar to
> 3.3.1. 3.6 should cover success or failure indications of basic password
> auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
> is used with both inner EAP and basic password auth.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5775

[Oleg Pekar]

>
> 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 still doesn't sound as exact enough instructions. We should
explain how to generate S-IMCK and CMK for no inner method case with more
details.

The Crypto-Binding TLV MUST be exchanged and verified before the
>  final Result TLV exchange, regardless of whether there is an inner
>  EAP method authentication or not.

This still remains an open question whether we MUST send Crypto-Binding TLV
after Basic-Password-Authentication exchange or not. Is
Basic-Password-Authentication treated just as a case of no inner EAP
authentication method? It is also discussed in the errata 5844 thread.

Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you
think it is unnecessary? So if one peer doesn't export a specific inner
method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK
- then the Crypto-Binding TLV exchange will fail naturally. Maybe it's
worth saying exactly that if the inner method exports MSK or EMSK then each
peer MUST use it and not Zero-MSK.

>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu