On Feb 5, 2019, at 11:17 AM, Mohit Sethi M wrote:
>
> Purely a personal opinion:
>
> Tying the fate of one document to another unless absolutely necessary is
> not a good idea.
I would say that it *is* absolutely necessary to issue simultaneous TLS 1.3
updates for *all* TLS-based EAP method
Purely a personal opinion:
Tying the fate of one document to another unless absolutely necessary is
not a good idea. Just look at the RFC editor queue:
https://www.rfc-editor.org/current_queue.php
There are documents with a MISSREF that were submitted to the RFC editor
in 2014. I certainly don
On Feb 5, 2019, at 10:40 AM, Mohit Sethi M wrote:
>
> One could use the same argument. Those only interested in implementing
> EAP-TLS will be forced to wait while all other methods are being updated.
Yes.
Sorry, but that's a good thing. Revving one EAP method while ignoring the
others i
Hi Alan,
One could use the same argument. Those only interested in implementing
EAP-TLS will be forced to wait while all other methods are being updated.
Anyhow, I don't expect the other document to take 18 months. I look
forward to your submission (and reviewing it once it is available).
--Mo
On Feb 5, 2019, at 12:28 AM, Mohit Sethi M wrote:
>
> The recommendations in this document may be used by all TLS-based EAP
> methods. However, fragmenting large certificates and certificate chains
> into many small messages is less of a problem when only one side
> (server) is authenticating
On Feb 5, 2019, at 12:25 AM, Mohit Sethi M wrote:
>
> Thanks for bringing this up. I agree that we should take this
> opportunity to fix other EAP methods which rely on TLS for the outer
> tunnel. I think that these updates merit a separate document. But I am
> not certain why the two document
Hi John, Alan, and others,
The recommendations in this document may be used by all TLS-based EAP
methods. However, fragmenting large certificates and certificate chains
into many small messages is less of a problem when only one side
(server) is authenticating with certificates.
--Mohit
On 2/
Hi Alan,
Thanks for bringing this up. I agree that we should take this
opportunity to fix other EAP methods which rely on TLS for the outer
tunnel. I think that these updates merit a separate document. But I am
not certain why the two documents need to be published simultaneously?
--Mohit
On
On Feb 3, 2019, at 7:46 AM, John Mattsson wrote:
>
> Based on this discussion I suggest changing the title and the scope of
> draft-ms-emu-eaptlscert
>
> OLD: "Handling Large Certificates and Long Certificate Chains in EAP-TLS"
> NEW: "Handling Large Certificates and Long Certificate Chains in
Based on this discussion I suggest changing the title and the scope of
draft-ms-emu-eaptlscert
OLD: "Handling Large Certificates and Long Certificate Chains in EAP-TLS"
NEW: "Handling Large Certificates and Long Certificate Chains in TLS-based EAP
Methods"
The problem description, discussion,
On Jan 31, 2019, at 11:55 AM, John Mattsson wrote:
>
>> Alan DeKok ; wrote:
>>
>> Hmm... if the changes are too complex, it may be better to have a new
>> document. I have a first draft written, and will be publishing it soon.
>> It's only about 12 pages, but it goes through a lot of detail t
> Alan DeKok ; wrote:
>
> Hmm... if the changes are too complex, it may be better to have a new
> document. I have a first draft written, and will be publishing it soon. It's
> only about 12 pages, but it goes through a lot of detail that is likely not
> relevant for the EAP-TLS document.
>
Ma
On Jan 31, 2019, at 10:13 AM, John Mattsson wrote:
>
> I also strongly agree that all TLS-based EAP methods in use should be capable
> of working with TLS 1.3. You make a very strong case that this need to happen
> as soon as possible and that the most practical approach is to add the
> inform
Hi Alan, David,
I also strongly agree that all TLS-based EAP methods in use should be capable
of working with TLS 1.3. You make a very strong case that this need to happen
as soon as possible and that the most practical approach is to add the
information to draft-ietf-emu-eap-tls13. Just like w
> On Jan 28, 2019, at 12:24 PM, Alan DeKok wrote:
>
> Some guidance would still be useful.
>
> My $0.02 is that the worst thing we could do is to publish EAP-TLS for TLS
> 1.3, and to give no guidance for other TLS-based EAP methods. I have a
> strong preference that *all* TLS-based EAP me
On Jan 28, 2019, at 12:10 PM, John Mattsson wrote:
>
>> Sure. The question then becomes one of encoding. For types < 256, 1 octet
>> is >enough. For others, it should be a 32-bit number in network byte order.
>
> Maybe we can state that it is the EAP Method Type value in network byte order
>Sure. The question then becomes one of encoding. For types < 256, 1 octet is
>>enough. For others, it should be a 32-bit number in network byte order.
Maybe we can state that it is the EAP Method Type value in network byte order
with any leading bytes of value zero removed? Then 13 is encode
On Jan 28, 2019, at 10:29 AM, John Mattsson wrote:
>
> I think you accidently took the key derivation from
> draft-mattsson-eap-tls13-00.
Ah, yes. Every time I look for the draft, Google etc. seem to prefer the -02
for some reason. I'll remember to avoid that.
> According to Section 6.2 o
Hi Alan
I think you accidently took the key derivation from
draft-mattsson-eap-tls13-00. The key derivation in draft-mattsson-eap-tls13-03
is:
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64)
Method-Id=
19 matches
Mail list logo
