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
-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
Jim:
Thanks for reviewing
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
* 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.
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 Schaad
Cc: 'Sam Hartman'; emu
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)
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
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 i...@augustcellars.com wrote:
1. After the first exchange
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
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; draft-ietf-emu-eap
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
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 that
-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.
Other comments
1. I think
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
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.
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
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
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
-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
Jim:
Please see comments below
-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
Jim:
Thanks for the review. Please
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
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 i...@augustcellars.com wrote:
-Original Message
-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 is the current thinking
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
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
. 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
To: emu@ietf.org
-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 no comments that I would consider
[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've included a survey of tunnel methods that have
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
-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; emu@ietf.org
Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
Joseph == Joseph Salowey (jsalowey
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
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
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
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
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:
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)
> -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.
>
>
> -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
m: 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-
> tls13-03.txt
>
>
>
> &
> -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!
>
> ---
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
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
> -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 finally getti
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
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
for 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
-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
-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
: 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
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
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
54 matches
Mail list logo