I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe that
compared with the -06 text, this version has taken a step backwards. My
read of the -07 changes are that they remove obligations for RFC
conformant certificate validation and authorization, making RFC 2716bis
less secure than RFC 2
Joe - For some reason I didn't get your email, I found it on the
archives; bellow are the questions from that mail and my answers:
Where the subjectAltName field is present in the peer or
Server certificate, the Peer-Id or Server-Id MUST be set
to the contents of the s
Comments in-line
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 06, 2007 8:35 AM
To: Ryan Hurst; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
Hi Ryan,
I understand the deprecation of subjectName in favor of
I am not sure the MAC address is directly relevant to this effort, as
long as we allow for alternate bindings to be used (I think the text I
proposed does this) then these problems can be dealt with in other
documents.
As for the MAC address as a identifier, I actually am not a fan; from
what I ca
Hi Joe, even more comments in-line:
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 7:38 AM
To: Ryan Hurst; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
Comments inline below.
> -Origi
I will do this before I go home today.
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 12:27 PM
To: emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
If possible, I'd like to include text arising from this thread in
etion, peer
implementations SHOULD also support checking for certificate
revocation after authentication completes and network connectivity
is available, and SHOULD utilize this capability.
"
-Original Message-----
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Wednesday, F
Since I am new to this list and don't know the PKI background here I
thought I would provide a few links to help with this discussion:
OCSP - http://www.ietf.org/rfc/rfc2560.txt
TLS Extensions - http://www.ietf.org/rfc/rfc4366.txt
Additionally I wanted to talk about the rationale behind this (alt
e probably
the best bests but I need to think about it more.
Ryan
-Original Message-
From: Ray Bell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 2:32 PM
To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';
emu@ietf.org
Subject: RE: [Emu] RE: dra
In-line
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 10:42 AM
To: Ryan Hurst; Ray Bell; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> -Original Message-
> From: Ryan
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 5:53 PM
To: Ryan Hurst; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
Hi Ryan,
Looks pretty good, two comments inline below.
Joe
In-line
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 4:15 PM
To: Ryan Hurst; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> >If subject naming information is present in o
In-line
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 10:03 PM
To: emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
>From the discussion it seems that if OCSP is a SHOULD implement, then
we
need a MUST for revocatio
Sounds like a good compromise.
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Tue 2/20/2007 9:53 PM
To: Ryan Hurst; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> The subject field identifies the entity associated with
in-line
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Tue 2/20/2007 8:54 PM
To: Ryan Hurst; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
>
>If subject naming information is present only
in-line
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Wed 2/21/2007 9:04 AM
To: Ryan Hurst; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
>If subject naming information is present only
I started work on some but it will take me a few days to get to finishing it, I
sugest we leave it out here and include text in a appendix to cover it.
Ryan
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Wed 2/21/2007 9:51 AM
To: [EMAIL PROTECTED]; Ryan
should the device identity go.
And to that end, if that identity is a MAC address what are the security
concerns.
Ryan
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Wed 2/21/2007 9:56 AM
To: Bernard Aboba; Ryan Hurst; emu@ietf.org
Subject
[Joe] I don't see any more confusion over having
multiple serial numbers than having multiples of any other attribute.
[rmh] The point I have been failing to make is that
these other ids are not expected to match a explicit entity, they are
really not much more t
I have not seen Steve on this list (though he might be), so I have added
him to this thread.
I have looked at TTLS and think it's a good method, I would be
interested in supporting participating in work to address the outlined
short comings if such a project were to be kicked off by Juniper in the
I believe there were many issues with how PEAP progressed, if we are
careful we could prevent the same things from happening with TTLS.
Ryan
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 12:36 PM
To: Bernard Aboba; emu@ietf.org
I totally agree, I would hate to see us define yet another tunneling eap method
if we could add a couple extensions to a existing one that has received
reasonable adoption already.
If it turns out we had to define a totally new non-backwards compatible
protocol I would agree we would probably
Thanks Steve, that was my understanding also.
Is it also true that there are no implementations of TTLSv1?
Ryan
-Original Message-
From: Stephen Hanna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:46 AM
To: Sam Hartman; Tschofenig, Hannes
Cc: [EMAIL PROTECTED]; emu@ietf.org
I can easily see how crypto-binding could be added to the protocol
without breaking backwards compatibility, eg how negotiation via
TTLSv0's extensibility model could add this in as a optional operation
that the client and server agree upon.
In general I think having a standards based, interoperab
I thought folks on these two lists might be interested in this,
Microsoft will be having a web chat next week discussing its EAP
platform if you want to know more about our implementation and how you
can integrate with it this is probably a interesting talk.
See:
http://blogs.technet.com/nap/ar
Yup, specifically 3280 says that a issuer, as represented by its DN will
guarantee unique serial numbers within its scope and issue within its
scope non-ambiguous subject DNs (e.g. no dupes).
-Original Message-
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 1:14
Yes that time is correct, 3:00 PM PST.
From: Glen Zorn (gwz) [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 07, 2007 12:15 AM
To: Ryan Hurst
Cc: emu@ietf.org; [EMAIL PROTECTED]
Subject: RE: [Emu] Talk on Windows EAP implementation...
I thought folks on these two lists might be interested
I agree that if there is not a standards based approach to choose
proprietary solutions will be implemented, I also agree that addressing
the password based authentication is not the only problem here.
I also think there is need for a standards based tunneled EAP method
also.
I for one support th
Yes, I noticed this recently too; I think thats a good addition.
Ryan
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Tue 6/5/2007 9:41 PM
To: emu@ietf.org
Subject: [Emu] Issue: Validation of server certificates in Section 5.3 of RFC
2716bis
I was looking
eaf.
Ryan
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 06, 2007 11:11 AM
To: Ryan Hurst; Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] Issue: Validation of server certificates in Section
5.3 ofRFC 2716bis
Looks fine to me. Any particu
I think this is a good clarification.
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 06, 2007 2:21 PM
To: emu@ietf.org
Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id
Issue
Also, it has been pointed out that the purpose of the
Your right, there can be only one distinguished name.
However there are also cases where there are more than one
subjectAltName may be present with a empty DN also; I don't think
mandating a DN is a good idea since 3280 doesn't do that.
Ryan
-Original Message-
From: Joseph Salowey (jsal
I think these changes are good.
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Tue 6/19/2007 1:20 PM
To: Bernard Aboba; gabriel montenegro; emu@ietf.org
Cc: Bernard Aboba
Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
> -Original Mes
I agree, I also want to see PEAPv0 published for the same reasons (I am
working on a draft of this, no ETA I can share at this time).
-Original Message-
From: Alan DeKok [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: emu@ietf.org
Subject: Re: [Emu]
: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 9:57 AM
To: Alan DeKok; Stephen Hanna
Cc: emu@ietf.org
Subject: RE: [Emu] Crypto-binding in TTLS-v0
I agree, I also want to see PEAPv0 published for the same reasons (I am
working on a draft of this, no ETA I can share at this
I also favor #2, I like Steve have found customers reluctant to deploy
new methods if we can satisfy the goals with a method that's broadly
deployed (with some tweaks) I think we will have more success than if we
define a new one.
-Original Message-
From: Ray Bell [mailto:[EMAIL PROTECTED]
36 matches
Mail list logo
