I have gathered these comments over time and therefore some of them are not
fully fleshed out. If you have any questions I will try and reconstruct my
ideas at the time.
Jim
Version Negotiation - terminate the conversation - w or w/o a fail?
Edge case - what if peer only supports a hig
> -Original Message-
> From: Hao Zhou [mailto:hz...@cisco.com]
> Sent: Wednesday, October 19, 2011 12:31 PM
> To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
> Cc: emu@ietf.org
> Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft
>
&
I want to make sure that we have distinguished between the two statements
1. The server says that I don't support these specific attributes and
2. The server does not tell me that it did or did not do matching of some
attributes.
The first I think is totally optional, but the second is necessar
* In section 5.1 (para 3) - The following sentence does not make sense to
me.
Message i2 is the information the AAA server receives from the last hop
in the AAA proxy chain which is not necessarily the authenticator.
Specifically I do not follow the last clause and what it is referring to.
A
I should probably read it when I am not so tired and distracted, however I
believe that all of my issues have been addressed in the last version
Jim
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
There is one other item that is also worrying me about this.
In doing the check of certificates, one should be doing revocation checking.
However if one is trying to get network access, one cannot independently
download the revocation information until access is granted, and one cannot
get access
TLS can present an OCSP response for the end certificate, if you have
TA->CA1->EE then you can't get it for the CA1 certificate.
Jim
> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> Sent: Saturday, February 18, 2012 11:28 AM
> To: Jim Sc
Sam et al,
1. In section 1 after the Classic Tunnel Attack figure, I believe there are
three methods listed as possible mitigation strategies, however I don't
understand how the second one - a sufficiently strong inner method - could
possibly be a mitigation by itself. The three I see are 1) Poli
1. After the first exchange of messages, if the version does not match the
agreed on version - what happens?
2. Section 3.2 says that one should be able to do a renegotiate for getting
the peers identity certificate. Do the following points need to be made?
a) If you are doing a re-negotiation
> -Original Message-
> From: Hao Zhou [mailto:hz...@cisco.com]
> Sent: Wednesday, March 21, 2012 11:26 AM
> To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
> Cc: emu@ietf.org
> Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02
>
> Jim:
>
6 AM
> To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
> Cc: emu@ietf.org
> Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02
>
> Jim:
>
> Thanks for the detailed review. My comments are below inline:
>
>
> On 3/21/12 6:15 AM, "Jim Schaad&quo
In the presentation you stated that the plan was to make the TLVs that are
requested become a sub TLV of the request TLV items. If that is true, then
should it be possible to allow for multiple request TLVs to be present in a
message. Thus one could say:
Please do A - and if not then fail authe
of
the requested items has been processed and the server has signaled it wants
to end the EAP conversation.
Jim
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Hao Zhou
> Sent: Monday, April 02, 2012 4:29 AM
> To: Jim Schaad;
In the Plasma work effort we have spent much of the last month thinking
about and doing some discussions on the question of delegated access. In
the process we have located the following SAML document
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cs-01.
pdf which discusses
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Sam Hartman
> Sent: Thursday, June 28, 2012 11:06 AM
> To: zhou.suj...@zte.com.cn
> Cc: hartmans-i...@mit.edu; emu@ietf.org
> Subject: Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
>
> >
Version 0 of the document is not ready for a last call as security
considerations are missing.
Other comments
1. I think in figure #1, there would be improved clarity if the line for
Pear initiates connection to a service would have the following under the
attacker line "-->|<--" to indicate t
to:emu-boun...@ietf.org] On Behalf Of
> Jim Schaad
> Sent: Tuesday, September 25, 2012 9:11 PM
> To: emu@ietf.org
> Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00
>
> Version 0 of the document is not ready for a last call as security
> considerations are missing.
&g
1. In section 3.2.3, it says that a new PAC can be requested after a full
TLS handshake. Can one be requested following an abbreviated handshake? Or
do you just re-use the existing PAC?
2. Section 3.3 s/descried/described/
3. Section 3.4 - Is it possible to have multiple server ids after the
I agree that the IMSK needs to take into account the existence of the EMSK,
however the current text has a severe problem with the way that it is done.
It assumes that if the EMSK is exportable on one side, then it will be
exportable on the other side as well. I don't believe this is the case.
In
1. Should the Message Length field be present if the TLS Data field is
absent?
2. There is nothing to say which TLVs can and cannot occur in the Outer
TLVs in any easily findable method. Either a table or the string outer in
descriptions would be helpful. As an example, does the Authority-ID
I found two that I forgot to include in the last message
1. When exporting the user-id, does there need to be a way to distinguish
at export time between the different types of ids that are authenticated by
the server? This does not seem to be an issue on the peer as it will only
do mutual authe
This issue is one that I was dealing with while driving grapes back from the
vineyard yesterday. I don't know that it needs to have any changes in the
draft. I am putting this out to see if there is any controversy on the
decisions that I would make about this issue.
The client is going to use c
Stefan,
Thanks for the input.
For the authors,
Does this need to be documented as a mode of operation for TEAP or are we
going to say that this is not a supported mode?
Jim
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Stefan Winter
> S
> -Original Message-
> From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
> Sent: Thursday, October 04, 2012 3:06 PM
> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
> met...@tools.ietf.org
> Subject: Re: [Emu] More COmments 2 on eap-tunnel-method
>
&
> -Original Message-
> From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
> Sent: Thursday, October 04, 2012 2:56 PM
> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
> met...@tools.ietf.org
> Subject: Re: [Emu] More comments for eap-tunnel-method
>
>
I have no problems with adding the Policy steps to the processing.
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Thursday, October 04, 2012 8:56 PM
To: Jim Schaad; emu@ietf.org
Subject: Re: [Emu] IMSK derivation issue
Jim:
Thanks for pointing out this issue. How about the
> -Original Message-
> From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
> Sent: Monday, October 08, 2012 9:23 PM
> To: Jim Schaad
> Cc: Stefan Winter;
> Subject: Re: [Emu] Client Auth with TLS
>
> I think it is worthwhile to support an mode of oper
: Tuesday, October 09, 2012 11:43 AM
> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
> met...@tools.ietf.org
> Subject: Re: [Emu] More comments for eap-tunnel-method
>
> Jim:
>
> Please see comments inline below.
>
> On 10/8/12 1:11 AM, "Jim Schaad"
> -Original Message-
> From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
> Sent: Tuesday, October 09, 2012 12:46 PM
> To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
> met...@tools.ietf.org
> Subject: Re: [Emu] More comments for eap-tunnel-method
>
> That
I think that picks up all of my current comments. Looking forward to seeing
the draft update.
Jim
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Wednesday, October 10, 2012 11:15 AM
To: Jim Schaad
Cc: emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00
> To: Jim Schaad
> Cc: Stefan Winter;
> Subject: Re: [Emu] Client Auth with TLS
>
>
> On Oct 9, 2012, at 9:35 AM, Jim Schaad wrote:
>
> >
> >
> >> -Original Message-
> >> From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
>
I just wanted to make sure that the mail list had at least the basics of
what I mentioned in the f2f today
1. The document does not appear to have an indicator that the EMSK was or
was not used to generate a confirmation value. I have not done a final
check that this is true but I did try and fi
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Thursday, October 04, 2012 10:39 AM
To: Jim Schaad
Cc: emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00
Jim:
Thanks very much for your detailed review. Please see the comments below. We
will respond
. I don't think point 3 below needs expansion, but I may be too close to
it. If you disagree please let me know.
Jim
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Jim Schaad
> Sent: Wednesday, November 07, 2012 4:48 PM
&
> -Original Message-
> From: Jim Schaad [mailto:jim...@augustcellars.com]
> Sent: Thursday, February 21, 2013 1:10 PM
> To: draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
> Cc: emu@ietf.org
> Subject: Last call comments on emu-eap-tunnel-method-05
>
> I have
Sam,
I made an assumption you were going to do a survey of the existing EAP
methods and compare them against a set of criteria that the document has
outlined.
As an example: outer EAP methods should
1) have channel binding, 2) should talk about TLS certificate naming, 3)
setup for mixing key ma
artman [mailto:hartmans-i...@mit.edu]
> Sent: Sunday, February 24, 2013 10:56 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; emu@ietf.org; draft-ietf-emu-crypto-
> bind...@tools.ietf.org
> Subject: Re: [Emu] crypto binding: why did I want a survey of methods
>
> Hi. I
> -Original Message-
> From: Jim Schaad [mailto:jim...@augustcellars.com]
> Sent: Wednesday, February 27, 2013 5:47 PM
> To: 'draft-ietf-emu-crypto-b...@tools.ietf.org'
> Cc: emu@ietf.org
> Subject: Comments on draft-ietf-emu-crypto-bind-02
>
> Sam et
Sam,
My responses are inline. May not agree with the authors however.
Jim
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Sam Hartman
> Sent: Saturday, February 23, 2013 5:47 PM
> To: emu@ietf.org
> Subject: [Emu] Comments on draft-ietf-em
> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> Sent: Monday, March 04, 2013 6:19 PM
> To: Joseph Salowey (jsalowey)
> Cc: Sam Hartman; Jim Schaad;
> Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
>
> >>>>&g
I have been doing my best not to send this message but it has finally
slipped out.
I keep wondering if we need to do something much more explicit in terms of
both identifying and purposing the certificates that are being used for this
method.
Question #1 - Do we expect that the client certi
Looking for a piece of information.
Are there cases in TLS before 1.3 where the PRF and the MAC are not inferred
from the cipher suite that was negotiated?
I think it would be surprising if the cipher suite was not obtainable. The
question would be if these are ever independent of the suite ther
I can see two problems right off the bat.
1. It does not allow me to use a different salted method for different
people so I can upgrade by salt function piecemeal.
2. It does not allow me to do both SASLprep and salting on the same
password.
Jim
-Original Message-
From: Emu [mailto:
-Original Message-
From: Dan Harkins [mailto:dhark...@lounge.org]
Sent: Tuesday, September 30, 2014 4:25 PM
To: Jim Schaad
Cc: emu@ietf.org
Subject: RE: [Emu] salted EAP-pwd
Hi Jim,
On Tue, September 30, 2014 2:16 pm, Jim Schaad wrote:
> I can see two problems right off the
There are already a couple of things in TLS 1.3 that can be used to address
some of these issues
From: Emu [mailto:emu-boun...@ietf.org] On Behalf Of Bernard Aboba
Sent: Friday, January 19, 2018 9:46 AM
To: emu@ietf.org
Subject: Re: [Emu] EAP-TLS with large certificates
Alan DeKok said:
It is on my long list of documents to review
> -Original Message-
> From: Emu On Behalf Of Mohit Sethi
> Sent: Monday, May 28, 2018 11:54 PM
> To: Alan DeKok ; Joseph Salowey
>
> Cc: emu@ietf.org
> Subject: Re: [Emu] Call for adoption of draft-arkko-eap-rfc5448bis-01.txt
>
> I will revi
Any issues that I have here might have already been raised and discussed. If
so just not that and ignore.
Section 3.4 - I am curious why you did not make the hash function a property of
the HKDF function rather than making it a hard coded value. I would kind of
expect that section 3.4 (top) a
> -Original Message-
> From: Emu On Behalf Of Cappalli, Tim (Aruba
> Security)
> Sent: Wednesday, November 14, 2018 6:49 AM
> To: Alan DeKok
> Cc: emu@ietf.org; John Mattsson
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
> tls13-03.txt
>
> The question was
> -Original Message-
> From: Jari Arkko
> Sent: Wednesday, November 14, 2018 9:47 AM
> To: Jim Schaad
> Cc: emu@ietf.org; draft-ietf-emu-rfc5448...@ietf.org
> Subject: Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis
>
> Thanks for your review, Jim.
>
>
t; From: Emu On Behalf Of Jim Schaad
> Sent: Wednesday, November 14, 2018 10:35 AM
> To: 'Cappalli, Tim (Aruba Security)' ; 'Alan DeKok'
>
> Cc: emu@ietf.org; 'John Mattsson'
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
&g
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 types of EAP assuming that EAP correctly checks the
> -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
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
General Comment: I have a strong tendency to like positive rather than
negative statements in documents, thus the use of MUST rather than MUST NOT.
Additionally, I have a general tendency to like to know what should happen
if a statement is violated. Thus consider the following from section 2.1.1
> -Original Message-
> From: John Mattsson
> Sent: Thursday, March 21, 2019 8:56 AM
> To: Jim Schaad ; draft-ietf-emu-eap-tl...@ietf.org
> Cc: 'EMU WG'
> Subject: Re: Review of draft-ietf-emu-eap-tls13-04
>
> Thanks for the thorough review Jim!
>
the
server based on a really fast read.
Jim
-Original Message-
From: Jouni Malinen
Sent: Sunday, July 28, 2019 12:58 PM
To: John Mattsson
Cc: Alan DeKok ; Jim Schaad
; EMU WG
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
On Thu, Jul 25, 2019 at 10:49:40AM
I am just finally getting caught up on mail for the EMU WG and am getting
this done.
It should probably be clarified that Figure 1has the additional restriction
that the server is not sending any resumption tickets as well.It would
also be better to label the TLS Application Data as the commit
I am going to come down on the side of no PSK should not be supported.
However my issues have nothing to do with how things are implemented and
more to do with the security properties of the EAP method.
When you use certificates, there is no leakage of who the client is as this
is encrypted by TLS
-Original Message-
From: Emu On Behalf Of Rick van Rein
Sent: Wednesday, April 22, 2020 12:52 AM
To: Alan DeKok
Cc: EMU WG
Subject: Re: [Emu] Proposal: SASL over EAP
Hi Alan / EMU,
I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs Eduroam
and I think he has mention
My expectation would be that the third option from Hannes is what should be
done. The commit message should be encrypted and not a plain text message.
Jim
From: Mohit Sethi M
Sent: Monday, July 13, 2020 10:44 AM
To: emu@ietf.org
Cc: Jim Schaad ; Alan DeKok
; j...@w1.fi; Roman
From: Emu On Behalf Of Mohit Sethi M
Sent: Monday, July 13, 2020 11:50 AM
To: Jorge Vergara ; Alan DeKok
; Hannes Tschofenig
Cc: emu@ietf.org
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message
handling
Hi Alan, Jorge, Jim, Hannes,
One octet of plaintext natura
vague
memory that there was an OpenSSL problem involved here but I would not swear to
that. You might be a better description either from John Mattsson or Jouni.
From: Mohit Sethi M
Sent: Friday, July 31, 2020 7:09 AM
To: emu@ietf.org
Cc: Benjamin Kaduk ; Jim Schaad ; Eric
Rescorla
-Original Message-
From: Alan DeKok
Sent: Saturday, August 1, 2020 6:53 AM
To: Jim Schaad
Cc: Mohit Sethi M ; EMU WG ; Benjamin
Kaduk
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote:
>
> Ok – so this issue was rai
: Alan DeKok
Sent: Tuesday, August 4, 2020 10:16 AM
To: Jorge Vergara
Cc: Jim Schaad ; Mohit Sethi M
; EMU WG ; Benjamin Kaduk
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Aug 3, 2020, at 2:23 PM, Jorge Vergara wrote:
>
> ACK that EAP-TLS does not need to keep the conn
64 matches
Mail list logo