On Mar 11, 2019, at 12:52 PM, John Mattsson wrote:
> There seems to be agreement on the list to add security considerations on
> authorization and resumption. With the text from Alan as a basis (thanks
> again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
>
> Some high le
Hi,
There seems to be agreement on the list to add security considerations on
authorization and resumption. With the text from Alan as a basis (thanks again
Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
Some high level changes from Alas text:
- Some considerations also
On Mar 10, 2019, at 1:27 PM, Michael Richardson wrote:
>
> If there is no legit use case for TLS resumption, then it seems that EAP
> servers SHOULD disable TLS resumption.
There are very many use-cases for TLS resumption.
The point is that all of these use-cases require additional informat
If there is no legit use case for TLS resumption, then it seems that EAP
servers SHOULD disable TLS resumption.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Emu mailing lis
I would totally agree that this type of guidance needs to be added to this
document.
Jim
> -Original Message-
> From: Alan DeKok
> Sent: Sunday, March 10, 2019 5:58 AM
> To: Jim Schaad
> Cc: Michael Richardson ; EMU WG
>
> Subject: Re: [Emu] Notes on session resu
On Mar 9, 2019, at 7:46 PM, Jim Schaad wrote:
> Yes - The resumption credential is on the user's device and on the TLS
> server. If the user's device moves then things are just fine. Again, the
> TLS server would need to check the credentials from the cached session
My point is that neither R
> -Original Message-
> From: Emu On Behalf Of Michael Richardson
> Sent: Saturday, March 9, 2019 3:51 PM
> To: 'EMU WG'
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
>
>
> Jim Schaad wrote:
> > I am fin
On Mar 9, 2019, at 6:50 PM, Michael Richardson wrote:
> I have been following along the discussion, and I think that I missed the use
> case.
> Why are we having this discussion?
It's good to understand the edge conditions of the protocol. Otherwise, it
might have designed-in flaws. Or, imp
Jim Schaad wrote:
> I am finally getting caught up on this thread and I have found it to be
very
> frustrating because it appears to make an assumption which I do not
believe
> is warranted.
> I do not see any problems with allowing TLS session to be used across
> different
.
Jim
> -Original Message-
> From: Emu On Behalf Of Alan DeKok
> Sent: Thursday, March 7, 2019 5:41 PM
> To: Arran Cudbard-Bell
> Cc: EMU WG
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
>
> On Mar 6, 2019, at 9:40 PM,
On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell
wrote:
> 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session
> tickets in TLS 1.3.'
>
> I know it's pedantic, but RFC 8446 obsoletes RFC 5077.
Sure.
>> Any authorization applied during resumption MUST be done using the
>>
> The solution to this conundrum is to associate authentication
> credentials and authorization information with the original
> authentication. That information can then be obtained and applied
> during resumption.
>
> There are two ways to make this association. The first method is v
Thanks for the suggested security consideration Alan! This helps a lot!
I'll will work with updating the draft during the next days. Your suggested
text look very good at a first readthrough.
Cheers,
John
___
Emu mailing list
Emu@ietf.org
https://ww
Here's my $0.02 on updates to the "Security Considerations" section.
---
5.9. Authorization
We note that EAP-TLS may be encapsulated in other protocols, such as
PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA
[RFC5191]. Systems implementing those protocols can make polic
On Feb 22, 2019, at 7:47 PM, Arran Cudbard-Bell
wrote:
>
>
>> In my opinion, the document MUST give guidance for implementors and site
>> administrators:
>>
>> * if resumption is used, the implementation MUST cache sufficient
>> information for the system to make appropriate policy decisions
> In my opinion, the document MUST give guidance for implementors and site
> administrators:
>
> * if resumption is used, the implementation MUST cache sufficient information
> for the system to make appropriate policy decisions on resumption
Maybe something about not relying on the outer ide
On Feb 22, 2019, at 2:46 AM, John Mattsson wrote:
>
> I think Section 2.2 of RFC 5216 do discuss this issue, but it does not
> explicitly mention resumption. The text is also too soft.
I think that section discusses an entirely different issue, that has nothing
to do with resumption.
> Sug
Alan DeKok ;; wrote:
>This security bug was completely missed in RFC 5216. This new draft should
>rectify that error.
>
>i.e. using an NAI of "example.org" in the first session, and "example.com" in
>the second session.
>
>Not only is this entirely permitted by the current spec, it's not
Agree 100% Alan. Now is the time to fix this.
-Original Message-
From: Emu on behalf of Alan DeKok
Date: Wednesday, February 20, 2019 at 9:03 AM
To: John Mattsson
Cc: "emu@ietf.org"
Subject: Re: [Emu] Notes on session resumption with TLS-based EAP methods
> On Feb 2
> On Feb 20, 2019, at 8:53 AM, John Mattsson wrote:
> draft-ietf-emu-eap-tls13 is actually very careful to not talk about "session
> resuption", it talks about "resumption". The reason is that "session" is not
> well defined and probably not the same in TLS and EAP. In TLS 1.2 or earlier,
> "
Alan DeKok ; wrote:
>The issue with session resumption is much larger than just the EAP method.
>This subject should ideally be discussed in the "Security Considerations"
>section of the new EAP-TLS draft.
I agree
>i.e. We should define precisely what a "session" is.
>
>Right now, the draft t
On Feb 18, 2019, at 1:49 AM, Arran Cudbard-Bell
wrote:
>> I can't think of any deployment which allows unauthenticated EAP-TLS. Or
>> authenticated only via the NAI.
>
> HS 2.0 Release 2 section 7.7 (Anonymous EAP-TLS)
Ah... I had forgotten about that.
> Regarding anonymous outer identiti
> On Feb 9, 2019, at 1:17 AM, Alan DeKok wrote:
>
> On Feb 8, 2019, at 7:21 AM, John Mattsson wrote:
>> (Everything below is from a pure EAP-TLS (0x0d) perspective without
>> considering any cross-method things)
>>
>> - From an EAP-TLS perspective, I think these two cases ("not authenticated
On Feb 8, 2019, at 7:21 AM, John Mattsson wrote:
> (Everything below is from a pure EAP-TLS (0x0d) perspective without
> considering any cross-method things)
>
> - From an EAP-TLS perspective, I think these two cases ("not authenticated"
> and "authenticate via some other means") are the same,
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Mohit Sethi M ; wrote:
>
>For me, an EAP-TLS server should not only refuse resumption if a client
>was not authenticated, it should also refuse resumption if the client
>was authenticated with other methods than
On Feb 7, 2019, at 4:26 AM, Mohit Sethi M wrote:
>
> Hi Alan, John,
> ...
> For me, an EAP-TLS server should not only refuse resumption if a client
> was not authenticated, it should also refuse resumption if the client
> was authenticated with other methods than certificates (such as passwords
Hi Alan, John,
On 2/6/19 2:44 PM, Alan DeKok wrote:
> On Feb 6, 2019, at 3:54 AM, John Mattsson wrote:
>> I think this is a very good discussion to have. Any problems with peer
>> authentication would (at least in theory) affect pure EAP-TLS as well. RFC
>> 5216 states that:
>>
>> RFC 5216: "Wh
On Feb 6, 2019, at 3:54 AM, John Mattsson wrote:
>
> I think this is a very good discussion to have. Any problems with peer
> authentication would (at least in theory) affect pure EAP-TLS as well. RFC
> 5216 states that:
>
> RFC 5216: "While the EAP server SHOULD require peer authentication, t
I think this is a very good discussion to have. Any problems with peer
authentication would (at least in theory) affect pure EAP-TLS as well. RFC 5216
states that:
RFC 5216: "While the EAP server SHOULD require peer authentication, this is not
mandatory, since there are circumstances in which p
On Feb 5, 2019, at 11:16 AM, Mohit Sethi M wrote:
>
> Peer/Client authentication in stage 1 of EAP-TTLS is optional. So there
> is probably no difference if you do EAP-TLS first and then possibly use
> EAP-TTLS resumption.
OK.
> But the other way, EAP-TTLS/EAP-PEAP first and then
> EAP-TLS
Hi Alan,
On 2/5/19 5:48 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote:
>> But session resumption is not simply about changing one byte in the EAP
>> conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03
>> (https://tools.ietf.org/html/draft-ietf-emu-eap-t
On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote:
>
> But session resumption is not simply about changing one byte in the EAP
> conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03
> (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03), a server is
> issuing a NewSessionTi
Hi Alan,
On 2/5/19 3:13 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote:
>> Do you have experience with such cross method resumption? Are there any
>> deployments that make use of this?
>There are no deployments that make use of it. It's worked in my testing.
>
>> My
On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote:
> Do you have experience with such cross method resumption? Are there any
> deployments that make use of this?
There are no deployments that make use of it. It's worked in my testing.
> My initial reaction is that such cross method session re
Hi Alan,
Do you have experience with such cross method resumption? Are there any
deployments that make use of this?
My initial reaction is that such cross method session resumption should
be forbidden. That is because EAP-TLS has different security properties
where both the peer and server are
On Feb 2, 2019, at 12:03 PM, John Mattsson wrote:
> Good suggestion, I'll add something like that to the resumption section in
> draft-ietf-emu-eap-tls13
Thanks.
>> e.g. TTLS and PEAP both allow session resumption, and when done, skip the
>> phase 2 / inner-tunnel authentication.
>
> That s
Alan DeKok ; wrote:
>I would suggest then referencing or duplicating the above text, and saying
>something like:
>
>---
>Implementations SHOULD be capable of session resumption across different
>TLS-based EAP types. This recommendation is made for a few reasons. It is
>recommended by [RFC7301
On Feb 2, 2019, at 6:50 AM, John Mattsson wrote:
> Very good that this is discussed and highlighted.
>
> My understanding is that TLS itself clearly allows a resumed connection to be
> used for a completely different purpose. The ALPN specification (RFC 7301)
> says that:
>
> "When session res
Hi Alan,
Very good that this is discussed and highlighted.
My understanding is that TLS itself clearly allows a resumed connection to be
used for a completely different purpose. The ALPN specification (RFC 7301) says
that:
"When session resumption or session tickets [RFC5077] are used, the pre
39 matches
Mail list logo
