[Emu] EMU PSK design team draft available

[Joseph Salowey \(jsalowey\)]

The EMU PSK design team has completed a draft of a Generalized
Pre-Shared Key EAP method for consideration by the EMU working group.
Information on accessing the draft is included at the end of this
message.  Please review this draft and post comments to the EMU working
group list.  

I would like to thank the EMU PSK design team for the hard work put into
this document.  

Joe

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


   Title   : EAP Generalized Pre-Shared Key (EAP-GPSK)
   Author(s)   : C. Clancy, H. Tschofenig
   Filename: draft-clancy-emu-eap-shared-secret-00.txt
   Pages   : 29
   Date: 2006-6-6

This Internet Draft defines an Extensible Authentication Protocol
method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method
is a lightweight shared-key authentication protocol supporting mutual
authentication and key derivation.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-clancy-emu-eap-shared-secret-0
0.txt

To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
   "get draft-clancy-emu-eap-shared-secret-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
   [EMAIL PROTECTED]
In the body type:
   "FILE
/internet-drafts/draft-clancy-emu-eap-shared-secret-00.txt".

NOTE:   The mail server at ietf.org can return the document in
   MIME-encoded form by using the "mpack" utility.  To use this
   feature, insert the command "ENCODING mime" before the "FILE"
   command.  To decode the response(s), you will need "munpack" or
   a MIME-compliant mail reader.  Different MIME-compliant mail
readers
   exhibit different behavior, especially when dealing with
   "multipart" MIME messages (i.e. documents which have been split
   up into multiple messages), so check your local documentation on
   how to manipulate these messages.


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Enhanced EAP-TLS

[Joseph Salowey \(jsalowey\)]

One of our charter items is to develop an enhanced EAP-TLS that can
support features that are not possible to support in a manner that is
backward compatible with RFC2716. 

Some of the potential features on the list include:

1. Additional cipher suites (PSK, Kerberos, ECC)
2. TLS extensions 
3. Channel Bindings
4. Identity protection

Are there additional features that should be supported by an enhanced
TLS?  

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Identity Protection in EAP-TLS

[Joseph Salowey \(jsalowey\)]

I agree that we need to determine what we can get away with and still be
backward compatible.  I think a big issue is whether TLS extensions are
allowed within RFC2716bis.  It may be that extensions will need to be
left for an enhanced EAP-TLS (which the working group needs to define).


Do we know what the client and server implementation problems with TLS
extensions are? 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, June 04, 2006 11:41 AM
> To: emu@ietf.org
> Subject: Re: [Emu] Identity Protection in EAP-TLS
> 
> >Clearly using this within eap-tls would require some specification
> >work, but I think would be preferable to your approach.
> 
> The EMU WG charter states:
> "Backwards compatibility with RFC 2716 is a requirement."
> 
> So I'd like to understand which approach (if any) is backward 
> compatible 
> with existing RFC 2716 implementations.
> 
> EAP-TLS server implementations always request a certificate.  
>  If the client 
> desires privacy, it can choose not to respond to the 
> certificate request.  
> An EAP-TLS server supporting privacy would then bring up the 
> TLS channel and 
> request the certificate again, and a client supporting 
> privacy would comply. 
> However, existing EAP-TLS servers will terminate the connection if a 
> certificate is not provided in response to the first request, 
> so an uplevel 
> client talking to a downlevel server would have to choose between 
> connectivity and privacy, at least on the first attempt.  On 
> subsequent 
> attempts, the uplevel client could choose whether it is 
> willing to hand over 
> its certificate in cleartext and if so, it could connect 
> using the RFC 
> 2716-specified sequence.
> 
> The backward compatibility of the client extension approach 
> depends on the 
> server's reaction to the offering of client extensions.  
> There seems to be 
> an assumption that a downlevel server will ignore the 
> extensions and that 
> therefore the conversation would complete as in RFC 2716.  
> This would allow 
> a client supporting privacy extensions but willing to connect without 
> privacy to successfully authenticate on the first attempt.  
> However, I'm not 
> clear whether the underlying assumption of extension backward 
> compatibliity 
> is actually true or not -- as I understand it, some EAP-TLS server 
> implementations do not react well to extensions.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Draft on EAP-TLS for TLS-PSK

[Joseph Salowey \(jsalowey\)]

Below is an announcement for a draft that I missed that may be pertinent
to some of the discussions in the working group.  It looks like it
addresses using EAP-TLS with PSK based cipher suites. 

Joe


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


   Title   : The EAP-TLS-PSK Authentication Protocol
   Author(s)   : T. Otto, H. Tschofenig
   Filename: draft-otto-emu-eap-tls-psk-00.txt
   Pages   : 28
   Date: 2006-4-20

The Extensible Authentication Protocol (EAP), defined in RFC 3748, is
a network access authentication framework which provides support for
multiple authentication methods.  One proposal is EAP-TLS, which
relies on the Transport Layer Security (TLS) protocol and allows for
certificate-based authentication.  This document specifies EAP-TLS-
PSK, which also relies on TLS, but allows for shared secret-based
authentication.  EAP-TLS-PSK supports the pre-shared key ciphersuites
specified in RFC 4279.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-otto-emu-eap-tls-psk-00.txt

To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
   "get draft-otto-emu-eap-tls-psk-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
   [EMAIL PROTECTED]
In the body type:
   "FILE /internet-drafts/draft-otto-emu-eap-tls-psk-00.txt".

NOTE:   The mail server at ietf.org can return the document in
   MIME-encoded form by using the "mpack" utility.  To use this
   feature, insert the command "ENCODING mime" before the "FILE"
   command.  To decode the response(s), you will need "munpack" or
   a MIME-compliant mail reader.  Different MIME-compliant mail
readers
   exhibit different behavior, especially when dealing with
   "multipart" MIME messages (i.e. documents which have been split
   up into multiple messages), so check your local documentation on
   how to manipulate these messages.

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Tentative EMU meeting slot

[Joseph Salowey \(jsalowey\)]

A tentative IETF 66 meeting schedule is available at:

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=
66

Note that this agenda is still subject to change. EMU is scheduled for:


WEDNESDAY, July 12, 2006
0800-1700 IETF Registration - Foyer 500D
0800-0900 Continental Breakfast - Foyer 500D
0900-1130 Morning Session I
Room 513B   APP calsify Calendaring and Scheduling Standards
Simplification WG
Room 518AB  INT autoconfAd-Hoc Network Autoconfiguration
WG
Room 519B   IRTFMobOpts IP Mobility Optimizations Research Group
Room 515OPS v6ops   IPv6 Operations WG
Room 513C-F RAI mmusic  Multiparty Multimedia Session Control WG
Room 520DEF RTG mplsMultiprotocol Label Switching WG
Room 519A   SEC emu EAP Method Update WG
Room 520ABC TSV nsisNext Steps in Signaling WG





___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Enhanced EAP-TLS

[Joseph Salowey \(jsalowey\)]

Exchanging data within the TLS tunnel is one way to achieve channel
bindings.  I could see advantages to having a single method for legacy
password database support and enhanced TLS.  At least it seems the core
specification could be the same.  

I'm not quite sure how to handle EAP negotiation with multiple
credentials supported by the same method.  For example, I don't see a
problem with backwards compatibility in adding additional ciphersuite
support to RFC2617bis to PSK and other credentials; I believe that most
TLS implementations handle ciphersuite negotiation correctly.  There may
a potential problem because if ciphersuite negotiation fails the only
way within EAP to try a new EAP method is to restart the entire
conversation in the lower layer.  This may be less than ideal, but I'm
not sure it is too much of a problem in reality. 


Joe


> -Original Message-
> From: Hao Zhou (hzhou) 
> Sent: Monday, June 12, 2006 11:49 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Enhanced EAP-TLS
> 
> What about exchanges of arbitrary data in the protected 
> tunnel (may include channel binding), optional server side 
> authentication with inner method support for weak password. 
> Would it make sense to create a single TLS based tunneling 
> method instead of two separate ones, one for enhanced TLS, 
> and another one for tunneling method support for weak password?
> 
> > -Original Message-
> > From: Joseph Salowey (jsalowey)
> > Sent: Thursday, June 08, 2006 4:01 PM
> > To: emu@ietf.org
> > Subject: [Emu] Enhanced EAP-TLS
> > 
> > One of our charter items is to develop an enhanced EAP-TLS that can 
> > support features that are not possible to support in a 
> manner that is 
> > backward compatible with RFC2716.
> > 
> > Some of the potential features on the list include:
> > 
> > 1. Additional cipher suites (PSK, Kerberos, ECC) 2. TLS 
> extensions 3. 
> > Channel Bindings 4. Identity protection
> > 
> > Are there additional features that should be supported by 
> an enhanced 
> > TLS?
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Draft Agenda for EMU working Group

[Joseph Salowey \(jsalowey\)]

Below is a draft agenda for the EMU working group meeting.  Let me know
if you have specific items for the agenda. 

Thanks,

Joe

EMU WG - WEDNESDAY, July 12, 2006 - 0900-1130 
--

Blue sheets - Agenda Bashing (5 min)

PSK

GPSK Presentation (15 min) - Hannes/Charles
GPSK Discussion (30 min) 
PSK Working Group Item (10 min)

EAP-TLS 

RFC2716bis update - (15 min) - Bernard
EAP-TLS enhancements discussion (40 min) - TBD

Password based mechanism
-
Requirements -  15 min - TBD

Misc
-
Implementation issues - 10 min - Dave Mitton

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] FW: [TLS] Fwd: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Yngve N. Pettersen [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 21, 2006 5:01 PM
> To: Transport Layer Security working group
> Subject: [TLS] Fwd: I-D 
> ACTION:draft-pettersen-tls-interop-experience-00.txt 
> 
> 
> 
> --- Forwarded message ---
> From: [EMAIL PROTECTED]
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt
> Date: Wed, 21 Jun 2006 12:50:01 -0700
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
>   Title   : Clientside interoperability experiences for
>the SSL and TLS protocols
>   Author(s)   : Y. Pettersen
>   Filename: draft-pettersen-tls-interop-experience-00.txt
>   Pages   : 27
>   Date: 2006-6-21
>   
> This document presents a number of problems encountered when
> implementing TLS 1.0, TLS 1.0 and TLS Extensions for clients, and
> their consequences.  The problems include servers that refuse to
> connect with clients supporting newer versions of the protocol, or
> does not handle such negotiation properly.  Other problems
> encountered are incorrect use of values in the protocol messages.
> 
> The consequences of these problems range from delayed 
> introduction of
> new protocol versions and features, to fallback 
> mechanisms that may
> disable protocol security features, to implementations that cannot
> interoperate with some other implementations.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pettersen-tls-intero
p-experience-00.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [EMAIL PROTECTED] with the word 
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
>   "get draft-pettersen-tls-interop-experience-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>   [EMAIL PROTECTED]
> In the body type:
>   "FILE 
> /internet-drafts/draft-pettersen-tls-interop-experience-00.txt".
>   
> NOTE: The mail server at ietf.org can return the document in
>   MIME-encoded form by using the "mpack" utility.  To use this
>   feature, insert the command "ENCODING mime" before the "FILE"
>   command.  To decode the response(s), you will need "munpack" or
>   a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
>   exhibit different behavior, especially when dealing with
>   "multipart" MIME messages (i.e. documents which have been split
>   up into multiple messages), so check your local documentation on
>   how to manipulate these messages.
>   
>   
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
> 
> 
> --
> Sincerely,
> Yngve N. Pettersen
> 
> 
> Senior Developer Email: [EMAIL PROTECTED]
> Opera Software ASA   http://www.opera.com/
> Phone:  +47 24 16 42 60  Fax:+47 24 16 40 01
> 
> 


attachment185.tmp
Description: attachment185.tmp


attachment186.tmp
Description: attachment186.tmp
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review

[Joseph Salowey \(jsalowey\)]

Hi Bernard,

Thanks for the update, comments inline below: 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, June 24, 2006 6:51 PM
> To: emu@ietf.org
> Subject: [Emu] Partial Proposed Resolution to RFC 2716bis Review
> 
> Find enclosed below some review questions from Joe Salowey.  
> I still am researching the answers to questions 1A and 1B, so 
> I have not included a proposal for these yet.
> 
> --
> 
> C. This document should probably reference RFC 3280.
> 
> [BA] DONE.
> 
> D. I think the last paragraph might not be quite correct:
> 
> "... Please note that in the case where the EAP 
> authentication is remoted that
>the EAP server will not reside on the same machine as the
>authenticator, and therefore the name in the EAP server's 
> certificate
>cannot be expected to match that of the intended 
> destination. In this
>case, a more appropriate test might be whether the EAP server's
>certificate is signed by a CA controlling the intended destination
>and whether the EAP server exists within a target sub-domain."
> 
> I'm not quite sure what the is meant by "target sub-domain."  
> In any case it is important that the peer be able to 
> authorize the server as an EAP-Server that can authorize the 
> authenticator the peer is connecting to. This is more than 
> being issued by an organizational CA since that particular CA 
> may issue certificates for many purposes. There either needs 
> to be something in the certificate or the peer must have 
> configuration to be able to perform the authorization.
> 
> [BA] How about this?
> 
> "  The peer MUST verify the validity of the EAP server 
> certificate, and
>SHOULD also examine the EAP server name presented in the 
> certificate,
>in order to determine whether the EAP server can be trusted.  For
>example, just because a server certificate can chain to a trust
>anchor does not necessarily imply that it is valid for 
> connection to
>a particular network.  As a result, the peer may also want to test
>whether the EAP server certificate is signed by a CA 
> controlling the
>destination network and whether the Server-Id matches the format
>expected for that network.  For example, an EAP peer connecting to
>the "EXAMPLE" SSID may wish to check whether the Server-Id matches
>the regular expression "*.example.com", in addition to checking
>wehther the server certificate chains to the example.com CA."
> 

[Joe] I think this is a step in the right direction. I'm not sure that
Server-ID is the only thing you may check for a particular deployment.  

> 2. Section 2.5 Key Hierarchy
> 
> A.  Why is the EMSK broken into two halves?  It should not be 
> as this implies a particular usage for the EMSK.  It should 
> just be one 64 byte value.
> 
> [BA] Right.  I've removed the mateiral on the "halves" of the EMSK.
> 
[Joe] OK

> B. Does this section tie the implementation of the PRF to 
> 2246?  What if TLS 1.2 supports a different PRF?
> 
> [BA] I've removed the RFC 2246 reference here and also 
> replaced other 2246 references with RFC 4346 since that 
> obsoletes 2246.
> 
[Joe] OK I think this is good.  How does 1.1 and 1.2 impact backwards
compatibility?

> C. This section shows the TLS key hierarchy, shouldn't it 
> show the EAP-TLS key hierarchy?
> 
> [BA]  How about this?
> 
> "   In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
>secret via a one-way function.  This ensures that the TLS master
>secret cannot be derived from the MSK, EMSK or IV unless 
> the one-way
>function (TLS PRF) is broken.  Since the MSK and EMSK are derived
>from the TLS master secret, if the TLS master secret is compromised
>then the MSK and EMSK are also compromised.
> 
>The MSK is divided into two halves, corresponding to the "Peer to
>Authenticator Encryption Key" (Enc- RECV-Key, 32 octets) and
>"Authenticator to Peer Encryption Key" (Enc- SEND-Key, 32 octets).
> 
>The IV is a 64 octet quantity that is a known value; 
> octets 0-31 are
>known as the "Peer to Authenticator IV" or RECV-IV, and 
> Octets 32-63
>are known as the "Authenticator to Peer IV", or SEND-IV.
> 
>EAP-TLS derives exported keying material and parameters as follows:
> 
>MSK(0,63)   = TLS-PRF-64(TMS, "client EAP encryption",
> client.random || server.random)
>EMSK(0,63)  = second 64 octets of:
>  TLS-PRF-128(TMS, "client EAP encryption",
> client.random || server.random)
>IV(0,63)= TLS-PRF-64("", "client EAP encryption",
> client.random || server.random)
> 
> 
>MSK(0,31)   = Peer to Authenticator Encryption Key (Enc-RECV-Key)
>  (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
>  PMK in [IEEE-802.1

RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, June 24, 2006 7:25 PM
> To: emu@ietf.org
> Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review
> 
> >I will add some text on this vulnerablity, which is enabled because 
> >some TLS-based methods share the same key-derivation formula.
> 
> How about this?
> 
> "4.6.  Packet Modification Attacks
> 
>The integrity protection of EAP-TLS packets does not extend to the
>EAP header fields (Code, Identifier, Length) or the Type or Flags
>fields.  As a result, these fields may be modified by attacker.
> 
>In most cases modification of the Code or Identifier 
> fields will only
>result in a denial of service attack.  However, it may be possible
>for an attacker to add additional data to an EAP-TLS 
> packet so as to
>cause it to be longer than implied by the Length field.  An
>implementation that does not check for this could be 
> vulnerable to a
>buffer overrun.
> 
>It is also possible for an attacker to modify the Type or Flags
>fields.  By modifying the Type field, an attacker could cause one
>TLS-based EAP method to be negotiated instead of another.  For
>example, the EAP-TLS Type field (13) could be changed to indicate
>another TLS-based EAP method.  Unless the alternative TLS-based EAP
>method utilizes a different key derivation formula, it is possible
>that an EAP method conversation altered by a 
> man-in-the-middle could
>run all the way to completion without detection.  
> Unless the
>ciphersuite selection policies are identical for all TLS-based EAP
>methods utilizing the same key derivation formula, it may 
> be possible
>for an attacker to mount a successful downgrade attack, causing the
>peer to utilize an inferior ciphersuite or TLS-based EAP method."
>

[Joe] OK, I'm not sure we need to include text about the key derivation.
If it is the key derivation that is the only difference then change will
only be caught after the completion of the method if the keys are used.

 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review

[Joseph Salowey \(jsalowey\)]

> I'll add a section on this in the next rev.
> 
> > >TLS_RSA_WITH_3DES_EDE_CBC_SHA.
> > >
> >[Joe] RFC4346 allows you define an application profile so we 
> wouldn't 
> >necessarily have to make this ciphersuite mandatory.
> 
> Just found some interoperability issues with this 
> ciphersuite,  so making it mandatory could be problematic :(
> 
> Maybe we should stick with RC4 as mandatory, and add AES as a 
> SHOULD?  RC4 definitely interoperates.
> 
[Joe] I would be tempted to specify it the other way.  I think we want
to encourage AES implementation, RC4 I'm not so sure... 

> >[Joe] what do you mean support and be able to negotiate?  
> Why not just 
> >support?
> 
> Support should be sufficient.  In some situations, not every 
> supported ciphersuite will be negotiable (e.g. in FIPS mode, 
> RC4 ciphersuites will not be negotiable).
> 
[Joe] Right.  I think we want it to be implemented, but it is up to the
deployment requirements as to what is actually gets negotiated. 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Presentations for EMU

[Joseph Salowey \(jsalowey\)]

The EMU agenda is available here:

http://www3.ietf.org/proceedings/06jul/agenda/emu.txt

Presenters please send me your presentations sometime today so I can
upload them.  

Thank you,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] IETF-66 EMU working group summary

[Joseph Salowey \(jsalowey\)]

The EMU working group meet at 9AM on Wednesday

The first topic of discussion was presented by Hannes Tschofenig on the
draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK
EAP Method.  There was consensus in the room to take this on as a
working group item to meet the PSK charter item with a modification to
the defined cipersuites (switch AES-CCM for AES-EAX).  The action is to
solicit comments on if this should be accepted as a working group item
on the EMU list. 

Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document.  The
presentation discussed some open issues of the draft.  Interoperability
problems with the TLS 3DES ciphersuites were discussed. It was noted
that some variants of EAP methods based on TLS method used the same
label strings in deriving the MSK from the TLS master secret. This is
thought to lead to some potential problems so it might be advisable to
use different label strings for this in the future.  Lastly, identity
privacy using TLS was discussed.  The draft needs to be updated and
listed as a working group draft on the charter page.

Next we had some presentations on EAP-TLS related methods.  Hannes
Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically
for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy
scheme for TLS.  The general feeling was this would be better evaluated
by the TLS group. Hao Zhou presented on some possible enhancements for
EAP-TLS.  More discussion on enhanced EAP-TLS is needed on the list. 

Dave Mitton presented on issues implementing new EAP methods.  One
problem was that some access points don't pass some EAP types they don't
know about.  The action is to assist the WIFI alliance develop tests for
this.   

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Draft minutes for EMU meeting - IETF 66

[Joseph Salowey \(jsalowey\)]

Here are the draft minutes for the EMU session,  let me know if you have
any corrections:

Minutes for EAP Method Update (EMU) at IETF 66
-
Date: 7/12/2006
Time: 9 - 11:30 AM
Place: Montreal, QC 
Note takers: Nancy Cam-Winget, Madjid Nakhjiri


Summary
-
The first topic of discussion was presented by Hannes Tschofenig on the
draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK
EAP Method.  There was consensus in the room to take this on as a
working group item to meet the PSK charter item with a modification to
the defined cipersuites (switch AES-CCM for AES-EAX).  The action is to
solicit comments on if this should be accepted as a working group item
on the EMU list. 

Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document.  The
presentation discussed some open issues of the draft.  Interoperability
problems with the TLS 3DES ciphersuites were discussed. It was noted
that some variants of EAP methods based on TLS method used the same
label strings in deriving the MSK from the TLS master secret. This is
thought to lead to some potential problems so it might be advisable to
use different label strings for this in the future.  Lastly, identity
privacy using TLS was discussed.  The draft needs to be updated and
listed as a working group draft on the charter page.

Next we had some presentations on EAP-TLS related methods.  Hannes
Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically
for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy
scheme for TLS.  The general feeling was this would be better evaluated
by the TLS group. Hao Zhou presented on some possible enhancements for
EAP-TLS.  More discussion on enhanced EAP-TLS is needed on the list. 

Dave Mitton presented on issues implementing new EAP methods.  One
problem was that some access points don't pass some EAP types they don't
know about.  The action is to assist the WIFI alliance develop tests for
this.   


Detailed Minutes
---


1. Generalized Pre-Shared Key Method (GPSK) - Hannes Tschofenig

Hannes Presented Slides

Discussion

- Key confirmation

Russ Housley:  wants to make sure that last message has confirmation on
last message that both parties have derived the same key

Hannes: Message 4 is optional and the encrypted part is also optional

Uri Blumenthal: questions need for explicit confirmation since Message 2
and Message 3 provides the information

Bernard Aboba: may be confused, in 2nd message should know what the enc
and MAC keys are used. The SEC_SK message is authenticated using a new
key?

Hannes: Confusion was around notation, the MAC's in the messages are
using the SK which is derived from the nonces and the PSK.

- identity protection

Bernard: asks on how identity protection may be achieved? 

Hannes: Out of scope one approach may be to use only the key identifier

Joe Salowey: temporary ID may be used, encrypted payload can deliver it.

- ciphersuites

Russ: asked why not choosing NIST approved modes? Consider changing it
to AES-CCM.

David McGrew: recommended use AES-CCM

Sam Hartman: questions why have a NULL?
Uri:  mentioned simplicity thus a reduction, mode was chosen to ensure
AES was used and most efficient thus why EAX was chosen.
Pasi Eronen: why can it not be replaced with CBC, other people gave
other options
Joe: mentions crypto selection should not be contentious

+ Needs discussion on the list and with the ADs. 

- key hierarchy

Hannes: Jouni has already made first cut an implementation of this
method. Only took 8 hours.
 
Joe: How many people have read the document?
Hands -- 4 - 5

Joe: Hum for "is this in the right direction?"
for: lots
against: none

Joe: Hum to accept as a working group item
for: lots
against: none

+ take it to the list


2. RFC 2716bis - Bernard Aboba

Bernard presents

- Key derivation

Bernard: Not a good idea to derive keys using the same label, though
this may not be as easy as it seems.

Sam: mentions that TLS community should make it easy to change labels
for key derivation

- Multiple layers of negotiation

Sam: does multiple layers of negotiation with EAP-TLS introduce a
vulnerability?
Bernard: 3748 with respect to protect against downgrade attack, you
could NACK it if it is something you don't want to do.

- Ciphersuite support

Bernard: mandatory to implement ciphersuites: 3DES/HMAC-SHA1 failed
interop tests. Some very popular EAP-TLS implementations with 3DES
failed to even complete. Possibly results from  some changes in openssl.

Russ: how about the old openssl?
Bernard: not tested
Bernard: does anybody has AES implementations we can use and test?

+ question the list about AES support

- Privacy

Bernard: what does it mean to be backward compatibility especially with
respect to privacy? Bernard's interpretation is that client requiring
privacy must fail with server w/no privacy but must conn

[Emu] GPSK as a working group item

[Joseph Salowey \(jsalowey\)]

At IETF 66 EMU working group meeting there was consensus to take on
draft-clancy-emu-eap-shared-secret-01.txt as a working group item.   

Are there any objections to taking this on as a working group item?

Thanks,

Joe 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] GPSK as a working group item

[Joseph Salowey \(jsalowey\)]

Since we haven't had any objections it seems there is consensus to take
this on as a working group item.  

Cheers,

Joe 

> -Original Message-
> From: Joseph Salowey (jsalowey) 
> Sent: Thursday, July 20, 2006 11:38 AM
> To: emu@ietf.org
> Subject: [Emu] GPSK as a working group item
> 
> At IETF 66 EMU working group meeting there was consensus to take on
> draft-clancy-emu-eap-shared-secret-01.txt as a working group item.   
> 
> Are there any objections to taking this on as a working group item?
> 
> Thanks,
> 
> Joe 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Duplicate integrity protection on Protected Payload datain GPSK

[Joseph Salowey \(jsalowey\)]

AES-CBC seems like a good choice.   

Joe 

> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, July 16, 2006 5:52 PM
> To: Lakshminath Dondeti
> Cc: emu@ietf.org
> Subject: Re: [Emu] Duplicate integrity protection on 
> Protected Payload datain GPSK
> 
>  > My reading of the GPSK draft is that the Protected Payload 
> data will  > be integrity protected using the MAC from the 
> combined mode and there  > is the integrity checksum over the 
> entire GPSK-Message.  I think we  > should avoid the multiple MACs.
> 
> ...
> 
>  > I am curious about others' opinions on EAX vs. CCM.
> 
> We could replace AES-EAX with AES-CBC.  Would address both 
> your concerns?
> 
> --
> t. charles clancy, ph.d.  |  [EMAIL PROTECTED]  |  www.cs.umd.edu/~clancy
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] new authenticated encryption draft and a proposed use inEMU GPSK

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David A. McGrew
> Sent: Friday, August 18, 2006 11:48 AM
> To: [EMAIL PROTECTED]; Hannes Tschofenig; Charles Clancy
> Subject: [Emudt] new authenticated encryption draft and a 
> proposed use inEMU GPSK
> 
> Hi Hannes, Charles, and others,
> 
> I've recently submitted an ID that defines a set of 
> application- independent authenticated encryption algorithms, 
> and I'd like to propose that it be used in 
> draft-clancy-emu-eap-shared-secret-01 and/ or in other work 
> in this area.  It is online at http:// 
> www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html, 
> and the "Introduction" section explains its benefits.  It is 
> a very natural fit to the EMU work.
> 
> Here is how to use this new spec for the EMU shared secret method.   
> Below I've adapted the EAP-GPSK protocol notation from 
> Section 3 of draft-clancy-emu-eap-shared-secret, and defined 
> how the fields of the messages relate to the inputs and 
> outputs of an authenticated encryption algorithm (defined at 
> http://www.mindspring.com/~dmcgrew/
> draft-mcgrew-auth-enc-00.html#anchor3):
> 
> Authenticated encryption inputs:
>  K = secret key
>AAD = additional authenticated (but not encrypted) data
>  P = plaintext
> 
> Authenticated encryption outputs:
>  C = ciphertext
> IV = initialization vector
>  T = authentication tag
> 
> GPSK using the authenticated encryption interface:
> 
> GPSK-1 := ID_Server, RAND_Server, CSuite_List
> 
> GPSK-2 := ID_Client, ID_Server, RAND_Client, RAND_Server,
>   CSuite_List, CSuite_Sel [, Ciphertext1, ... ],  ICV1
> 
>  AAD := HDR2, ID_Client, ID_Server, RAND_Client, 
> RAND_Server, CSuite_List, CSuite_Sel
>P := PD_Payload_1
> Ciphertext1 := IV || C
> ICV1 := T
> 
> GPSK-3 := RAND_Client, RAND_Server, CSuite_Sel [, Ciphertext2 ],
> ICV2
> 
>  AAD := HDR3, RAND_Client, RAND_Server, CSuite_Sel
>P := PD_Payload_2
> Ciphertext2 := IV || C
> ICV2 := T
> 
> GPSK-4 := [ Ciphertext_3, ] ICV
> 
>  AAD := HDR4
>P := PD_Payload_3
> Ciphertext3 := IV || C
> ICV3 := T
> 
> 
> To leverage the authenticated encryption spec, large parts of 
> Sections 5 and 6 in the GPSK draft would be replaced by 
> references to the former document.  This would have the 
> effect of replacing the  
> currently defined ciphersuites with slightly different ones.   
> However, there are problems with the current definitions, so 
> changes are needed in this area anyway.  (Ciphersuite #1 is 
> defined to use
> AES-EAX-128 for encryption and AES-CMAC-128 for integrity, and  
> includes a key derivation function to derive keys for each mode.   
> This is a serious misuse of EAX, or a faulty explanation of 
> the intended use of EAX, because that mode of operation can provide
> *both* encryption and integrity, without the need for 
> AES-CMAC or a key derivation function.) If no confidentiality 
> is needed, this is indicated by providing a zero-length 
> plaintext to the authenticated encryption algorithm, so there 
> is no need for a separate authentication-only ciphersuite.
> 
> The authenticated encryption draft uses AES CCM instead of AES EAX,  
> because CCM is widely supported and is approved for use in 
> FIPS-140.   
> Of course, the really important thing about the authenticated 
> encryption draft is the interface that it defines, and if 
> there is a need for a different authenticated encryption 
> algorithm, it would be easy to add.  FWIW I do think that the 
> AE algorithms that are currently defined meet the EMU requirements.
> 
> Comments welcome.  I'll be traveling over the next week, so 
> my response time might lag a bit.
> 
> Best regards,
> 
> David
> ___
> Emu mailing list
> [EMAIL PROTECTED]
> https://www.machshav.com/mailman/listinfo.cgi/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

Is the proposal to make 3DES mandatory and AES optional? 
It seems that we should be moving toward AES.  Since this is a new
method it may be better to make AES mandatory and 3DES optional.

> -Original Message-
> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 22, 2006 2:20 AM
> To: M. Vanderveen
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> Hi
> 
> let us for a moment assume that RFC 4307 makes some 
> reasonable algorithm choices (we are talking about IKEv2 
> here). If we take the text and apply it to EAP-GPSK then we 
> would produce something like:
> 
> Conservative Choice:
> ---
> 
> (Integrity)
>AUTH_HMAC_SHA1_962[RFC2404]MUST
> 
> (Encryption)
>ENCR_3DES3 [RFC2451]   MUST-
> 
> (Key Derivation)
>PRF_HMAC_SHA1   2  [RFC2104]MUST
> 
> (Note that there is no MUST for encryption algorithms specified in RFC
> 4307.)
> 
> 
> Choice for the Future:
> ---
> 
> (Encryption)
>   ENCR_AES_CBC 12[AES-CBC]   SHOULD+
> 
> (Integrity)
>   AUTH_AES_XCBC_96 5 [AES-MAC]   SHOULD+
> 
> (Key Derivation)
>PRF_AES128_CBC  4  [AESPRF] SHOULD+
> 
> Does this sound like a terrible bad idea?
> 
> Ciao
> Hannes
> 
> M. Vanderveen schrieb:
> > Both are pretty popular. Why not list them both? As for 
> which one to be 
> > mandatory to implement, someone should to a search through 
> other systems 
> > (e.g. IEEE, IPSec) and see which one is most popular.
> > 
> > */Hannes Tschofenig <[EMAIL PROTECTED]>/* wrote:
> > 
> > Hi all,
> > 
> > the current version of the document
> > 
> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt
> > still supports AES-EAX:
> > 
> > 
> +---++-+---++
> > | CSuite/ | KS | Encryption | Integrity | Key Derivation |
> > | Specifier | | | | Function |
> > 
> +---++-+---++
> > | 0x01 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 |
> > 
> +---++-+---++
> > 
> > At the IETF#66 EMU meeting AES CCM was suggested.
> > 
> > Later, it got the impression that AES-CBC was more 
> appreciated. Should
> > we update the draft with AES-CBC?
> > 
> > Ciao
> > Hannes
> > 
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> > 
> > 
> --
> --
> > Do you Yahoo!?
> > Get on board. You're invited 
> > 
>  ahoo.com/handraisers> 
> > to try the new Yahoo! Mail Beta.
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

We want to define GPSK as a framework that can accommodate new
algorithms when they are available.  I believe that Lakshminath is
looking to allow optimizations within this framework in the case where a
combined mode cipher is used.  At this point I'm not sure how much
complexity this would add to the specification.  If it can be done
simply then it might be worthwhile pursuing,  perhaps David McGrew's
AEAD specification would help here.

 

> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 22, 2006 4:05 AM
> To: Lakshminath Dondeti
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> Interesting idea, but what does it gain you?  Why not just 
> use an AES-CBC and CMAC ciphersuite?
> 
> --
> t. charles clancy, ph.d.  |  [EMAIL PROTECTED]  |  www.cs.umd.edu/~clancy
> 
> Lakshminath Dondeti wrote:
> > I guess we agree to disagree.  The addition integrity checksum is 
> > spurious in my view and I believe we can define things so that 
> > combined modes can be employed without encrypting anything, so I am 
> > somewhat confused here.  What's your opinion on the latter 
> part of my email?
> > 
> > thanks,
> > Lakshminath
> > 
> > At 05:12 PM 8/22/2006, Hannes Tschofenig wrote:
> >> Hi Lakshminath,
> >>
> >> Lakshminath  Dondeti schrieb:
> >>> At the expense of generating some confusion, here is my 
> take on this:
> >>> The objection is to having to carry multiple integrity 
> checksums in 
> >>> GPSK, if we used the combined mode *and* an integrity algorithm.
> >>
> >> I don't agree with you. There is no reason to optimize a 
> few bits in 
> >> a pre-shared secret method.
> >> Note that we are not talking about a protocol for data transfer.
> >> We wanted the flexibility to use different cipher suites. 
> We do not 
> >> only want to use cipher suites that provide authenticated 
> encryption 
> >> (since we almost have nothing to encrypt; currently 1 bit 
> and almost 
> >> no EAP method provides this functionality).
> >>
> >> Ciao
> >> Hannes
> >>
> >>> I think CCM is fine for instance, the only catch is that 
> we need to 
> >>> make sure and define AAD for CCM carefully to include appropriate 
> >>> data into the integrity checksum calculation.  So, once we define 
> >>> CCM as the mode, we shouldn't need AES-CMAC-128 if 
> encryption is being used.
> >>> I would suggest using CCM and specifying the use of it 
> fully so it 
> >>> can be used without misunderstandings.  If you want me to 
> put some 
> >>> time into writing that up, let me know.
> >>> cheers,
> >>> Lakshminath
> >>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote:
>  Hi all,
> 
>  the current version of the document 
>  
> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.
>  txt
>  still supports AES-EAX:
> 
> 
>  
> +---++-+---++
> | CSuite/   | KS | Encryption  | Integrity | Key 
>  Derivation |
> | Specifier || |   | 
>  Function   |
> 
>  
> +---++-+---++
> | 0x01  | 16 | AES-EAX-128 | AES-CMAC-128  | 
>  GKDF-128   |
> 
>  
> +---++-+---++
> 
>  At the IETF#66 EMU meeting AES CCM was suggested.
> 
>  Later, it got the impression that AES-CBC was more appreciated. 
>  Should we update the draft with AES-CBC?
> 
>  Ciao
>  Hannes
> 
> 
>  ___
>  Emu mailing list
>  Emu@ietf.org
>  https://www1.ietf.org/mailman/listinfo/emu
> > 
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 28, 2006 11:37 AM
> To: Joseph Salowey (jsalowey)
> Cc: Charles Clancy; Lakshminath Dondeti; emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> Hi Joe,
> 
> I don't think that we on-the-fly want to use new algorithms 
> as they come available. 

[Joe] Not sure what you mean by on the fly, but I think it would be bad
to have to rewrite large portions of EAP-GPSK to make use of a new
algorithm. 

Based on Bernhard's experience with 
> EAP-TLS I got the impression that most EAP implementers and 
> users are not really excited about updating their 
> implementation whenever a new algorithm becomes available.
> 

[Joe] However, new algorithms are implemented and requirements for
algorithm agility exist.  

> Furthermore, if new algorithms become available we need to 
> specify a ciphersuite that makes sense for the given environment.
> 
> The most difficult part with protocol design is to sometimes 
> say NO when features and optimizations are proposed.
> 

[Joe] True, but an analysis of the cost and benefits should be done. It
is also not good to end up with a protocol that is obsolete when a new
algorithm is required. 


> Ciao
> Hannes
> 
> 
> Joseph Salowey (jsalowey) schrieb:
> > We want to define GPSK as a framework that can accommodate new 
> > algorithms when they are available.  I believe that Lakshminath is 
> > looking to allow optimizations within this framework in the 
> case where 
> > a combined mode cipher is used.  At this point I'm not sure 
> how much 
> > complexity this would add to the specification.  If it can be done 
> > simply then it might be worthwhile pursuing,  perhaps David 
> McGrew's 
> > AEAD specification would help here.
> > 
> >  
> > 
> >> -Original Message-
> >> From: Charles Clancy [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, August 22, 2006 4:05 AM
> >> To: Lakshminath Dondeti
> >> Cc: emu@ietf.org
> >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> >>
> >> Interesting idea, but what does it gain you?  Why not just use an 
> >> AES-CBC and CMAC ciphersuite?
> >>
> >> --
> >> t. charles clancy, ph.d.  |  [EMAIL PROTECTED]  |  www.cs.umd.edu/~clancy
> >>
> >> Lakshminath Dondeti wrote:
> >>> I guess we agree to disagree.  The addition integrity checksum is 
> >>> spurious in my view and I believe we can define things so that 
> >>> combined modes can be employed without encrypting 
> anything, so I am 
> >>> somewhat confused here.  What's your opinion on the latter
> >> part of my email?
> >>> thanks,
> >>> Lakshminath
> >>>
> >>> At 05:12 PM 8/22/2006, Hannes Tschofenig wrote:
> >>>> Hi Lakshminath,
> >>>>
> >>>> Lakshminath  Dondeti schrieb:
> >>>>> At the expense of generating some confusion, here is my
> >> take on this:
> >>>>> The objection is to having to carry multiple integrity
> >> checksums in
> >>>>> GPSK, if we used the combined mode *and* an integrity algorithm.
> >>>> I don't agree with you. There is no reason to optimize a
> >> few bits in
> >>>> a pre-shared secret method.
> >>>> Note that we are not talking about a protocol for data transfer.
> >>>> We wanted the flexibility to use different cipher suites. 
> >> We do not
> >>>> only want to use cipher suites that provide authenticated
> >> encryption
> >>>> (since we almost have nothing to encrypt; currently 1 bit
> >> and almost
> >>>> no EAP method provides this functionality).
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>>> I think CCM is fine for instance, the only catch is that
> >> we need to
> >>>>> make sure and define AAD for CCM carefully to include 
> appropriate 
> >>>>> data into the integrity checksum calculation.  So, once 
> we define 
> >>>>> CCM as the mode, we shouldn't need AES-CMAC-128 if
> >> encryption is being used.
> >>>>> I would suggest using CCM and specifying the use of it
> >> fully so it
> >>>>> can be used without misunderstandings.  If you want me to
> >> put some
> >>>>> time into writing that up, let me know.
> >>>>> cheer

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

IKEv2 has been designed for a different environment which already had
3DES deployed,  I'm not sure that this is the case with EAP-GPSK. 

> -Original Message-
> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 28, 2006 11:32 AM
> To: Joseph Salowey (jsalowey)
> Cc: M. Vanderveen; emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> Hi Joe,
> 
> we might want to ask ourself why IKEv2 guys have chosen the 
> indicated list of algorithms and why we decide to use different onces.
> 
> If we think that their list represents a problem we might 
> want to convince them to submit an updated version of RFC 4307.
> 
> Ciao
> Hannes
> 
> Joseph Salowey (jsalowey) schrieb:
> > Is the proposal to make 3DES mandatory and AES optional? 
> > It seems that we should be moving toward AES.  Since this is a new
> > method it may be better to make AES mandatory and 3DES optional.
> > 
> >> -Original Message-
> >> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, August 22, 2006 2:20 AM
> >> To: M. Vanderveen
> >> Cc: emu@ietf.org
> >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> >>
> >> Hi
> >>
> >> let us for a moment assume that RFC 4307 makes some reasonable 
> >> algorithm choices (we are talking about IKEv2 here). If we 
> take the 
> >> text and apply it to EAP-GPSK then we would produce something like:
> >>
> >> Conservative Choice:
> >> ---
> >>
> >> (Integrity)
> >>AUTH_HMAC_SHA1_962[RFC2404] 
>MUST
> >>
> >> (Encryption)
> >>ENCR_3DES3 [RFC2451]   MUST-
> >>
> >> (Key Derivation)
> >>PRF_HMAC_SHA1   2  [RFC2104]MUST
> >>
> >> (Note that there is no MUST for encryption algorithms specified in 
> >> RFC
> >> 4307.)
> >>
> >>
> >> Choice for the Future:
> >> ---
> >>
> >> (Encryption)
> >>   ENCR_AES_CBC 12[AES-CBC]   SHOULD+
> >>
> >> (Integrity)
> >>   AUTH_AES_XCBC_96 5 [AES-MAC]   SHOULD+
> >>
> >> (Key Derivation)
> >>PRF_AES128_CBC  4  [AESPRF] SHOULD+
> >>
> >> Does this sound like a terrible bad idea?
> >>
> >> Ciao
> >> Hannes
> >>
> >> M. Vanderveen schrieb:
> >>> Both are pretty popular. Why not list them both? As for
> >> which one to be
> >>> mandatory to implement, someone should to a search through
> >> other systems
> >>> (e.g. IEEE, IPSec) and see which one is most popular.
> >>>
> >>> */Hannes Tschofenig <[EMAIL PROTECTED]>/* wrote:
> >>>
> >>> Hi all,
> >>>
> >>> the current version of the document
> >>> 
> >> 
> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.tx
> >> t
> >>> still supports AES-EAX:
> >>>
> >>> 
> >> 
> +---++-+---++
> >>> | CSuite/ | KS | Encryption | Integrity | Key Derivation |
> >>> | Specifier | | | | Function |
> >>> 
> >> 
> +---++-+---++
> >>> | 0x01 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 |
> >>> 
> >> 
> +---++-+---++
> >>> At the IETF#66 EMU meeting AES CCM was suggested.
> >>>
> >>> Later, it got the impression that AES-CBC was more
> >> appreciated. Should
> >>> we update the draft with AES-CBC?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>
> >>> ___
> >>> Emu mailing list
> >>> Emu@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/emu
> >>>
> >>>
> >>>
> >> --
> >> --
> >>> Do you Yahoo!?
> >>> Get on board. You're invited
> >>>
> >> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.y
> >> ahoo.com/handraisers>
> >>> to try the new Yahoo! Mail Beta.
> >>
> >> ___
> >> Emu mailing list
> >> Emu@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/emu
> >>
> > 
> > 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

Hi Lakshminath,

I have not seen a lot of support for use of CCM/EAX with or without the
optimization of eliminating additional MAC algorithm on the list.  I
think it would be useful to understand what the impact is on the current
specification to support ciphers that provide both integrity protection
and encryption without requiring additional MAC algorithms.  Would the
current spec need to be modified to support this?  If so, what
modifications are needed?

Thanks,
Joe

> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, August 20, 2006 12:23 AM
> To: Hannes Tschofenig; emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> At the expense of generating some confusion, here is my take on this:
> 
> The objection is to having to carry multiple integrity 
> checksums in GPSK, if we used the combined mode *and* an 
> integrity algorithm.
> 
> I think CCM is fine for instance, the only catch is that we 
> need to make sure and define AAD for CCM carefully to include 
> appropriate data into the integrity checksum calculation.  
> So, once we define CCM as the mode, we shouldn't need 
> AES-CMAC-128 if encryption is being used.
> 
> I would suggest using CCM and specifying the use of it fully 
> so it can be used without misunderstandings.  If you want me 
> to put some time into writing that up, let me know.
> 
> cheers,
> Lakshminath
> 
> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote:
> >Hi all,
> >
> >the current version of the document
> >http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr
> et-01.txt
> >still supports AES-EAX:
> >
> >
> +---++-+---++
> >| CSuite/   | KS | Encryption  | Integrity | Key 
> Derivation |
> >| Specifier || |   | 
> Function   |
> >
> +---++-+---++
> >| 0x01  | 16 | AES-EAX-128 | AES-CMAC-128  | 
> GKDF-128   |
> >
> > 
> +---++-+---++
> >
> >At the IETF#66 EMU meeting AES CCM was suggested.
> >
> >Later, it got the impression that AES-CBC was more appreciated. 
> >Should we update the draft with AES-CBC?
> >
> >Ciao
> >Hannes
> >
> >
> >___
> >Emu mailing list
> >Emu@ietf.org
> >https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EAP-GPSK: Ciphersuites

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 28, 2006 8:27 PM
> To: emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> Lots of interesting conversation...
> 
> Being ciphersuite-modular doesn't mean we have to give up all 
> control or write a protocol that would work in every possible 
> case.  I don't see any reason to add optimizations to support 
> CCM/EAX-like primitives when there's no reason to use them in 
> the first place.  Both supporting them and using them adds 
> unnecessary complexity.
> 
> IMHO, the ciphersuites should be AES-CBC with a suitable MAC 
> (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to 
> implement because it would most easily achieve FIPS140-2 
> certification.
> 
> Is there general consensus on this part?  There seems to be 
> more contention on which MAC should be used with an AES-based 
> ciphersuite.

[Joe] I personally would prefer to have a mandatory to implement
encrypting ciphersuite.  I'm also flexible when it comes to which AES
MAC is used, either XCBC or OMAC is fine.


> 
> --
> t. charles clancy, ph.d.  <>  [EMAIL PROTECTED]  <>  www.cs.umd.edu/~clancy
> 
> Joseph Salowey (jsalowey) wrote:
> > Hi Lakshminath,
> > 
> > I have not seen a lot of support for use of CCM/EAX with or without 
> > the optimization of eliminating additional MAC algorithm on 
> the list.  
> > I think it would be useful to understand what the impact is on the 
> > current specification to support ciphers that provide both 
> integrity 
> > protection and encryption without requiring additional MAC 
> algorithms.  
> > Would the current spec need to be modified to support this?  If so, 
> > what modifications are needed?
> > 
> > Thanks,
> > Joe
> > 
> > 
> >>-Original Message-
> >>From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> >>Sent: Sunday, August 20, 2006 12:23 AM
> >>To: Hannes Tschofenig; emu@ietf.org
> >>Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> >>
> >>At the expense of generating some confusion, here is my 
> take on this:
> >>
> >>The objection is to having to carry multiple integrity checksums in 
> >>GPSK, if we used the combined mode *and* an integrity algorithm.
> >>
> >>I think CCM is fine for instance, the only catch is that we need to 
> >>make sure and define AAD for CCM carefully to include 
> appropriate data 
> >>into the integrity checksum calculation.
> >>So, once we define CCM as the mode, we shouldn't need
> >>AES-CMAC-128 if encryption is being used.
> >>
> >>I would suggest using CCM and specifying the use of it 
> fully so it can 
> >>be used without misunderstandings.  If you want me to put some time 
> >>into writing that up, let me know.
> >>
> >>cheers,
> >>Lakshminath
> >>
> >>At 10:55 PM 8/20/2006, Hannes Tschofenig wrote:
> >>
> >>>Hi all,
> >>>
> >>>the current version of the document
> >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr
> >>
> >>et-01.txt
> >>
> >>>still supports AES-EAX:
> >>>
> >>>   
> >>
> >>+---++-+---+
> +
> >>
> >>>   | CSuite/   | KS | Encryption  | Integrity | Key 
> >>
> >>Derivation |
> >>
> >>>   | Specifier || |   | 
> >>
> >>Function   |
> >>
> >>>   
> >>
> >>+---++-+---+
> +
> >>
> >>>   | 0x01  | 16 | AES-EAX-128 | AES-CMAC-128  |
> >>
> >>GKDF-128   |
> >>
> >>>   
> >>>
> >>
> >>+---++-+---+
> +
> >>
> >>>At the IETF#66 EMU meeting AES CCM was suggested.
> >>>
> >>>Later, it got the impression that AES-CBC was more appreciated. 
> >>>Should we update the draft with AES-CBC?
> >>>
> >>>Ciao
> >>>Hannes
> >>>
> >>>
> >>>___
> >>>Emu mailing list
> >>>Emu@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/emu
> >>
> >>
> >>___
> >>Emu mailing list
> >>Emu@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/emu
> >>
> > 
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] GPSK issue - KDF Data

[Joseph Salowey \(jsalowey\)]

The current GPSK draft includes the capability for the client and server
to combine data into the KDF.  This is currently incompletely described
in the GPSK draft.  The question has been raised as to whether we need
this functionality.  Unless there is a reason to support this it should
be removed from the specification.  Is there a good reason to keep this?

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] GPSK Issue - Identity in key derivation

[Joseph Salowey \(jsalowey\)]

There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys.  It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities. 

It seems that including the lengths as part of the identity would be
fine.  Any objections?

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] GPSK Open Issues - mandatory ciphersuites

[Joseph Salowey \(jsalowey\)]

Here is my suggestion for resolving the ciphersuite issue:

We need to define a small set (preferably one, maybe two) of mandatory
to implement ciphersuites for GPSK. The mandatory to implement ciphers
should exercise the features of GPSK.  This would suggest that it should
be a block cipher based ciphersuite. It seems a reasonable choice is
AES-CBC with AES-CMAC.  This makes use of a single base algorithm using
relatively simple modes of operation. 

The HMAC-SHA256 ciphersuite should also be described, but is not
mandatory to implement.

Does this seem reasonable? Any objections?

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] GPSK Open Issues - mandatory ciphersuites

[Joseph Salowey \(jsalowey\)]

Hi David,

Do you know if NIST is planning on producing a block cipher based method
for key derivation?  It would be nice to get away with only AES.  One
approach would be to keep the AES-CBC cipher AES only and let
implementations that are concerned about FIPS 140 have the choice of
implementing the SHA-256 cipher. 

Thanks,

Joe

> -Original Message-
> From: David McGrew (mcgrew) 
> Sent: Thursday, October 12, 2006 5:09 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] GPSK Open Issues - mandatory ciphersuites
> 
> Hi Joe,
> 
> a ciphersuite consisting of AES-CBC and AES-CMAC seems 
> reasonable, but we should strive to make sure that the method 
> that derives keys for these algorithms is FIPS-140 approved, 
> so that a module implementing all three methods can be 
> validated.  The KDFs defined in draft-dang-nistkdf-01.txt 
> meet this requirement, but would require that a hash function 
> like SHA-256 be present.  Still, this seems like a decent way 
> to go because at least it keeps SHA-256 out of the data- 
> processing path, and the alternate ciphersuite that you 
> mention has it there.
> 
> David
> 
> On Oct 3, 2006, at 3:04 PM, Joseph Salowey ((jsalowey)) wrote:
> 
> > Here is my suggestion for resolving the ciphersuite issue:
> >
> > We need to define a small set (preferably one, maybe two) 
> of mandatory 
> > to implement ciphersuites for GPSK. The mandatory to 
> implement ciphers 
> > should exercise the features of GPSK.  This would suggest that it 
> > should be a block cipher based ciphersuite. It seems a reasonable 
> > choice is AES-CBC with AES-CMAC.  This makes use of a single base 
> > algorithm using relatively simple modes of operation.
> >
> > The HMAC-SHA256 ciphersuite should also be described, but is not 
> > mandatory to implement.
> >
> > Does this seem reasonable? Any objections?
> >
> > Thanks,
> >
> > Joe
> >
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] EMU meeting Scheduled for IETF 67

[Joseph Salowey \(jsalowey\)]

The following is the scheduled meeting slot for IETF 67

MONDAY, November 6, 2006
1300-1500 Afternoon Session I
SEC   emu   EAP Method Update WG

Let me know if you have any agenda items you would like to cover in this
meeting.  

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

[Joseph Salowey \(jsalowey\)]

Hi Bernard,

Thanks for the update.  I'd like to have some discussion on section 2.4
- Identity verification.  Currently the section states that the peer
identity is obtained from the subjectAltName in the certificate.  Is
this text meant to be normative?  Currently there are implementations
that use elements of the subject distinguished name and do not provide a
subjectAltName. 

Perhaps it would be better to say the subjectAltName is used if it is
present and if it is not then the subject distinguished name is used.
However it seems that RFC3280 might indicate that it would be better to
use subject distinguished name if it is present and subjectAltName if
not. This section should  reference RFC3280.   Also is there any reason
why mapping using a directory service is called out, isn't just mapping
to a Peer-ID or Server-ID sufficient?

It would may also be good to say that an EAP-TLS implementation MAY make
other certificate fields available to the lower layer.

The document should also state in the security considerations section
that the identity in the identity response is not necessarily related to
the identity authenticated in EAP-TLS and should not be relied upon for
any access control or accounting purposes. 


Joe

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 17, 2006 6:57 PM
> To: emu@ietf.org
> Subject: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> I have updated RFC 2716bis with a list of changes, added a 
> section on privacy, rewritten the key hierarchy section to 
> utilize modern terminology (MSK, EMSK), and updated the 
> security considerations section.
> 
> The updated document is available here:
> http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt
> 
> Comments welcome.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Tying EAP-TLS method type to specific ciphersuites

[Joseph Salowey \(jsalowey\)]

We have had discussions on limiting the ciphersuites that are supported
by EAP-TLS in the past.  In particular it seemed that there was some
leaning towards limiting it to certificate based ciphersuites.  For the
most part this seems unnecessary since TLS supports ciphersuite
negotiation.  However some have raised the concern that negotiating the
use of different credentials may not be appropriate at the TLS level.
If this is the case then one approach would be to assign different EAP
method types to different types of ciphersuites. 

Do people see the need to limit the types of ciphersuites that can be
negotiated within EAP-TLS?  

If so what would be the appropriate way to divide up the ciphersuites
with method types? 

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Tentative Agenda for EMU at IETF 67

[Joseph Salowey \(jsalowey\)]

Below is the tentative agenda for EMU.  Please let me know if you have
any additions or corrections.

Thanks,

Joe

EMU Agenda For IETF 67
--
EMU Session 1 (2 hours)
Monday, Afternoon Session I 1300-1500
Room Name: Harbor 1
--

1. Agenda bashing, blue sheets, note takes - 5 min

2. EAP-TLS (Aboba) - 30 min

http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt

3. EAP-GPSK (Clancy/Tschofenig) - 30 min 

http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-00.txt

4. TLS-Enhanced (TBD) - 25 min

5. Password based method (TBD) - 25 min

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

[Joseph Salowey \(jsalowey\)]

Looks good to me. 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, October 22, 2006 8:47 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> >The document should also state in the security 
> considerations section 
> >that the identity in the identity response is not 
> necessarily related 
> >to the identity authenticated in EAP-TLS and should not be 
> relied upon 
> >for any access control or accounting purposes.
> 
> Here is some proposed new text for Section 2.4:
> 
> "As noted in [RFC3748] Section 5.1:
> 
>It is RECOMMENDED that the Identity Response be used primarily for
>routing purposes and selecting which EAP method to use.  EAP
>Methods SHOULD include a method-specific mechanism for obtaining
>the identity, so that they do not have to rely on the Identity
>Response.
> 
> As part of the TLS negotiation, the server presents a 
> certificate to the peer, and if mutual authentication is 
> requested, the peer presents a certificate to the server.  
> EAP-TLS therefore provides a mechanism for determining both 
> the peer identity (Peer-Id in [KEYFRAME]) and server identity 
> (Server-Id in [KEYFRAME]).
> Since the identity presented in the Identity Response need 
> not be related to the identity presented in the peer 
> certificate, EAP-TLS implementations SHOULD NOT require that 
> they be identical, and SHOULD NOT use the identity presented 
> in the Identity Response for access control or accounting purposes."
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, October 22, 2006 9:39 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> Joe Salowey said:
> 
> >Currently the section states that the peer identity is obtained from 
> >the subjectAltName in the certificate.  Is this text meant to be 
> >normative?
> >Currently there are implementations
> >that use elements of the subject distinguished name and do 
> not provide 
> >a subjectAltName.
> >
> >Perhaps it would be better to say the subjectAltName is used 
> if it is 
> >present and if it is not then the subject distinguished name is used.
> >However it seems that RFC3280 might indicate that it would 
> be better to 
> >use subject distinguished name if it is present and subjectAltName if
> >not. This section should  reference RFC3280.   Also is there 
> any reason
> >why mapping using a directory service is called out, isn't 
> just mapping 
> >to a Peer-ID or Server-ID sufficient?
> >
> >It would may also be good to say that an EAP-TLS implementation MAY 
> >make other certificate fields available to the lower layer.
> 
> I've added some text in Section 4.2 that hopefully will clear this up:
> 
> 4.2.  Certificate Usage
> 
>The EAP-TLS peer name (Peer-Id) represents the Network Access
>Identifier (NAI) [RFC4282] to be used for authorization and
>accounting purposes.  The Peer-Id is determined from the subject or
>altSubjectName fields in the peer certificate.  As noted 
> in [RFC3280]
>Section 4.1.2.6:
> 
>   The subject field identifies the entity associated with 
> the public
>   key stored in the subject public key field.  The 
> subject name MAY
>   be carried in the subject field and/or the subjectAltName
>   extension...  If subject naming information is present 
> only in the
>   subjectAltName extension (e.g., a key bound only to an email
>   address or URI), then the subject name MUST be an empty sequence
>   and the subjectAltName extension MUST be critical.
> 
>   Where it is non-empty, the subject field MUST contain an X.500
>   distinguished name (DN).
> 
>Where the subject field is not empty, the Peer-Id and Server-Id are
>obtained from the Common Name (CN) field of the DN.  Where subject
>naming information is present only in the subjectAltName extension,
>the Peer-Id and Server-Id are obtained from the subjectAltName.
> 
[Joe] OK

>A valid EAP-TLS client certificate SHOULD contain an 
> extendedKeyUsage
>value indicating support for Client Authentication
>(1.3.6.1.5.5.7.3.2).  A valid EAP-TLS server certificate SHOULD
>contain an extendedKeyUsage value indicating support for Server
>Authentication (1.3.6.1.5.5.7.3.1).
> 
[Joe] I think I remember that some protocols specify the presence of a
specific EKU or the ANY EKU.

>As discussed in [He], the security of EAP-TLS can be compromised if
>the same credentials are used for authentication within multiple
>applications.  

[Joe] I haven't looked at [He] in a while, but I thought that it wasn't
applications in general, but applications that use a protocol that
bindly signs arbitrary data. Perhaps this should be a bit clearer. 

>  Certificate extensions for use with EAP-TLS are
>discussed in "Certificate Extensions and Attributes Supporting
>Authentication in Point-to-Point Protocol (PPP) and Wireless Local
>Area Networks (WLAN)" [RFC4334].  These extensions enable 
> certificate
>usage to be restricted to use with lower layers such as 
> PPP or IEEE 802.11.
>An EAP-TLS implementation MAY make these and other 
> certificate fields
>available to the lower layer.
> 
[Joe] OK

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Tying EAP-TLS method type to specific ciphersuites

[Joseph Salowey \(jsalowey\)]

I think the typecode and separate document are orthogonal.  There has been 
discussion of adding enhancements to EAP-TLS, such as channel bindings, which 
would probably not be backward compatible.  In this case we would need a new 
typecode for this new protocol.  PSK or other ciphersuites could be negotiated 
in TLS under this method type.  

Joe

> -Original Message-
> From: Tschofenig, Hannes [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, October 26, 2006 9:52 AM
> To: Charles Clancy; Bernard Aboba
> Cc: emu@ietf.org
> Subject: AW: [Emu] Tying EAP-TLS method type to specific ciphersuites
> 
>  Hi Charles,
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Charles Clancy [mailto:[EMAIL PROTECTED]
> > Gesendet: Donnerstag, 26. Oktober 2006 18:45
> > An: Bernard Aboba
> > Cc: emu@ietf.org
> > Betreff: RE: [Emu] Tying EAP-TLS method type to specific 
> ciphersuites
> > 
> > So, it sounds like defining an EAP type code for EAP-TLS 
> with non-PKI 
> > ciphersuites sounds like the best way to go.  Would it be 
> appropriate 
> > to have IANA allocate a new EAP type code with 2716bis, or have a 
> > seperate document discussing EAP-TLS with TLS-PSK ciphersuites?
> 
> A separate document is needed since the security properties 
> are different.
> You need to describe them somewhere. 
> 
> Example:
> draft-otto-emu-eap-tls-psk-01.txt
> 
> For some other ciphersuites you even need todo more. 
> Example: A Kerberos based TLS ciphersuite
> 
> Ciao
> Hannes
> 
> 
> > 
> > --
> > t. charles clancy, ph.d.  <>  [EMAIL PROTECTED]  <>  
> www.cs.umd.edu/~clancy
> > 
> > 
> > On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote:
> > >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2
> > (PKI and PSK)?
> > >> Or
> > >>EAP-TLS-PKI and EAP-TLS-PSK?  If we have both legacy issues
> > AND footprint
> > >>issues, perhaps something like ...
> > >
> > > So far, we've talked about handling PSK support by creating
> > a new EAP
> > > method
> > > with a distinct name: "EAP-TLS-PSK".That approach 
> > enables embedded
> > > devices to implement only PSK ciphersuites, reducing
> > footprint.   It also
> > > avoids impacting the interoperability and security of
> > existing EAP-TLS
> > > implementations.
> > >
> > > Given that EAP-TLS already supports PKI, I'm not sure why a
> > distinct EAP
> > > method called "EAP-TLS-PKI" would be needed.
> > >
> > > Creating "versions" of EAP-TLS would potentially confuse
> > customers and
> > > cause
> > > problems with existing test suites and certification
> > programs.  Witness
> > > the
> > > confusion that was created by PEAP versioning, where PEAPv0
> > and PEAPv1 did
> > > not interoperate.   So I'd stay away from versioning if at 
> > all possible.
> > >
> > >
> > >
> > > ___
> > > Emu mailing list
> > > Emu@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/emu
> > >
> > 
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Tying EAP-TLS method type to specific ciphersuites

[Joseph Salowey \(jsalowey\)]

I don't think we would go down the route of making other types of
ciphersuites mandatory to implement.  

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 23, 2006 9:17 AM
> To: emu@ietf.org
> Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites
> 
> During the EMU BOF we talked about the high cost that would 
> be imposed on customers by introducing new non-certificate 
> ciphersuites during EAP-TLS.
> 
> EAP-TLS is now ten years old, and has a very large installed base.  
> Virtually all of these installations only support 
> certificate-based authentication, since that is a requirement 
> of RFC 2716, which states:
> 
>If the EAP server is not resuming a previously established
>session, then it MUST include a TLS server_certificate handshake
>message, and a server_hello_done handshake message MUST be the last
>handshake message encapsulated in this EAP-Request packet
> 
>If the EAP server sent a certificate_request message in 
> the preceding EAP-Request packet, then
>the peer MUST send, in addition, certificate and 
> certificate_verify handshake messages.
> 
> As a result of these and other specification requirements, an 
> implementation that does not support certificate 
> authentication is non-compliant with RFC 2716.
> 
> During the BOF we also talked about the drawbacks of 
> attempting to support 
> both certificate and non-certificate modes in a single EAP 
> method.   Such an 
> approach would require embedded systems to take on the 
> footprint of certificate handling even when all they really 
> needed to do was to support pre-shared keys.  It would also 
> add new potential security vulnerabilities to one of the few 
> EAP methods that has provable security properties.
> 
> In addition adding new non-certificate modes would impose 
> large costs on customers. Today there are interoperability 
> and conformance test suites for EAP-TLS that assume that only 
> certificate-based authentication is supported. 
>   In addition, EAP-TLS has been approved for use within FIPS 
> 140-2 installations, based on support for certificate-base 
> ciphersuites.  
> Introducing new non-certificate modes would introduce 
> confusion, and would force existing test suites to be re-written.
> 
> For customers, deployment of EAP is difficult enough without 
> introducing confusion, interoperability problems and new 
> security vulnerabilities into the one EAP method that today 
> is synonmous with high security.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Password based mechanism Design team

[Joseph Salowey \(jsalowey\)]

Please send me a message if you are interested in participating on a
design team for the following EMU working group charter item:

- A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
of existing password databases such as AAA databases. The implementation
should strive to be usable in resource constrained
environments.

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 01, 2006 8:29 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> > >A valid EAP-TLS client certificate SHOULD contain an 
> > > extendedKeyUsage
> > >value indicating support for Client Authentication
> > >(1.3.6.1.5.5.7.3.2).  A valid EAP-TLS server certificate SHOULD
> > >contain an extendedKeyUsage value indicating support for Server
> > >Authentication (1.3.6.1.5.5.7.3.1).
> > >
> >[Joe] I think I remember that some protocols specify the 
> presence of a 
> >specific EKU or the ANY EKU.
> 
> Any references I should look at?   Other than RFC 3280, the 
> only reference I 
> could find is this:
> http://www.drizzle.com/~aboba/CPW/Hardjono-IETF55-TLScertProfile.pdf
> 

Good question, 

SMIME (RFC3850) discusses EKU in section 4.4.4 is the only reference I
found to anyExtendedKeyUsage. 

Documents such as RFC4556 (PKINIT) and RFC4334 (WLAN CERTS) use MAY when
discussing EKU.  

There are also examples where a specific EKU is required in RFC3161
(Time stamping protocol).

It seems that 3850,4556 and 4334 are more consistent with EAP-TLS usage.


> >[Joe] I haven't looked at [He] in a while, but I thought 
> that it wasn't 
> >applications in general, but applications that use a protocol that 
> >bindly signs arbitrary data. Perhaps this should be a bit clearer.
> 
> Yes, that was the issue.
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] EMU Summary

[Joseph Salowey \(jsalowey\)]

EMU working group Summary

EMU met on Monday afternoon. Our first agenda item was RFC2716bis
(EAP-TLS) where much of the discussion of open items centered around
certificate handling.  This document is almost ready for WG Last Call,
which should be started later this month.  Our second item was GPSK
(generalized pre-shared key) where we had some discussion of key
derivation and NIST requirements for key derivation.  This document is
also close to WG group last call which should occur before the next
IETF.  For the third agenda item we discussed approaches for a password
based method that works with existing password databases. This
discussion centered around the choice of reusing existing methods or
trying to develop something new. There was a general feeling that we
should avoid doing something new.  We will be forming a design team
shortly after this IETF meeting to work on this method type.  Finally we
had lengthy discussion on enhanced EAP-TLS and how negotiation should be
performed.  There were some good ideas uncovered in this discussion
which will be discussed on the list.  



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Draft minutes for EMU working group

[Joseph Salowey \(jsalowey\)]

Here are draft minutes from the EMU minutes.  Thanks to Donald and Hao
for taking excellent notes. 

EAP Method Update (EMU) working Group 
--
IETF 67
11/06/2006
13:00 
--
Chair: Joe Salowey

Note Takers: Donald Eastlake
   Hao Zhou

--
Agenda

1. Administrative
2. RFC2716bis (EAP-TLS)
3. EAP-GPSK
4. Password based
5. Enhanced-TLS

---
Administrative


- Current Drafts
EAP-TLS
draft-simon-emu-rfc-2716bis-04.txt
close to last call

EAP-GPSK
Draft-ietf-emu-eap-gpsk-00.txt
close to WGLC, but needs some more revision


RFC2716bis (EAP-TLS)
Presenter: Bernard Aboba
Draft: draft-simon-emu-rfc-2716bis-04.txt

Changes from RFC 2716, two draft revisions since last IETF 

- Open Issues

What if EKU (extended key usage) is present or ANY?
What if more than one altSubjectName?
Is result dependent on the order of altSubjectName fields?

Russ:Your description is accurate, any of EKU will work. If you want
to assign one, we can assign one.
Bernard: I would like to have a reference to point to 
Joe: I would like to avoid mandating a particular EKU
Bernard: The question is how to address that so existing implementation
is compatible. 

- EAP-TLS certificate profile different from TLS certificate profile?
RFC 4334 seems to assume yes.
But implementations typically just rely on TLS for cert
handling.

Dave Johnston: are we going to specify an EAP-TLS profile? The
IEEE802.16 standards assume it exists and refers to it.
Bernard Aboba: No. Maybe we need to specifically say there isn't such a
thing. Other people shouldn't be changing EAP-TLS by requiring OIDs,
etc., that will break existing implementation.
Joe: How is that?
Bernard: 802 has forked 3 version incompatible with existing
implementation. Existing implementation don't look for any EKU Oids.
Bernard: There is no such thing of EAP-TLS profile, if you create a new
profile, 
Joe: Existing implementations already has issue with dealing with CN and
SAN.
Bernard: At least they can look at RFC3280. Question is where do we go
from here. Look at 3280 to specify what people are doing today.
Russ: Two aspects: application needs to make authorization decision on
top of TLS, SIP RFC3269 is an example on how to deal with two SANs.
Bernard: Will look into it to modify.

Chair: target for working group last call at the end of November
beginning of December

EAP-GPSK
Presenter: Charles Clancy
Draft: Draft-ietf-emu-eap-gpsk-00.txt (-01 submitted, should be on site
soon)
Issue tracker: www.tschofenig.com:8080/eap-gpsk/ 

- Issues believed closed:
#4 delimiters in KDF (Key Derivation Function), swapped two
items for more self delimiting

Russ Housley: Doesn't conform to NIST 800-56A and should.
Hannes: What do we need to do?
Tim Polk: 800-56A is key establishment algorithms. This document has
requirements for KDFs. Specifies two functions with some mandatory and
optional fields. One is ASN.1 and one is byte string.
Sam Hartman: Is 800-56A a key hierarchy or for turning stuff into a
symmetric key?
Tim Polk: Not for hierarchy where you derive one key from another. We
are working on that but document is just an internal draft right now.

#3 KDF data, way to include arbitrary data has been taken out.
#5 cipher suites, AES-EAX-128 changed to AES-CBC-128.
#2 channel binding, has been removed but could be added back.


Minor KDF inconsistency. Now allows arbitrary length input but one case
where it says truncate is still there. 
Need to take out truncation.


-  Issues still open:

#5 error handling: what to do if there is a MAC error? Return en
error or just drop the packet? How long till user finds out about the
error?

Bernard Aboba: There is now an error message you can send back that
doesn't change state.
Lakshminath: maybe it's not DOS, but guessing the key
Charles: with strong key, we shouldn't worry about
Glen: It would be good to get some result back, knowing the reason.
Bernard: Radius client will try to retransmit, if message is discarded. 
Vidya: not just a radius problem, EAP problem as well. User experience
an issue 
Hannes: what do other EAP method uses
Bernard: EAP-TLS uses TLS-alert
Lakshminath: ok with EAP-failure as long as we put some user guidance on
how to deal with it
Vidya: Is EAP or radius failure?
Joe: They are linked, EAP-failure implies RADIUS reject
Bernard: RFC 3589 describe retry within the method
Charles: PSK is a strong key, we don't have to worry about offline and
online dictionary attack.

#1 Protected Results Indication
Define PRI within document, rather than as something that could
be added later.

Hannes: different than the first issue
Hao: Agree with Hannes, two different issu

RE: [Emu] CAPWAP and HOKEY interim meetings

[Joseph Salowey \(jsalowey\)]

There is an IEEE 802.1 interim in Monterey, CA 1/22 - 1/26 (most of the
rest of 802 is in London the week before).  I may attend Hokey if it
doesn't conflict with 802.1 sessions I need to attend. 

> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 17, 2006 10:01 AM
> To: [EMAIL PROTECTED]; emu@ietf.org
> Subject: [Emu] CAPWAP and HOKEY interim meetings
> 
> CAPWAP and HOKEY WGs,
> 
> The chairs of both CAPWAP and HOKEY feel an interim meeting 
> between IETF
> 67 and 68 is necessary in order to meet their respective 
> milestones.  Due to a likely overlap in some participants, 
> consecutive, co-located meetings are suggested.
> 
> The chairs propose to hold a 3-day event (1 day for HOKEY 
> followed by 2 days for CAPWAP) in the San Francisco Bay area 
> the week of January 22. Due to a preference of not traveling 
> on weekends, meeting Tue-Thu (Jan 23-25) is suggested.  
> Please send comments to the lists on the proposed schedule, 
> area, preference on dates, and which meeting(s) you're likely 
> to attend. 
> Also please indicate any possible overlooked conflicts with 
> conferences and other events.
> 
> If your organization would be interested in providing a venue 
> to host the event, please let us know.  In particular, we are 
> interested in your site's space availability, accessibility 
> to visitors, guest Internet connectivity, ability to provide 
> lunch, and proximity to a major airport and reasonably-priced hotels.
> 
> Thanks!
> 
> --
> t. charles clancy, ph.d.  <>  [EMAIL PROTECTED]  <>  www.cs.umd.edu/~clancy
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 22, 2006 8:48 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Issue: Definition of Session-Id, 
> Peer-Id,Server-Id for EAP GPSK
> 
> >[Joe] It seems that the server ID is as authenticated as the 
> client ID.
> >The server ID and client ID are associated with the shared 
> key.  If a 
> >different identity is asserted a different key would be selected and 
> >the protocol should fail.
> 
> Since more than one AAA server can have access to the 
> credentials, I don't see how the client can verify which 
> server it is talking to.  It only knows that the server has 
> access to the PSK, not which server it is.
> 
[Joe] Whether this identity belongs to an individual or a group depends
upon deployment.  A deployment could assign a separate identity for each
server with a different key, although I'm not sure what adavantage that
would bring.  

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id forEAP GPSK

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 22, 2006 8:52 AM
> To: [EMAIL PROTECTED]
> Cc: emu@ietf.org
> Subject: Re: [Emu] Issue: Definition of Session-Id, 
> Peer-Id,Server-Id forEAP GPSK
> 
> >Sounds reasonable, but I'm not entirely sure I'd call the ID_Server 
> >unauthenticated.  It's authenticated in GPSK-3 when the 
> server includes 
> >it in the key derivation to compute SK.  If the value was 
> changed by an 
> >attacker, the authentication would fail.
> 
> The client only confirms that the server has access to the 
> PSK, but it doesn't confirm the specific server identity.  
> This is different from TLS-based EAP methods where the client 
> can verify a certificate issued to a specific server.
> 
[Joe] Yes, by it's nature symmetric authentication is different than
asymmetric authentication, but that doesn't mean that an identity is not
authenticated in the symmetric case.  

> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Password based method design team

[Joseph Salowey \(jsalowey\)]

Hi all,

This message is to inform the EMU working group that EMU password based
design team has been formed.

The members of the design team are:
Charles Clancy, Hannes Tschofenig, Hao Zhou, Jouni Malinen, Madjid
Nakhjiri, Mohamed Badra, Pascal Urien, Ray Bell, Vijay Devarapalli and
the EMU chair. 

The purpose of this design team is to complete the following WG charter
item:
"A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
of existing password databases such as AAA databases. The implementation
should strive to be usable in resource constrained environments."

The output of the design team is one or more documents to the EMU
working group. This design team will use a separate mailing list and
conference calls.

The initial deliverable is a statement of a basic approach to be used in
developing the method sent to the working group list for discussion.

As with any design team in the IETF, the output of this design team must
be approved by the EMU working group nor carries any special
consideration in development of EMU working group consensus.

Cheers,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] WG Last Call: draft-simon-emu-rfc2716bis-05

[Joseph Salowey \(jsalowey\)]

This is a working group last call for draft-simon-emu-rfc2716bis-05.  

Please send you comments to the emu list by December 29, 2006. 

The document can be accessed here:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt.  

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[Joseph Salowey \(jsalowey\)]

Hi Bernard,

I'm not sure I understand some of the text below:


>The peer MUST verify the validity of the EAP server 
> certificate, and
>SHOULD also examine the Server-id in order to determine whether the
>EAP server can be trusted.  Even though a server certificate chains
>to a trust anchor, this does not necessarily imply that it is valid
>for connection to a particular network.
> 
>Comparing the Server-Id in the certificate to the expected server
>name limits the damage that will result from an attacker 
> compromising
>a server private key.  If the peer does not check the 
> Server-Id, then
>the peer would accept a compromised server certificate chaining to
>any of the configured trust anchors.
> 

[Joe] If the server key is compromised then it seems checking the
server-ID will not help discover this or limit damage.  

>The peer MAY also test whether the EAP server certificate is signed
>by a CA controlling the destination network and whether 
> the Server-Id
>matches the format expected for that network.  For example, an EAP
>peer connecting to the "EXAMPLE" SSID may check whether 
> the Server-Id
>matches the regular expression "*.example.com", in addition to
>checking whether the server certificate chains to the 
> example.com CA."
> 
> --
> -
> >From: <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>, 
> >Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
> >Date: Wed, 13 Dec 2006 09:52:13 +0200
> >
> >Thanks for handling my comments so quickly! (If every author 
> had this 
> >fast turnaround times, IETF would get documents to RFCs in a 
> fraction 
> >of current time... :-)
> >
> >About 1: the figure in 2.6 is not quite right yet. There should be a 
> >finished message after the first change_cipher_spec sent by 
> the server, 
> >and the certificate/server_key_exchange messages after the second 
> >server_hello are not optional.
> >
> >About 2: I'd further suggest rephrasing the last two paragraphs of
> >2.1.1 along these lines (basic case first, session 
> resumption second):
> >
> >If the peer supports EAP-TLS and is configured to use it, it MUST
> >respond to the EAP-Request with an EAP-Response packet of EAP-
> >Type=EAP-TLS.  If the preceding server_hello message sent by the
> >EAP server in the preceeding EAP-Request packet did not indicate
> >the resumption of a previous session, the data field of 
> this packet
> >MUST encapsulate one or more TLS records containing a TLS
> >client_key_exchange, change_cipher_spec and finished 
> messages.  If
> >the EAP server sent a certificate_request message in the 
> preceding
> >EAP-Request packet, then unless the peer is configured 
> for privacy
> >(see Section 2.6) the peer MUST send, in addition, 
> certificate and
> >certificate_verify messages.  The former contains a 
> certificate for
> >the peer's signature public key, while the latter contains the
> >peer's signed authentication response to the EAP server.  After
> >receiving this packet, the EAP server will verify the peer's
> >certificate and digital signature, if requested.
> >
> >If the preceding server_hello message sent by the EAP 
> server in the
> >preceding EAP-Request packet indicated the resumption of 
> a previous
> >session, then the peer MUST send only the change_cipher_spec and
> >finished handshake messages.  The finished message contains the
> >peer's authentication response to the EAP server.
> >
> >(And maybe Section 2.6 could be moved to 2.1.4?)
> >
> >About 7: This one is not there yet.
> >
> >About 9: The document still doesn't specify 
> mandatory-to-implement TLS 
> >version (which is required in addition to 
> mandatory-to-implement cipher 
> >suite to get interoperability).
> >
> >About 11: The S bit was removed from the bit diagram, but 
> the text "The 
> >S bit (EAP-TLS start) is set in an EAP-TLS Start message" is still 
> >there.
> >
> >Best regards,
> >Pasi
> >
> > > -Original Message-
> > > From: ext Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > Sent: 13 December, 2006 01:55
> > > To: Eronen Pasi (Nokia-NRC/Helsinki); emu@ietf.org
> > > Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
> > >
> > > I think I have now incorporated most of these comments into a 
> > > strawman -06 document:
> > > 
> http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt
> > >
> > > Let me know if I've missed something.
> >
> >___
> >Emu mailing list
> >Emu@ietf.org
> >https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/m

RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[Joseph Salowey \(jsalowey\)]

> > >Comparing the Server-Id in the certificate to the 
> expected server
> > >name limits the damage that will result from an 
> attacker compromising
> > >a server private key.  If the peer does not check the 
> Server-Id, then
> > >the peer would accept a compromised server certificate 
> chaining to
> > >any of the configured trust anchors.
> > >
> >
> >[Joe] If the server key is compromised then it seems checking the 
> >server-ID will not help discover this or limit damage.
> 
> Maybe this should have been "compromising a trust anchor 
> private key".  I think the idea was to prevent a compromise 
> of a trust anchor from enabling attackers to carry out "rogue 
> authenticator" attacks across the board.

[Joe] I don't think so, since a compromised trust anchor is a bigger
problem.  This text appears to mostly deal with authorization issues.
Here is a proposal for some modifications to the text:

In section 5.2, we may want to rethink the recommendation to use the TLS
WWW EKU, I'm not sure it is appropriate. Right now I suggest we remove
this paragraph. The text for the rest of the section could be replaced
by the following text. 

"Once the endpoints of the EAP-TLS conversation have been authenticated
and have had their certificates validated they then must be authorized.
The authorization process makes use of the contents of the certificates
as well as other contextual information.  While authorization
requirements will vary from deployment to deployment it is RECOMMENDED
that implementations be able to authorize based on the EAP Peer and EAP
Server identities defined above. 

Certificate extensions for use with EAP-TLS are discussed in
"Certificate Extensions and Attributes Supporting Authentication in
Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)"
[RFC4334].  These extensions enable certificate usage to be restricted
to use with lower layers such as PPP or IEEE 802.11.  An EAP-TLS
implementation MAY make these and other certificate fields available to
the lower layer.

Since authorization based on specific identities may not scale well in a
large environment implementations may make use of other fields in the
certificate.  For example an implementation may be configured to accept
all certificates issued by a CA with a certain name format as trusted.
In another example the peer may test whether the EAP server certificate
is signed by a CA controlling the destination network and whether the
Server-Id matches the format expected for that network.  For example, an
EAP peer connecting to the "EXAMPLE" SSID may check whether the
Server-Id matches the regular expression "*.example.com", in addition to
checking whether the server certificate chains to the example.com CA.
However, it is important to realize that any certificate matching the
above criteria will be authorized, so this method should only be used in
environments where this is guaranteed to be accurate."



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

[Joseph Salowey \(jsalowey\)]

It seems that most of the issues brought up in last call are resolved or
nearly resolved in draft-simon-emu-rfc2716bis-06.txt.  The one area
where we need more discussion is section 5.2 on certificate usage.
Below are the remaining open issue I have tracked with this section,
please indicate if there are others with this section or other sections
that I have missed.  

1. Use of TLS-WWW EKU 

The question was raised that the TLS WWW EKU may not be appropriate for
EAP-TLS.  The suggestion was made to remove the text on EKU.  Are
members of the working group in favor of removing this text? 

2. Discussion of naming

This section recommends

"Where the subjectAltName field is present, the Peer-Id or Server-Id
is set to the contents of the subjectAltName.  If subject naming
information is present only in the subject field, then the Peer-Id or
Server-Id is set to the Distinguished Name (DN)." 

It is possible that more than one subjectAltName may be present in a
certificate.  Are there any rules as to how this is represented as a
Peer name?  Also would it be more consistent to use the DN unless it is
empty?  

3. Discussion of authorization

The later part of this section seems to discuss authorization.  A
suggestion for revised text was made in
http://www1.ietf.org/mail-archive/web/emu/current/msg00309.html.  Does
the suggested text convey the necessary information? 


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 16, 2007 7:41 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
> 
> >1. Use of TLS-WWW EKU
> >
> >The question was raised that the TLS WWW EKU may not be 
> appropriate for 
> >EAP-TLS.  The suggestion was made to remove the text on EKU.  Are 
> >members of the working group in favor of removing this text?
> 
> There are a number of EAP-TLS implementations that require 
> TLS WWW EKUs (or any).  So in practice an implementation 
> needs to understand that or it may not interoperate.  It also 
> occurs to me that there could be some security issues that 
> would surface.  For example, if there is no indication that 
> an EAP-TLS server is authorized for that function (e.g. if it 
> doesn't contain a TLS WWW server EKU or any), then any 
> machine possessing an EAP-TLS client certificate chaining to 
> a trust anchor could use that certiciate to act as an EAP-TLS 
> server (assuming that the NASes were configured to trust it). 
>  It seems like this could make it easier to put up a rogue NAS.
> 

[Joe] It also seems that there are the same type of security issues with
using the TLS WWW EKUs.  There are the same certificates that are issued
to web servers.   However the TLS WWW server EKU at least differentiates
between the server and client role.  How about including:

"Some deployments may require the presence of client and server
authentication extended key usage extensions in certificates.  Client
implementations wishing to interoperate in these environments SHOULD
check the server's certificate for an Extended Key Usage field
implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special
keyPurposeID anyExtendedKeyUsage.  Server implementations wishing to
interoperate in this environment SHOULD check the client's certificate
for an Extended Key Usage field containing id-kp-clientAuth
(1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage.
Note that these key usage extension identifiers for server and client
authentication are somewhat generic and may not be sufficient to
authorize an entity's role specifically as an EAP-TLS client or server."



> With respect to the RFC 4334 OIDs, I'm ok with removing 
> mention of them.  
> There are no existing implementations, and as a result, there 
> should be no expectation that EAP-TLS clients or servers will 
> understand these extensions.  It seems like these OIDs are 
> problematic since they don't correspond to values of the 
> NAS-Port-Type attribute, and therefore can't be compared to 
> NAS-Port-Type values by implementations that don't understand them.
> 
[Joe] OK 

> >2. Discussion of naming
> >
> >This section recommends
> >
> >"Where the subjectAltName field is present, the Peer-Id or 
> Server-Id is 
> >set to the contents of the subjectAltName.  If subject naming 
> >information is present only in the subject field, then the 
> Peer-Id or 
> >Server-Id is set to the Distinguished Name (DN)."
> >
> >It is possible that more than one subjectAltName may be present in a 
> >certificate.  Are there any rules as to how this is represented as a 
> >Peer name?  Also would it be more consistent to use the DN 
> unless it is 
> >empty?
> 
> Can someone descirbe a case where there would be more than 
> one subjectAltName in a certificate?
> I'm having a hard time wrapping my head around this case.
> 
[Joe] The subjectAltName may contain a host name as DNSName and a
manufacturing serial number as an OtherName or perhaps it may contain a
UPN and a SIP URI. 

> >3. Discussion of authorization
> >
> >The later part of this section seems to discuss authorization.  A 
> >suggestion for revised text was made in 
> >http://www1.ietf.org/mail-archive/web/emu/current/msg00309.ht
> ml.  Does 
> >the suggested text convey the necessary information?
> 
> I'd suggest that the rest of the section include the 
> following text (missing the RFC 4334 discussion):
> 
> "Once the endpoints of the EAP-TLS conversation have been 
> authenticated and have had their certificates validated they 
> then must be authorized.
> The authorization process makes use of the contents of the 
> certificates as well as other contextual information.  While 
> authorization requirements will vary from deployment to 
> deployment it is RECOMMENDED that implementations be able to 
> authorize based on the EAP Peer and EAP Server identities 
> defined above.
> 
> Since authorization based on specific identities may not 
> scale 

RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 19, 2007 10:12 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt



> 
> > > Can someone descirbe a case where there would be more than one 
> > > subjectAltName in a certificate?
> > > I'm having a hard time wrapping my head around this case.
> > >
> >[Joe] The subjectAltName may contain a host name as DNSName and a 
> >manufacturing serial number as an OtherName or perhaps it 
> may contain a 
> >UPN and a SIP URI.
> 
> Any recommendations on what we should say about this?
> 
[Joe] There is no one field in all certificate that unequivocally
represents the "identity" for all EAP-TLS uses.  

For the mapping of certificate fields to name:

"If the peer's or server's certificate contains a non-empty subject name
then it is the peer or server name respectively.  If the subject name is
empty then the peer name maps to a subjectAltName.  Since the
subjectAltName may contain more than one instance of subjectAltName an
implementation should provide a means to choose which subjectAltName
type is used. An implementation may also provide configuration controls
to allow a particular subjectAltName type to override the subject name
when present."

I'm not sure that this maps sufficiently well to NAI as described in the
opening sentence of the first paragraph.  

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

Hi Ryan,
 
Thanks for posting this, I think it is very helpful.   I have some
questions in-line below:




From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 01, 2007 12:35 PM
To: emu@ietf.org
Subject: [Emu] draft-simon-emu-rfc2716bis-07.txt



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 2716 combined with RFC 3280.  For this
reason I believe that draft -07 is not suitable for advancement as a
Proposed Standard.

 

To address the issues, I propose that the current Sections 5.2
and 5.3 be replaced with the following text:

 

"5.2 Peer and Server Identities

 

   The EAP-TLS peer name (Peer-Id) represents the identity to be

   used for access control and accounting purposes.  The
Server-Id 
   represents the identity of the EAP server.

 

   In EAP-TLS, the Peer-Id and Server-Id are determined from the
subject
   or subjectAltName fields in the peer and server certificates.
As
   noted in [RFC3280] Section 4.1.2.6.

  

   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 subjectAltName as per Section 5.3.  

 

[Joe] Why subjectAltName and not Subject?  

 

   If subject naming information is present in only in the
subject name field

   then the Subject Field of the peer certificate SHOULD contain
a E RDN

   containing the Peer-Id and the Subject Field of the server
certificate MUST

   contain the CN RDN containing the Server-ID.  If subject
naming

   information is present only in the subjectAltName extension
then the subject

   field MUST be an empty sequence and the subjectAltName
extension

   MUST be critical. 

 

[Joe] What is E RDN?  

 

   Although the use of  the subject field is existing practice,
its use in EAP-TLS

   is deprecated and Certification Authorities are encouraged to
use 
   the subjectAltName field instead.

 

[Joe] Are there other standards that are deprecating the use of subject
field as well?  (This is related to my first question above.)

 

   Where the peer identity represents a host, a subjectAltName
of type 
   dNSName SHOULD be present in the peer certificate.  Where the
peer 
   identity represents a user and not a resource, a
subjectAltName of type
   rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section
2.1. 
   If the peer identity represents neither a host nor a user,
another field

   type (for example a subjectAltName of type iPAddress
   or uniformResourceIdentifier) MAY be used. 

[Joe] There may be hosts which do not have a DNSName or Ipaddress (L2
entities), so I think we need to clarify the above text. 

   A server identity will typically represent a host, not a user
or
   a resource.  As a result, a subjectAltName of type dNSName
SHOULD be
   present in the server certificate.  A subjectAltName of type
   iPAdress MAY be used in the server certificate. 

 

[Joe] We probably need to allow various name types for the server as
well.  I think there still needs to be some discussion on how
subjectAltNames map to peer and server names in the case where there are
multiple subjectAltNames.  

 

5.3.  Certificate Validation

 

   Since the EAP-TLS server is typically connected to the
Internet,
   it SHOULD support validating the  peer certificate using 
   RFC 3280 [RFC3280] conformant path validation, including the 
   ability to retrieve intermediate certificates that may be
   necessary to validate the peer certificate. For details, 
   see [RFC3280] Section 4.2.2.1.

 

   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, it must be pre-configured with the necessary 
   intermediate certificates to complete path validation or 
   rely on the EAP-TLS peer to provide this information as 
   part of the TLS Handshake (see [RFC4346] section 7.4.6).

   

   In contrast to the EAP-TLS server, the EAP-TLS peer may
   not have Internet connectivity. Therefore the EAP-TLS server 
   SHOULD provide its entire certificate chain minus the root to

   facilitate certificate validation by the peer.

 

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

Hi Ryan,

I understand the deprecation of subjectName in favor of SubjectAltName,
this makes sense to me now.  
 
I'm still struggling a little with mapping subjectAltName and
subjectName certificate fields to peer and server identities.  I think
the text you suggested for the server name subjectAltName mapping is
good:
 
[rmh] How about we change "A subjectAltName of type iPAdress MAY
be used
  [rmh] in the server certificate." To "If a dnsName is not
available other
[rmh] field types (for example a subjectAltName of type iPAdress
or
[rmh] uniformResourceIdentifier) MAY be used.

I think we should have similar text for the peer name.  There are cases
where either or both the EAP peer and EAP server may be devices that do
not have an RFC822 name or dnsName.  

I am a bit concerned with the text for the subject DN.  Why not use the
same field for both server and peer certificates?  In my experience the
email address in a certificate subject DN is not always the best
identifier. Could CN be used instead of email address?  

With regard to usage of OCSP, I understand the concern you raise.
However, the current practice of retrieving a CRL when attached to the
network and validating the accepted certificate seems to provide decent
protection.  The OCSP in TLS approach is a better approach, but how much
better is it?  A SHOULD is a fairly strong requirement and its use here
may affect how quickly this document can move through the standards
track.  I want to make sure we are getting significant benefit from this
added requirement. 

Joe



From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 1:04 PM
To: emu@ietf.org
Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt



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 subjectAltName as per Section
5.3.  

 

[Joe] Why subjectAltName and not Subject?  

[rmh] The use of the subject name was intended to
represent a directory location, directory locations may or

  may not include the a value that would reasonable
map to the subject id (eg a E rdn).

  its bad form to require people to change their
directory layout to deploy a application, therefore

  standards that take a dependency on a specific
name form being present in a certificate should do so

  by specifying that name form exist in the
subjectAltName.

 

   If subject naming information is present in only in
the

   subject name field then the Subject Field of the peer

   certificate SHOULD contain a E RDN containing the
Peer-Id.

 

[Joe] What is E RDN?  

[rmh] RDN is a relative distinguished name, DNs are made
up of these;

  There is a RDN is for the email address, I don't
have the X.500

  documents handy but its defined in there. I
remember the name being

  just E; however I did some googling and looks like
I was wrong its

  emailAddress.

 

   Although the use of  the subject field is existing
practice,

   its use in EAP-TLS is deprecated and Certification
Authorities

   are encouraged to use the subjectAltName field
instead.

 

[Joe] Are there other standards that are deprecating the
use of subject

field as well?  (This is related to my first question
above.)

 

[rmh] uid is the only other RDN that a peer-id like
value that might be used in

[rmh] however in practice I have never seen this used;
see my other comment as

[rmh] to why. This is one of the reasons other rfcs like
TLS deprecate use of the

[rmh] subject dn for subjectAltName instead (see 3.1 of
http://www.ietf.org/rfc/rfc2818.txt)



 

Where the peer identity represents a host, a
subjectAltName

of type dNSName SHOULD be present in the peer
certificate.  Where the

peer identity represents a user and not a resource, a
subjectAltName of type

rfc822Name SHOULD be used, conforming to the grammar for
the

Network Access Identifier (NAI) defined in [RFC4282]
Section 2.1. 

If the peer identity represents neither a host nor a
user,

another field type (for example a subjectAltName of type
iPAddress

or u

[Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt

[Joseph Salowey \(jsalowey\)]

This is a working group last call for draft-ietf-emu-eap-gpsk-03. 

Send your comments to the EMU list by March 7, 2007.  Please respond to
this call even if you have reviewed the draft and found no problems.  

The document can be accessed here:
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

802.1AR is not specifying that a device identity within a certificate
has to be a MAC address.  It can be any identifier that is unique within
a manufacturer's domain.  The current thinking is that the identity
would go in the common name of the subject name. 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 13, 2007 10:59 AM
> To: emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> Question:
> 
> What about a device that has a MAC address as a name?  Use of 
> EAP-TLS with MAC certificates is being discussed in WiMAX 
> Forum and IEEE 802.1AR.  Where should the MAC address be 
> placed (subject vs. subjectAltName) and what field type 
> should it have?  Is there a reference that defines the 
> formatting of field types? Is there guidance on how to format 
> the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs. 
> 00:03:7B:5F:CE:73 in IEEE 802.1AR).
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

Comments inline below.

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 13, 2007 10:35 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> 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 
> SubjectAltName,
> this makes sense to me now.  
>  
> I'm still struggling a little with mapping subjectAltName and
> subjectName certificate fields to peer and server identities.  I think
> the text you suggested for the server name subjectAltName mapping is
> good:
>  
> [rmh] How about we change "A subjectAltName of type 
> iPAdress MAY
> be used
> [rmh] in the server certificate." To "If a dnsName is not
> available other
> [rmh] field types (for example a subjectAltName of 
> type iPAdress
> or
> [rmh] uniformResourceIdentifier) MAY be used.
> 
> I think we should have similar text for the peer name.  There 
> are cases
> where either or both the EAP peer and EAP server may be 
> devices that do
> not have an RFC822 name or dnsName.  
> 
>   [rmh] Could you propose some text that would address your
> concern?
>   [rmh] It was my hope that the following (from the original
> proposal)
>   [rmh] would address this concern:
>  
>   If the peer identity represents neither a host nor a
> user, another field
>   type (for example a subjectAltName of type iPAddress
>   or uniformResourceIdentifier) MAY be used.
> 
[Joe] OK, I think it does.  Here is what I have for the text around
SubjectAltName

   "Although the use of  the subject field is existing practice, its use
in EAP-TLS
   is deprecated and Certification Authorities are encouraged to use 
   the subjectAltName field instead.

   Where the peer identity represents a host, a subjectAltName of type 
   dNSName SHOULD be present in the peer certificate.  Where the peer 
   identity represents a user and not a resource, a subjectAltName of
type
   rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. 
   If the peer identity represents neither a host nor a user, another
field
   type (for example a subjectAltName of type iPAddress
   or uniformResourceIdentifier) MAY be used. 


   A server identity will typically represent a host, not a user or
   a resource.  As a result, a subjectAltName of type dNSName SHOULD be
   present in the server certificate.  If a dnsName is not available
other
   field types (for example a subjectAltName of type iPAdress or
   uniformResourceIdentifier) MAY be used."

> 
> I am a bit concerned with the text for the subject DN.  Why 
> not use the
> same field for both server and peer certificates?  In my 
> experience the
> email address in a certificate subject DN is not always the best
> identifier. Could CN be used instead of email address?
> 
>   [rmh] CNs contain common names, for example my CN in the
> directory is Ryan Hurst,
>   [rmh] this is the appropriate use of CN and as you can see this
> is not non-ambiguous
>   [rmh] (there is a actor with the same name BTW).
> 
>   [rmh] Since servers do not have "common names" it is has become
> standard to put the
>   [rmh] DNS name in the common name field instead of using a
> dNSName RDN (I am not even sure
>   [rmh] one exists). 
> 
>   [rmh] In the case of user certificates clearly users have common
> names, and applications almost
>   [rmh] universally expect this field to be present for display
> purposes. It's this reason the eMail 
>   [rmh] address (when present in a DN) is put into its own RDN.
> 
>   [rmh] The proposed text is consistent with all certificate
> mapping implementations I have ever encountered,
>   [rmh] and it should also be consistent with the HTTP over SSL
> RFC that prescribes much of the same.
> 
[Joe] With certificates embedded in device the email address portion of
the DN is not used so consistently, it does not typically refer to the
email address of the device but rather of an organization. 

>   [rmh] In the end applications have one of two choices when doing
> mapping, map on the full subject DN or
>   [rmh] map on the email address and we should not specify
> anything inconsistent with that as it will lead
>   [rmh] to problems.
> 
[Joe] It seems that mappi

[Emu] EAP-TLS and OCSP

[Joseph Salowey \(jsalowey\)]

Currently EAP-TLS does not require OCSP.  Ryan has requested that we
make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD
implement in EAP-TLS.  

The benefit of this is that it allows the peer to check for certificate
revocation before it has access to the network.  Without this if the
peer does not have an up to date CRL it must defer revocation checking
until it has network access and can receive an up to date CRL.  The peer
must limit its trust of the security of its network connection until it
can access the CRL.  

The downside of this is that it places a new requirement on EAP-TLS
implementations.  Even though it is a SHOULD and not a MUST it is
important to realize that a SHOULD is a requirement to implement unless
there are circumstances which make this requirement not apply to a
particular situation.  

I would like to here views from the working group on this topic.

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

Hi Ryan,

Looks pretty good, two comments inline below.

Joe 

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 14, 2007 3:00 PM
> To: Ryan Hurst; Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> Bernard - I believe this block of text represents the changes 
> we have discussed in the thread, I would use it in your next release.
> 
> "5.2 Peer and Server Identities
>  
>The EAP-TLS peer name (Peer-Id) represents the identity to be 
>used for access control and accounting purposes.  The Server-Id 
>represents the identity of the EAP server.
>  
>In EAP-TLS, the Peer-Id and Server-Id are determined from 
> the subject
>or subjectAltName fields in the peer and server certificates.  As
>noted in [RFC3280] Section 4.1.2.6.
>   
>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 subjectAltName as per Section 5.3.  
>  
>If subject naming information is present in only in the 
> subject name field
>then the Subject Field of the peer certificate SHOULD 
> contain a emailAddress RDN
>containing the Peer-Id 

[Joe] Can we qualify this with user and device as we did with
subjectAltName?

"If subject naming information is present in only in the subject name
field then the Subject Field of and the peer identity represents a user
the certificate SHOULD contain a emailAddress RDN.  If the peer identity
represents a host or device the certificate SHOULD contain a CN RDN or
Serial Number RDN. The Subject Field of the server certificate MUST
contain the CN RDN or Serial Number RDN containing the Server-ID.  

> If subject naming
>information is present only in the subjectAltName 
> extension then the subject
>field MUST be an empty sequence and the subjectAltName extension
>MUST be critical. 
>  



>However, in the case where the EAP-TLS peer is attempting 
> to obtain network
>access, it will not have network connectivity and is therefore not
>capable of checking for certificate revocation until after
>authentication completes and network connectivity is available.  
>For this reason EAP-TLS peers and servers SHOULD implement 
>Certificate Status Request messages, as described in [RFC3546] 
>section 3.6.  To enable revocation checking in situations 
>where servers do not support Certificate
>Status Request messages and network connectivity is not
>available prior to authentication completion,  peer 
>implementations SHOULD also support checking for certificate 
>revocation after authentication completes and network connectivity 
>is available, and SHOULD utilize this capability.

[Joe] OK, if we go with OCSP as a SHOULD then I think checking for
certificate revocation after network authentication completes should be
MUST to implement for the peer since there is a possibility that OCSP
will not be available in the server implementation. 

> "
> 
> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 14, 2007 1:12 PM
> To: Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> 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 the
> -08
> version of the document, submitted by the IETF 68 deadline.
> 
> To make it easier for me to figure out what that text is, it 
> would be helpful for someone to post the suggested changes in 
> their entirety, with modifications agreed to during the 
> discussion.  Further comments can then refer to that text, 
> suggesting specific changes.
> 
> Having that record on the mailing list will make it a lot 
> easier for me to figure out what changes to make to the document.
> 
> Thanks in advance,
> 
> Bernard
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 16, 2007 10:23 AM
> To: Ray Bell; Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> Ray - I am familiar with the cable labs stuff, they put the 
> MAC in the CN although if I recall they don't specify how the 
> value should be represented which really limits its value IMHO.
> 
> I have looked at 802.1ar and from what I can tell they have 
> not decided where the value should go in their certificate 
> profile, from the various revisions it looks like they have 
> considered many locations from the CN, certificate Serial 
> Number, subject serial number to a SAN othernames.
> 
[Joe] The identifier in AR is not necessarily a MAC address. The
identifier format is determined by the manufacturuer. 

> I have spoken to Bernard off-line and he has convinced me 
> that it would be useful for there to be a appendix discussing 
> how one would include this value in a certificate if it's to 
> be used within EAP-TLS. 
> 
[Joe] What value?

> I want to ping a few people for their opinions on location, 
> my initial take is that specifying a consistent format to 
> represent the value as and putting it in the CN or the 
> subjectAltName:OtherName:PI are probably the best bests but I 
> need to think about it more.
> 
[Joe] I'm not quite sure what value you are talking about, but if it is
a device identity then why not the SN RDN.  

> 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: draft-simon-emu-rfc2716bis-07.txt
> 
> The CableLabs Device PKI process should be considered...
> 
> http://www.cablelabs.com/certqual/security/
> 
> Ray
> 
> 
> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 13, 2007 1:38 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> 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 can tell it has been added to facilitate 
> better certificate selection but there are much better ways 
> to achieve that; I have been tempted to write a informational 
> on how proper certificate selection is done but have not had the time.
> 
> The problem with a MAC address is that certificates normally 
> contain bindings of entitlements or constraints, these are 
> all assertions that the CA can stand behind (I have verified 
> that the holder of this key has the rights to this fqdn, I 
> have verified he is entitled to represent that FQDN for 
> server TLS transactions, etc.).
> 
> You just can't do that with a MAC address, not in any 
> reasonable way; now device identity is a SUPER important 
> thing without it we will continue to take dependencies on 
> weak identifiers like MAC addresses to perform exceptions and 
> entitlements (which essentially throw out any security value 
> modern isolation solutions provide) so the work being done by 
> AR is important.
> 
> As for where AR puts the identity, generally speaking you 
> should be able to tell what is in a RDN given a certificate 
> usage; so if AR has a EKU for Device Authentication I suppose 
> its fine for it to say when this EKU is present the RDN CN 
> has special meaning, otherwise it should go elsewhere.
> 
> Actually now that I think about it I would suggest that they 
> go in subjectAltName; again the general thinking about 
> Subject DNs is they map to a directory entity; this isn't 
> always the case and its likely not the case with a device 
> certificate (many assumptions in this statement so be kind), 
> in such cases its probably more appropriate to have a empty 
> Subject DN and use a existing name form (urn, etc.) in 
> subjectAltName or define a new name form for the 
> subjectAltName extension.
> 
> Ryan
> -Original Message-
> From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 13, 2007 12:18 PM
> To: Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> 802.1AR is not specifying that a device identity within a 
> certificate has to be a MAC address.  It can be any 
> identifier that is u

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

> > I want to ping a few people for their opinions on location, 
> my initial 
> > take is that specifying a consistent format to represent 
> the value as 
> > and putting it in the CN or the subjectAltName:OtherName:PI are 
> > probably the best bests but I need to think about it more.
> > 
> [Joe] I'm not quite sure what value you are talking about, 
> but if it is a device identity then why not the SN RDN.  
> [rmh] The problem with just saying SN RDN is that you can 
> have many RDNs in a given DN, plus by putting in the DN you 
> potentially require directory schemas to change to 
> accommodate; the PI RFC
> (http://www.ietf.org/rfc/rfc4043.txt) documents how one 
> handles the multiple RDN situation and specifies a othername 
> name-form for subjectAltName which allows you to specify the 
> value without the directory hit.
> [rmh] Problem with PI is its intended for people not devices, 
> however from my read it has all the right properties to deal 
> with a device id such as a MAC address.
> 
[Joe] OK, got it. A consistent place to find a MAC address in a cert.
If this is the case I don't think CN is appropriate since it is used for
all sorts of random stuff.  I agree that  subjectAltName:OtherName:PI
looks promising.  I support we could also define a MAC address OID. 

> > 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: draft-simon-emu-rfc2716bis-07.txt
> > 
> > The CableLabs Device PKI process should be considered...
> > 
> > http://www.cablelabs.com/certqual/security/
> > 
> > Ray
> > 
> > 
> > -Original Message-
> > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 13, 2007 1:38 PM
> > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> > 
> > 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 can tell it has been added to facilitate better certificate 
> > selection but there are much better ways to achieve that; I 
> have been 
> > tempted to write a informational on how proper certificate 
> selection 
> > is done but have not had the time.
> > 
> > The problem with a MAC address is that certificates 
> normally contain 
> > bindings of entitlements or constraints, these are all 
> assertions that 
> > the CA can stand behind (I have verified that the holder of 
> this key 
> > has the rights to this fqdn, I have verified he is entitled to 
> > represent that FQDN for server TLS transactions, etc.).
> > 
> > You just can't do that with a MAC address, not in any 
> reasonable way; 
> > now device identity is a SUPER important thing without it we will 
> > continue to take dependencies on weak identifiers like MAC 
> addresses 
> > to perform exceptions and entitlements (which essentially throw out 
> > any security value modern isolation solutions provide) so the work 
> > being done by AR is important.
> > 
> > As for where AR puts the identity, generally speaking you should be 
> > able to tell what is in a RDN given a certificate usage; so 
> if AR has 
> > a EKU for Device Authentication I suppose its fine for it 
> to say when 
> > this EKU is present the RDN CN has special meaning, otherwise it 
> > should go elsewhere.
> > 
> > Actually now that I think about it I would suggest that they go in 
> > subjectAltName; again the general thinking about Subject 
> DNs is they 
> > map to a directory entity; this isn't always the case and 
> its likely 
> > not the case with a device certificate (many assumptions in this 
> > statement so be kind), in such cases its probably more 
> appropriate to 
> > have a empty Subject DN and use a existing name form (urn, etc.) in 
> > subjectAltName or define a new name form for the subjectAltName 
> > extension.
> > 
> > Ryan
> > -Original Message-
> > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 13, 2007 12:18 PM
> > To: Bernard Aboba; emu@ietf.org
> > Subject: RE: [Emu] RE: draft-s

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Joseph Salowey (jsalowey) 
> Sent: Friday, February 16, 2007 11:25 AM
> To: Ryan Hurst; Ray Bell; Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> 
> 
> > > I want to ping a few people for their opinions on location,
> > my initial
> > > take is that specifying a consistent format to represent
> > the value as
> > > and putting it in the CN or the subjectAltName:OtherName:PI are 
> > > probably the best bests but I need to think about it more.
> > > 
> > [Joe] I'm not quite sure what value you are talking about, 
> but if it 
> > is a device identity then why not the SN RDN.
> > [rmh] The problem with just saying SN RDN is that you can have many 
> > RDNs in a given DN, plus by putting in the DN you 
> potentially require 
> > directory schemas to change to accommodate; the PI RFC
> > (http://www.ietf.org/rfc/rfc4043.txt) documents how one handles the 
> > multiple RDN situation and specifies a othername name-form for 
> > subjectAltName which allows you to specify the value without the 
> > directory hit.
> > [rmh] Problem with PI is its intended for people not 
> devices, however 
> > from my read it has all the right properties to deal with a 
> device id 
> > such as a MAC address.
> > 
> [Joe] OK, got it. A consistent place to find a MAC address in a cert.
> If this is the case I don't think CN is appropriate since it 
> is used for all sorts of random stuff.  I agree that  
> subjectAltName:OtherName:PI looks promising.  I support we 
> could also define a MAC address OID. 

[Joe] Should be "I suppose" instead of "I support" 

> 
> > > 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: draft-simon-emu-rfc2716bis-07.txt
> > > 
> > > The CableLabs Device PKI process should be considered...
> > > 
> > > http://www.cablelabs.com/certqual/security/
> > > 
> > > Ray
> > > 
> > > 
> > > -Original Message-
> > > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, February 13, 2007 1:38 PM
> > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> > > 
> > > 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 can tell it has been added to facilitate better 
> certificate 
> > > selection but there are much better ways to achieve that; I
> > have been
> > > tempted to write a informational on how proper certificate
> > selection
> > > is done but have not had the time.
> > > 
> > > The problem with a MAC address is that certificates
> > normally contain
> > > bindings of entitlements or constraints, these are all
> > assertions that
> > > the CA can stand behind (I have verified that the holder of
> > this key
> > > has the rights to this fqdn, I have verified he is entitled to 
> > > represent that FQDN for server TLS transactions, etc.).
> > > 
> > > You just can't do that with a MAC address, not in any
> > reasonable way;
> > > now device identity is a SUPER important thing without it we will 
> > > continue to take dependencies on weak identifiers like MAC
> > addresses
> > > to perform exceptions and entitlements (which essentially 
> throw out 
> > > any security value modern isolation solutions provide) so 
> the work 
> > > being done by AR is important.
> > > 
> > > As for where AR puts the identity, generally speaking you 
> should be 
> > > able to tell what is in a RDN given a certificate usage; so
> > if AR has
> > > a EKU for Device Authentication I suppose its fine for it
> > to say when
> > > this EKU is present the RDN CN has special meaning, otherwise it 
> > > should go elsewhere.
> > > 
> > > Actually now that I think about it I woul

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 
> >If subject naming information is present in only in the subject 
> > name field
> >then the Subject Field of the peer certificate SHOULD contain a 
> > emailAddress RDN
> >containing the Peer-Id
> 
> [Joe] Can we qualify this with user and device as we did with 
> subjectAltName?
> 
> "If subject naming information is present in only in the 
> subject name field then the Subject Field of and the peer 
> identity represents a user the certificate SHOULD contain a 
> emailAddress RDN.  If the peer identity represents a host or 
> device the certificate SHOULD contain a CN RDN or Serial 
> Number RDN. The Subject Field of the server certificate MUST 
> contain the CN RDN or Serial Number RDN containing the Server-ID.  
> 
> [rmh] As I understand it the peer ID always (essentially) 
> looks like a email address so host or otherwise it seems 
> appropriate to use the emailAddress RDN; this also (based on 
> my experience) represents current practice with the Subject 
> DN being deprecated any new name-forms should be proposed in 
> the subjectAltName shouldn't it?
>
[Joe] The peer name often takes the form of [EMAIL PROTECTED], but it does not
necessarily have to.  Another problem is that some existing device
implementations use the email address RDN, but it does not have a unique
identifier in it. 

  
> > If subject naming
> >information is present only in the subjectAltName extension then 
> > the subject
> >field MUST be an empty sequence and the subjectAltName extension
> >MUST be critical. 
> >  
> 
> 
> 
> >However, in the case where the EAP-TLS peer is 
> attempting to obtain 
> > network
> >access, it will not have network connectivity and is 
> therefore not
> >capable of checking for certificate revocation until after
> >authentication completes and network connectivity is available.  
> >For this reason EAP-TLS peers and servers SHOULD implement 
> >Certificate Status Request messages, as described in [RFC3546] 
> >section 3.6.  To enable revocation checking in situations 
> >where servers do not support Certificate
> >Status Request messages and network connectivity is not
> >available prior to authentication completion,  peer 
> >implementations SHOULD also support checking for certificate 
> >revocation after authentication completes and network 
> connectivity 
> >is available, and SHOULD utilize this capability.
> 
> [Joe] OK, if we go with OCSP as a SHOULD then I think 
> checking for certificate revocation after network 
> authentication completes should be MUST to implement for the 
> peer since there is a possibility that OCSP will not be 
> available in the server implementation. 
> [rmh] Well this should always be a matter of policy (maybe I 
> have other ways to mitigate this risk in my environment), 
> this is the core issue with the requirement being a MUST. In 
> such situations most specs leave these sorts of requirements 
> as a SHOULD, we could put a MUST in there with some words 
> that still let you choose though; what do you want to do?
> 
[Joe] Right there is a difference between required to implement and
required to deploy.  In most cases the MUSTs, SHOULDs, etc are required
to implement.  A particular deployment can often disable a particular
feature if it does not work in their environment. 
I think in this version of the text we have a MUST requirement for
certificate revocation checks which is different than the SHOULD in
RFC2716.  If the peer must be able to perform certificate validation
then it needs to have a mechanism to do this.  Since OCSP in TLS (RFC
4366) is a SHOULD it may not be implemented in a server the peer is
talking to, in which case the peer must be able to fall back to post
connection checks.  It seems the first SHOULD in the text refers to
support in an implementation and the second refers to deployment.  It
seems inconsistent to have a MUST for revocation and no mandatory way to
do it, but perhaps the MUST for CRL support covers it.  

> 
> > "
> > 
> > -Original Message-
> > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 14, 2007 1:12 PM
> > To: Bernard Aboba; emu@ietf.org
> > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> > 
> > 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 the
> > -08
> > version of the document, submitted by the IETF 68 deadline.
> > 
> > To make it easier for me to figure out what that text is, 
> it would be 
> > helpful for someone to post the suggested changes in their 
> entirety, 
> > with modifications agreed to during the discussion.  
> Further comments 
> > can then refer to that text, suggesting specific changes.
>

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

> > [rmh] As I understand it the peer ID always (essentially) 
> looks like a 
> > email address so host or otherwise it seems appropriate to use the 
> > emailAddress RDN; this also (based on my experience) represents 
> > current practice with the Subject DN being deprecated any new 
> > name-forms should be proposed in the subjectAltName shouldn't it?
> >
> [Joe] The peer name often takes the form of [EMAIL PROTECTED], but 
> it does not necessarily have to.  Another problem is that 
> some existing device implementations use the email address 
> RDN, but it does not have a unique identifier in it. 
> [rmh] Could you provide me a example? Is it a "unique" device 
> ID of some sort?

[Joe] Manufacturing installed certificates will not have a realm since
the realm will not be known at manufacturing time.  I have seen
manufacturing installed certificates where the email address field of
the DN contains a contact address such as "[EMAIL PROTECTED]".  I do
see your point about email address having a similar form to NAI.
Perhaps something like the following would be better text?

" If subject naming information is present in only in the subject name
field
then the Subject Field of the peer certificate SHOULD contain a
emailAddress RDN
containing the Peer-Id and the Subject Field of the server certificate
SHOULD
contain the CN RDN containing the Server-ID.  The peer and server ID MAY
appear in a different field such as the serialNumber RDN, especially in
the case where the deployment realm or domain of the certificate is not
known at the time the certificate is issued (for example at
manufacturing time). If subject naming information is present only in
the subjectAltName extension then the subject
field MUST be an empty sequence and the subjectAltName extension
MUST be critical. "

>   
> > > If subject naming
> > >information is present only in the subjectAltName 
> extension then 
> > > the subject
> > >field MUST be an empty sequence and the subjectAltName 
> extension
> > >MUST be critical. 
> > >  
> > 
> > 
> > 
> > >However, in the case where the EAP-TLS peer is
> > attempting to obtain
> > > network
> > >access, it will not have network connectivity and is
> > therefore not
> > >capable of checking for certificate revocation until after
> > >authentication completes and network connectivity is 
> available.  
> > >For this reason EAP-TLS peers and servers SHOULD implement 
> > >Certificate Status Request messages, as described in [RFC3546] 
> > >section 3.6.  To enable revocation checking in situations 
> > >where servers do not support Certificate
> > >Status Request messages and network connectivity is not
> > >available prior to authentication completion,  peer 
> > >implementations SHOULD also support checking for certificate 
> > >revocation after authentication completes and network
> > connectivity
> > >is available, and SHOULD utilize this capability.
> > 
> > [Joe] OK, if we go with OCSP as a SHOULD then I think checking for 
> > certificate revocation after network authentication 
> completes should 
> > be MUST to implement for the peer since there is a possibility that 
> > OCSP will not be available in the server implementation.
> > [rmh] Well this should always be a matter of policy (maybe I have 
> > other ways to mitigate this risk in my environment), this 
> is the core 
> > issue with the requirement being a MUST. In such situations 
> most specs 
> > leave these sorts of requirements as a SHOULD, we could put 
> a MUST in 
> > there with some words that still let you choose though; what do you 
> > want to do?
> > 
> [Joe] Right there is a difference between required to 
> implement and required to deploy.  In most cases the MUSTs, 
> SHOULDs, etc are required to implement.  A particular 
> deployment can often disable a particular feature if it does 
> not work in their environment. 
> 
> I think in this version of the text we have a MUST 
> requirement for certificate revocation checks which is 
> different than the SHOULD in RFC2716.  If the peer must be 
> able to perform certificate validation then it needs to have 
> a mechanism to do this.  Since OCSP in TLS (RFC
> 4366) is a SHOULD it may not be implemented in a server the 
> peer is talking to, in which case the peer must be able to 
> fall back to post connection checks.  It seems the first 
> SHOULD in the text refers to support in an implementation and 
> the second refers to deployment.  It seems inconsistent to 
> have a MUST for revocation and no mandatory way to do it, but 
> perhaps the MUST for CRL support covers it.  
> 
> [rmh] OK, I buy this. I am OK with changing the SHOULD to a MUST.
>  > 
> > > "
> > > 
> > > -Original Message-
> > > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, February 14, 2007 1:12 PM
> > > To: Bernard Aboba; emu@ietf.org
> > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> > > 
> > > 

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

> 
>If subject naming information is present only in the subject name
>field and the peer identity represents a user, then the 
> subject name
>field SHOULD contain an emailAddress RDN.  If the peer identity
>represents a host or device the subject name field SHOULD contain a
>CN RDN or Serial Number RDN.
> [rmh] If you say they can include a serialNumber (not Serial 
> Number) RDN then you have to specify processing symantics 
> when more than one are present, and discuss what sort of 
> value is used here, etc.
> [rmh] I suggest dropping the " or Serial Number RDN" portion 
> of this text, we can if appropriate work on a appendix or 
> other RFC that discusses these issues; I suspect the right 
> answer will be to reference the Permanent Identifier RFC from 
> the PKIX working group which already deals with these problems.
> 

[Joe] Would you not have to do the same with email address or CN?  It
seems it would be possible for multiple of these to be present.  There
should not be any semantics associated with a serial number other than
it is an identifier.  It should not be interpreted as a MAC address or
some other value without additional knowledge outside this
specification.  I agree that this would not be the place to consistently
find a MAC address. I would prefer to keep Serial Number as a
possibility as it is at least as relevant as the other fields.  I would
be fine with the previous text I posted with a MAY. 

>If subject naming information is present only in the subject name
>field of a server certificate, then the subject name field MUST
>contain a CN RDN or Serial Number RDN.
> [rmh] See my prior statements on serialNumber RDN.
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

This text looks fine to me. 

> -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 revocation checking after authentication, 
> since some servers might not implement OCSP, right? I don't 
> think we can add "MUST use" text for something that is a 
> "SHOULD implement".
> 
> In terms of usage, it is possible for the Peer-Id to 
> represent a machine name.  For example, with EAP-TLS the peer 
> could use a machine certificate for authentication. So I 
> think that the text on subjectAltName as well as the subject 
> name field needs to reflect this.
> 
> BTW, I'm not entirely clear that the NAI syntax is completely 
> compatible with that of an email address, although they are 
> pretty close.  For example, RFC 4282 defines 
> internationalization of the username field in the NAI, but 
> for email addresses we aren't there yet.  This has come up in 
> other contexts too (e.g. IKEv2 Identity Payload) where it 
> turned out not to be a big deal, but I thought it was worth 
> pointing out, just in case someone knows otherwise.
> 
> On the server side, I don't think that the Server-Id is 
> likely to be an NAI, although I'm not sure we can prohibit that.
> 
> Based on the comments and my own cleanup, here is where I 
> think we are at the moment.
> 
> Comments welcome.
> 
> =
> 5.2.  Peer and Server Identities
> 
>The EAP-TLS peer name (Peer-Id) represents the identity to be used
>for access control and accounting purposes.  The Server-Id 
> represents
>the identity of the EAP server.
> 
>In EAP-TLS, the Peer-Id and Server-Id are determined from 
> the subject
>or subjectAltName fields in the peer and server certificates.  As
>noted in [RFC3280] Section 4.1.2.6:
> 
>   The subject field identifies the entity associated with 
> the public
>   key stored in the subject public key field.  The 
> subject name MAY
>   be carried in the subject field and/or the subjectAltName
>   extension...  If subject naming information is present 
> only in the
>   subjectAltName extension (e.g., a key bound only to an email
>   address or URI), then the subject name MUST be an empty sequence
>   and the subjectAltName extension MUST be critical.
> 
>   Where it is non-empty, the subject field MUST contain an X.500
>   distinguished name (DN).
> 
>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 subjectAltName as per Section 5.3.  If subject naming 
> information
>is present only in the subjectAltName extension of a peer or server
>certificate, then the subject field MUST be an empty 
> sequence and the
>subjectAltName extension MUST be critical.  Although the 
> use of  the
>subject field is existing practice, its use in EAP-TLS is 
> deprecated
>and Certification Authorities are encouraged to use the
>subjectAltName field instead.
> 
>Where the peer identity represents a host, a subjectAltName of type
>dNSName SHOULD be present in the peer certificate.  Where the peer
>identity represents a user and not a resource, a subjectAltName of
>type rfc822Name SHOULD be used, conforming to the grammar for the
>Network Access Identifier (NAI) defined in [RFC4282] 
> Section 2.1.  If
>a dnsName or rfc822Name are not available other field types (for
>example a subjectAltName of type iPAdress or
>uniformResourceIdentifier) MAY be used.
> 
>A server identity will typically represent a host, not a user or a
>resource.  As a result, a subjectAltName of type dNSName SHOULD be
>present in the server certificate.  If a dnsName is not available
>other field types (for example a subjectAltName of type iPAdress or
>uniformResourceIdentifier) MAY be used.
> 
>If subject naming information is present only in the subject name
>field and the peer identity represents a user, then the 
> subject name
>field SHOULD contain an emailAddress RDN.  If the peer identity
>represents a host or device the subject name field SHOULD contain a
>CN RDN or Serial Number RDN.
> 
>If subject naming information is present only in the subject name
>field of a server certificate, then the subject name field MUST
>contain a CN RDN or Serial Number RDN.
> 
> 5.3.  Certificate Validation
> 
>Since the EAP-TLS server is typically connected to the Internet, it
>SHOULD support validating the  peer certificate using RFC 3280
>[RFC3280] conformant path validation, including the ability to
>retrieve intermediate certificates that may be necessary 
> to validate
>the peer certificate. For details, se

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

>If subject naming information is present only in the
subject name
>field and the peer identity represents a user, then the
> subject name
>field SHOULD contain an emailAddress RDN.  If the peer
identity
>represents a host or device the subject name field SHOULD
contain a
>CN RDN or Serial Number RDN.
> [rmh] If you say they can include a serialNumber (not Serial
> Number) RDN then you have to specify processing symantics
> when more than one are present, and discuss what sort of
> value is used here, etc.
> [rmh] I suggest dropping the " or Serial Number RDN" portion
> of this text, we can if appropriate work on a appendix or
> other RFC that discusses these issues; I suspect the right
> answer will be to reference the Permanent Identifier RFC from
> the PKIX working group which already deals with these
problems.
>

[Joe] Would you not have to do the same with email address or
CN?  It
seems it would be possible for multiple of these to be present.
There
should not be any semantics associated with a serial number
other than
it is an identifier.  It should not be interpreted as a MAC
address or
some other value without additional knowledge outside this
specification.  I agree that this would not be the place to
consistently
find a MAC address. I would prefer to keep Serial Number as a
possibility as it is at least as relevant as the other fields.
I would
be fine with the previous text I posted with a MAY.


[rmh] Although your right that the fact that multiple RDNs can
be used to make up a DN universally other RDNs are non-ambiguous while
serialNumber conceptually is not, 

[Joe] Can you expand upon this? Why is SerialNumber different
than other RDNs? 

[rmh] As for the value, EAP is not 802.11 only therefore a
device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used as a source address a attacker can presume if a EAP
authentication is succesfull the MAC used in the source address was
authenticated. I think there are other issues related to it being a MAC
address that should be thought through before it is added; especially if
its not even common practice today which it doesnt apear to be.

[Joe]  I think we are in agreement here.  

 
>If subject naming information is present only in the
subject name
>field of a server certificate, then the subject name field
MUST
>contain a CN RDN or Serial Number RDN.
> [rmh] See my prior statements on serialNumber RDN.
>
>


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 21, 2007 9:52 AM
> To: Joseph Salowey (jsalowey); [EMAIL PROTECTED]; emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> > [rmh] As for the value, EAP is not 802.11 only 
> therefore a device id 
> >should not be a MAC, also a MAC has locally administered and 
> globally 
> >adminstered versions, you would probably want to restrict the use to 
> >the globally issued ones, then there are the privacy issues 
> since the 
> >MAC is used as a source address a attacker can presume if a EAP 
> >authentication is successful the MAC used in the source address was 
> >authenticated. I think there are other issues related to it 
> being a MAC 
> >address that should be thought through before it is added; 
> especially 
> >if its not even common practice today which it doesnt apear to be.
> >
> > [Joe]  I think we are in agreement here.
> 
> Use of the MAC address as an EAP-TLS identity is not yet 
> common practice.   
> Yet both IEEE 802.1AR and WiMAX documents talk about use of 
> MAC addresses in certificates (using different formats), so 
> it could be used more widely in the future.
> 
[Joe] IEEE802.1AR is going down a different path then using MAC address
in certificates.  I don't know about WiMAX.  

> I agree that using a locally administered MAC address as an 
> identity in EAP-TLS does not make sense.
> 
> Do we have proposed text to deal with this issue?

[Joe] What is the issue?

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

In 802.11AR what comprises an identity is up to the manufacturer.  They
can put whatever they want in their as long as it is unique within their
namespace.  Right now it is unclear where the device identity will go.
Currently, if the identity is placed in the subject name  I don't think
it will use the email address RDN.  It is fairly common practice to use
CN and there is some existence of serialNumber since, as you pointed
out, CN may contain different less unique information.   I don't know of
any devices currently that place device identity in subjectAltName
fields. 
 
Off hand there may be some privacy concerns with using MAC address
(although this would probably be true of any "permanent" identifier).  I
don't think we want EAP-TLS to depend upon knowing about MAC addresses.
The security implications of MAC addresses will vary with deployment
scenarios.  I think these are largely out of scope for EAP-TLS.  
 
 Joe




From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 10:01 AM
    To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt


I beleive that 802.11AR still allows for the device ID to be a
MAC address, atleast the last version I read did although they have gone
from that being the ID to the ID being one that could be a MAC address.
 
I think the issue is the same one you have been calling out, if
I have a device where 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: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt





> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 21, 2007 9:52 AM
> To: Joseph Salowey (jsalowey); [EMAIL PROTECTED];
emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
>
> > [rmh] As for the value, EAP is not 802.11 only
> therefore a device id
> >should not be a MAC, also a MAC has locally administered and
> globally
> >adminstered versions, you would probably want to restrict the
use to
> >the globally issued ones, then there are the privacy issues
> since the
> >MAC is used as a source address a attacker can presume if a
EAP
> >authentication is successful the MAC used in the source
address was
> >authenticated. I think there are other issues related to it
> being a MAC
> >address that should be thought through before it is added;
> especially
> >if its not even common practice today which it doesnt apear
to be.
> >
> > [Joe]  I think we are in agreement here.
>
> Use of the MAC address as an EAP-TLS identity is not yet
> common practice.  
> Yet both IEEE 802.1AR and WiMAX documents talk about use of
> MAC addresses in certificates (using different formats), so
> it could be used more widely in the future.
>
[Joe] IEEE802.1AR is going down a different path then using MAC
address
in certificates.  I don't know about WiMAX. 

> I agree that using a locally administered MAC address as an
> identity in EAP-TLS does not make sense.
>
> Do we have proposed text to deal with this issue?

[Joe] What is the issue?


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

 




From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 9:15 AM
To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt


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 in
the subject name
>field and the peer identity represents a user, then
the
> subject name
>field SHOULD contain an emailAddress RDN.  If the
peer identity
>represents a host or device the subject name field
SHOULD contain a
>CN RDN or Serial Number RDN.
> [rmh] If you say they can include a serialNumber (not
Serial
> Number) RDN then you have to specify processing
symantics
> when more than one are present, and discuss what sort
of
> value is used here, etc.
> [rmh] I suggest dropping the " or Serial Number RDN"
portion
> of this text, we can if appropriate work on a appendix
or
> other RFC that discusses these issues; I suspect the
right
> answer will be to reference the Permanent Identifier
RFC from
> the PKIX working group which already deals with these
problems.
>

[Joe] Would you not have to do the same with email
address or CN?  It
seems it would be possible for multiple of these to be
present.  There
should not be any semantics associated with a serial
number other than
it is an identifier.  It should not be interpreted as a
MAC address or
some other value without additional knowledge outside
this
specification.  I agree that this would not be the place
to consistently
find a MAC address. I would prefer to keep Serial Number
as a
possibility as it is at least as relevant as the other
fields.  I would
be fine with the previous text I posted with a MAY.


[rmh] Although your right that the fact that multiple
RDNs can be used to make up a DN universally other RDNs are
non-ambiguous while serialNumber conceptually is not, 

[Joe] Can you expand upon this? Why is SerialNumber
different than other RDNs? 

[rmh] Conceptually a serial number is a exact match to a
entity, for example no two tivos share the same serial number but they
could all share the same common name of Tivo Series 2. 

[Joe] OK. 

[rmh] In my case case there is a actor who also shares
the name Ryan Hurst (http://www.imdb.com/name/nm0403652/) but we both
have unique ssns.

[Joe] OK 

 [rmh] Since its CN is not intended to be non-ambiguous
its reasonable for me to have multiple CNs in a certificate all of which
are appropriate as a common name of me; for example I could have one
that is just Ryan, another that is Ryan Hurst, another that is Ryan M
Hurst.

 [Joe] A device could be composed of multiple parts
(such as line cards) each with its own serial number.  There can also be
various formats and representations of a serial number.

 [rmh]  Since a serial number is a exact match, what
does it mean if you have multiple serial numbers? 

[Joe] I don't see any more confusion over having
multiple serial numbers than having multiples of any other attribute.  

[rmh] As for the value, EAP is not 802.11 only therefore
a device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used as a source address a attacker can presume if a EAP
authentication is succesfull the MAC used in the source address was
authenticated. I think there are other issues related to it being a MAC
address that should be thought through before it is added; especially if
its not even common practice today which it doesnt apear to be.

[Joe]  I think we are in agreement here.  


>If subject naming information is present only in
the subject name
>field of a server certificate, then the subject
name field MUST
>contain a CN RDN or Serial Number 

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joseph Salowey \(jsalowey\)]

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 21, 2007 9:43 PM
> To: emu@ietf.org
> Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> 
> [Joe] I don't see any more confusion over having multiple 
> serial numbers than having multiples of any other attribute.
> 
> Placing multiple identities into a peer certificate 
> represents an assertion that the identities are equivalent.  
> If they are not equivalent, then they should be placed into 
> separate certificates.  If the identities are equivalent, 
> then you could put "[EMAIL PROTECTED]"  and 
> "[EMAIL PROTECTED]" into a peer certificate,  and the server 
> would be free to pick one (e.g. the first one), and use that 
> to obtain the authorizations, assuming that the peer proved 
> possession of the private key.
> 
[Joe] I don't see why this doesn't hold for serial numbers as well.

> With a serial number or MAC address, I don't think this logic holds.  
> Multiple serial numbers or MAC addresses are not equivalent.  
> For example, the server might take the first MAC address as 
> the peer identity, but then it might expect this to match the 
> Called-Station-Id attribute, and it won't, because that MAC 
> address was the second one.  So the server may need to do 
> something different, like check all of the potential 
> identities.  That implies that identities really aren't 
> equivalent, and probably belong in separate certificates.
> 
[Joe] The same thing can happing with multiple CN or multiple email
addresses.  One of the values in the certificate may not match an
authorization entry while another one may.  Just to reiterate, I am not
suggesting that serial number have MAC address semantics.  

> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Agenda for EMU at IETF 68

[Joseph Salowey \(jsalowey\)]

Please let me know if you have any additions or corrections:

PRELIMINARIES (10 minutes)

Blue sheets
Minute takers
Agenda bash
Document Status

ITEMS IN EMU WG LAST CALL (40 minutes)

Topic: RFC2716bis - EAP-TLS
Presenter: TBD (Bernard Aboba)
Time: 20 minutes
URL:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt

Topic: EAP-GPSK
Presenter: TBD (Hannes Tschofenig, Charles Clancy)
Time: 20 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt

PASSWORD BASED METHOD (50 min)

Topic: Password Based Method Requirements
Presenter: TBD (password based design team)
Time: 20 minutes
URL: TBD(Summary mail to be sent to list)

Topic: Password based method approach discussion
Presenter: TBD (password based design team)
Time: 30
URL: TBD(Summary mail to be sent to list)

ADDITIONAL TOPICS (10 min)

Topic: An EAP Method for EAP Extension (EAP-EXT)
Presenter: Yoshihiro Obha 
Time: 10 Min
URL:
http://www.ietf.org/internet-drafts/draft-ohba-hokey-emu-eap-ext-00.txt

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 06, 2007 11:51 AM
> To: Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> Hi Bernard,
> Thanks much for the response. If we go down this path, are we 
> then saying that for every new ciphersuite that may be added 
> to TLS, a separate EAP method would need to be designed to 
> support that in EAP?
> Also, how is this different from TLS implementations having 
> to support the newer ciphersuites? 
> 

[Joe] We have a charter item for enhanced TLS which could support other
types of ciphersuites along with other features. 

> I can understand the mandatory cert requirement in RFC2716, 
> since at that point of time, TLS did not have the PSK 
> ciphersuites. But, now that we are revising it, does it not 
> make sense to support all the ciphersuites supported in TLS? 
> 
> Also, could you please elaborate on the multiple negotiation problem?
> Looking at the message flows in section 2.1 in
> draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in 
> draft-simon-emu-rfc2716bis-08, except for the certs portion, 
> everything else looks the same. 
> 

[Joe] EAP negotiation happens early before TLS negotiation.  If a peer
or server negotiate a particular EAP method they may actually not
actually be able to complete this because TLS negotiation arrives upon
an result that is not satisfactory. Restricting EAP-TLS to certificate
based ciphers does not solve this problem, but it helps. In an enhanced
EAP-TLS the initial message from the server could indicate the supported
ciphers giving the chance for a client to NAK. 


> Thanks,
> Vidya
> 
> > -Original Message-
> > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 05, 2007 11:29 PM
> > To: Narayanan, Vidya; emu@ietf.org
> > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> > 
> > According to RFC 2716, a compliant EAP-TLS implementation 
> must support 
> > certificates.  Since the resources required to support 
> certificates is 
> > much larger than the resources required for TLS-PSK, a 
> combined method 
> > would not be optimal for use within an embedded environment.  There 
> > would also be substantial costs to adding support for additional 
> > authentication methods to EAP-TLS.  For example, EAP-TLS 
> certification 
> > and testing programs have been developed which focus solely on 
> > certificate ciphersuites; rewriting those test suites would 
> be costly.
> > 
> > By developing EAP-TLS-PSK as a separate EAP method an 
> implementation 
> > can solely implement TLS-PSK while remaining compliant.  
> This permits 
> > EAP TLS-PSK implementations to be optimized for embedded 
> environments.  
> > As a side benefit, this approach also eliminates multiple levels of 
> > negotiation, which had been raised as a potential problem.
> > 
> > 
> > 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 07, 2007 8:12 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: emu@ietf.org
> Subject: Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> Hannes Tschofenig said:
> 
> >We discussed this already several times and this lead me to 
> work on a 
> >draft together with Thomas Otto:
> >
> >http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt
> 
> Which begs the question:  what is the WG doing with this draft?
> 

[Joe] The draft is not currently a working group item.  The pre-shared
key mechanism charter item is covered by EAP-GPSK.  There is a charter
item for enhanced EAP-TLS which could support TLS-PSK and other
enhancements.  

> >From where I sit, it seems quite likely that EAP-TLS-PSK, if 
> completed, 
> >will
> be deployed.  When TLS 1.2 is done, this method could 
> eventually benefit from KDF negotiation, and should meet the 
> criteria for FIPS 140-2 certification.  Given the TLS code 
> base in embedded systems, it should not be hard to add 
> support for EAP-TLS-PSK within embedded devices.
> 
[Joe] The KDF needs to be looked at, but I do not think it is
necessarily a show stopper, it does provide KDF agility.  Reports from
people who implemented EAP-GPSK indicate that it was simple to
implement. I have heard push back from embedded system implementers on
EAP-TLS stating that it is too complex, this may be a result of
certificate support I am not sure. 

> I my doubts about EAP-GPSK on several of these dimensions.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 07, 2007 1:28 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> Hi Joe, 
> 
> Let me separate this into different topics for clarity.  
> 
> > 
> > [Joe] EAP negotiation happens early before TLS negotiation. 
>  If a peer
> 
> > or server negotiate a particular EAP method they may actually not 
> > actually be able to complete this because TLS negotiation 
> arrives upon
> 
> > an result that is not satisfactory. Restricting EAP-TLS to 
> certificate
> 
> > based ciphers does not solve this problem, but it helps. In an 
> > enhanced EAP-TLS the initial message from the server could indicate 
> > the supported ciphers giving the chance for a client to NAK.
> > 
> > 
> 
> 1. TLS negotiations in EAP: 
> ---
> I guess in a way, this is trying to perform some rudimentary 
> TLS ciphersuite negotiation at the EAP level. For regular TLS 
> operation, I can see clients connecting to just about any 
> server. However, for EAP, typically, the peer has an 
> "association" with a certain server that at least knows a 
> list of methods that the peer or peers that have an 
> association with it support - that's how it knows what method 
> to start in the EAP Request following the EAP Response 
> Identity. EAP doesn't quite provide method negotiation per se 
> - by using EAP NAKs, we can make it soemthing of a 
> negotiation. If the EAP server has no clue about the peer 
> attempting to authenticate or if the server does not have a 
> reasonable number of methods that it supports, the EAP 
> exchange could potentially go on with several NAKs and that 
> wouldn't be good. 

[Joe] EAP provides negotiation and it is even used in real networks.  I
agree it is not ideal, but it is what we have. 

>By that same principle, it seems like 
> whatever would indicate to the server that the client can do 
> EAP-TLS-PSK (when that is a separate method) should also 
> indicate that the client can do EAP-TLS with PSK ciphersuites. 
> 

[Joe] I'm not sure what principle you are referring to so I don't see
how it can be applied to this problem.  The client tells the server it
supports method x by responding to the server's challenge for method x.
The ciphersuite is not available in the initial challenge. One could
modify EAP-TLS such ciphersuites are advertised in the EAP-TLS start,
but this would interfere with backwards capability, hence there is a
charter item for enhanced TLS. 

> 2. TLS vs. EAP-TLS Implementations:
> 
> I'm a bit concerned about supporting a subset of TLS in 
> EAP-TLS. For instance, consider a server that has a regular 
> TLS implementation and typically supports the PSK 
> ciphersuites. For a client that talks TLS directly to it, it 
> allows negotiation of any ciphersuites, including the PSK 
> ones. However, for a client that talks TLS via EAP, it needs 
> to make sure that only a subset of the TLS ciphersuites are 
> provided as an option. So, in this case, EAP is not just a 
> carrier for the TLS authentication method - EAP then only 
> supports one "profile" of TLS, so to say. 
> 
[Joe] Most TLS libraries support "profiling" of TLS ciphersuites for
different applications and deployments.  

> If we think that optimizations can be supported by having a 
> separate EAP-TLS-PSK method, we may still want to do that, 
> but, precluding the use of certain TLS ciphersuites with 
> EAP-TLS seems restrictive. 
> 
[Joe] It is not necessary to put restrictions on an enhanced EAP-TLS
since it does not have the same backwards compatible expectations as
EAP-TLS.  

> 3. Client authentication in EAP-TLS:
> 
> I also notice that client authentication is optional as 
> written in draft-simon-emu-rfc2716bis. When would peer 
> authentication ever be optional for EAP operation? 
>I realize 
> this is something that came from TLS, since client 
> authentication is truly optional in TLS (and that makes sense 
> in certain uses of TLS). However, in the context of EAP, that 
> seems strange. If we were to follow the same notions about 
> optional TLS elements as in RFC4346 (or 4346bis), the server 
> certificate would also then be optional. 
> 

[Joe] There are EAP  use cases where peer authentication is not required
but server authentication is.  There are also instances where anonymous
ciphersuites are used, but the trade off in security is much more severe
with anonymous ciphersuites. 

> Vidya
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 07, 2007 9:00 PM
> To: Joseph Salowey (jsalowey); [EMAIL PROTECTED]; 
> [EMAIL PROTECTED]
> Cc: emu@ietf.org
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> >[Joe] The KDF needs to be looked at, but I do not think it is 
> >necessarily a show stopper, it does provide KDF agility.  
> Reports from 
> >people who implemented EAP-GPSK indicate that it was simple to 
> >implement. I have heard push back from embedded system 
> implementers on 
> >EAP-TLS stating that it is too complex, this may be a result of 
> >certificate support I am not sure.
> 
> In my experience, adding certificate support dramatically 
> increases footprint.  For example, as I recall IKEv1/IPsec 
> with AES CBC/HMAC-SHA1 is around 250 KB or so if we're just 
> talking about pre-shared key authentication but if you add 
> certificate support that is another 750 KB, which will be too 
> big for some applications.
> 
> I would think that the same logic applies to EAP-TLS-PSK.  Of 
> course that would require a stripped down implemenation of 
> TLS that only supported TLS-PSK, no certificates.  I guess 
> that doesn't exist yet?  If you had to pull in all of say, 
> Open SSL plus add TLS-PSK support, that would almost 
> certainly make it too large for many embedded applications.
> 
[Joe] Yes OpenSSL is a commonly used toolkit, however I don't think one
of its design goals is a small footprint. 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Re: On my suggestion to use CTR mode instead of CBC

[Joseph Salowey \(jsalowey\)]

We discussed using CBC mode because it was slightly simpler than CTR
mode.  What is the significant advantage you see with CTR mode?  

Joe

> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 12, 2007 6:21 AM
> To: Lakshminath Dondeti
> Cc: emu@ietf.org
> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC
> 
>  > CTR mode encryption does not include integrity protection. 
>  There are  > what are known as combined modes, e.g., CCM, 
> OCB, GCM, which use CTR  > mode for encryption.  I am not 
> talking about using CCM or something like  > that.
> 
> I have no objection to switching from CBC to CTR.  Anyone 
> else have an opinion?
> 
> --
> t. charles clancy, ph.d.  |  [EMAIL PROTECTED]  |  www.cs.umd.edu/~clancy
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Re: On my suggestion to use CTR mode instead of CBC

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 12, 2007 10:58 AM
> To: Joseph Salowey (jsalowey)
> Cc: Charles Clancy; emu@ietf.org
> Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC
> 
> Joseph Salowey (jsalowey) wrote:
> > We discussed using CBC mode because it was slightly simpler 
> than CTR 
> > mode.  What is the significant advantage you see with CTR mode?
> 
> CTR mode as the encryption algorithm and AES_CMAC_128 as the 
> integrity algorithm requires the implementation of the 
> forward operation of the cipher only.
> 
[Joe] Would this make the implementation more compact?  

> I missed the part about CBC being simpler (btw, I have 
> nothing against CBC :) ).  Could you refresh my memory?  Thanks.
> 
[Joe] Most implementers are fairly familiar with CBC and its use, many
libraries are available for it.  CTR is a less familiar, which can
result in difficulties in counter management.  

> regards,
> Lakshminath
> 
> > 
> > Joe
> > 
> >> -Original Message-
> >> From: Charles Clancy [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, March 12, 2007 6:21 AM
> >> To: Lakshminath Dondeti
> >> Cc: emu@ietf.org
> >> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC
> >>
> >>  > CTR mode encryption does not include integrity protection. 
> >>  There are  > what are known as combined modes, e.g., CCM, 
> OCB, GCM, 
> >> which use CTR  > mode for encryption.  I am not talking 
> about using 
> >> CCM or something like  > that.
> >>
> >> I have no objection to switching from CBC to CTR.  Anyone 
> else have 
> >> an opinion?
> >>
> >> --
> >> t. charles clancy, ph.d.  |  [EMAIL PROTECTED]  |  www.cs.umd.edu/~clancy
> >>
> >> ___
> >> Emu mailing list
> >> Emu@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/emu
> >>
> > 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Presentations for EMU

[Joseph Salowey \(jsalowey\)]

Please send me presentations for EMU agenda items this morning. 

Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Thoughts on Password-based EAP Methods

[Joseph Salowey \(jsalowey\)]

I'm not sure that adding yet another version to TTLS specifically for
supporting passwords will make things better for customers.  Multiple
versions certainly has caused quite a confusion in PEAP.

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 27, 2007 8:07 AM
> To: emu@ietf.org
> Subject: [Emu] Thoughts on Password-based EAP Methods
> 
> After listening to the IETF 68 presentation on a 
> password-based EAP method, I would like to voice some concerns.
> 
> Today we already have an "over abundance" of such methods.  
> These include 
> PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST.   In my 
> discussions 
> with customers, I invariably hear complaints about this 
> explosion, and about various interoperability and 
> compatibility problems that it causes.  Simply put, customers 
> do not want "yet another password-based EAP method";  they 
> want a single method that is widely implemented and interoperable.
> 
> I am concerned that by defining yet another password-based 
> authentication 
> mechanism, EMU WG will be making this problem worse, not 
> better.   Creating 
> yet another mechanism which differs little from the existing 
> ones also seems to have very little chance of being implemented.
> 
> There is a better alternative that EMU WG should consider. 
> This is to choose an existing method for inclusion on the 
> IETF Standards Track, rather than creating a new one.  In 
> order to maintain backward compatibility, this would require 
> that the owners give up change control to the IETF.
> 
> I would suggest that the best candidate for this would be 
> EAP-TTLSv0, since it is very widely implemented, and has an 
> existing certification program in 
> WFA.   Also, EAP-TTLSv0 had previously been on the Standards 
> Track in the 
> PPPEXT WG, before work on EAP methods was removed from the 
> PPPEXT WG charter and the EAP WG was formed.
> 
> In terms of steps to be taken, this would require the 
> following actions:
> 
> a. Review and publication of the existing EAP-TTLSv0 
> specification as an RFC.  The goal here would be to document 
> EAP-TTLSv0 as it exists today.
> 
> b. Agreement by the authors to give up change control to the IETF.
> 
> c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, 
> specifying additional capabilities (such as Channel Bindings).
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Thoughts on Password-based EAP Methods

[Joseph Salowey \(jsalowey\)]

Some of the things that need to be fixed are fairly fundamental. For
example crypto-binding and avoiding multiple layers of negotiation are
fairly fundamental.  At this point I'm not sure that modifying TLVs is
the best way to achieve this.  It needs to be investigated.  

Joe

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 02, 2007 3:46 PM
> To: emu@ietf.org
> Subject: RE: [Emu] Thoughts on Password-based EAP Methods
> 
> >I'm not sure that adding yet another version to TTLS 
> specifically for 
> >supporting passwords will make things better for customers.  
> Multiple 
> >versions certainly has caused quite a confusion in PEAP.
> 
> I would agree that "versioning" is not a good idea.  However, 
> as I understand it, EAP-TTLSv0 is the only deployed version 
> of TTLS; v1 has never 
> been implemented.   So currently there is no versioning issue 
> with TTLS, and 
> if possible, it would be best if the IETF would not create 
> such a problem.
> 
> It is not clear to me that EAP-TTLS needs "versioning" in 
> order to enable addition of new features in a backwards 
> compatible way, since it already supports a TLV-based 
> extension mechanism.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Password based method

[Joseph Salowey \(jsalowey\)]

I would recommend that the design team put together a draft that can be
evaluated against other options if they are generated.  The draft should
strive to meet the requirements and be simple. I think we already have a
good start.

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Draft Meeting Minutes from IETF-68

[Joseph Salowey \(jsalowey\)]

Below are draft meeting minutes from IETF-68.  Please let me know if you
have any additions or corrections.  


--
EAP Method Update (EMU) Minutes 
IETF-68 
Prague, Czech Republic
March 19, 2007 

Chair: Joseph Salowey
Note Taker: Nancy Cam-Winget


Agenda

1. rfc2716-bis
2. EAP-GPSK
3. Password-based method
4. Additional Item - EAP extensions


RFC 2716bis - Bernard Aboba

- Discussion of changes in version 08
- Open Issues mostly around certificate usage

+ Discussion on multiple names in certificate

Joe Salowey: what if there is more than one subjectAltName?
Tim Polk: states that we need to define the same context and rules.
Stefan Santesson: having more names in a cert is not a problem so long
as matching the  name requirement is okay in general.
Tim: retorts that it can get tricky as it depends on where the name
"sought" is  in the appropriate place.
Sam Hartman: trying to authorize access; all names provided in a cert
should be valid,  so if any of those names match an authorizable name,
then access should be  granted.  
Tim: questions whether there would be an issue if there's a
distinguished name  versus an RFC2716 name...
Sam and Tim: agree that as long as there is a searchable name, it should
be  "good enough".
Bernard Aboba: comments AAA server should try to see for the name to
match in any and  all the fields.
Hannes Tschofenig: comments it may just be an implementation issue by
the EAP server.   Doesn't believe the checks need to be constrained and
precise as it would  require full description of what is to be matched;
in this case it shouldn't  matter.

+ Discussion on where to put MAC address in certificate raised by Ryan
Hurst on  list

Bernard: comments that it arose from cert applicability of whether the
MAC  address is in the subjectAltName and whether they should be colon
delimited or  not.
Stefan: comments on 3 alternatives: (1) distinguished name; (2)
permanent  serial number and (3) creating a new "other" field.  Concern
of use of (2) and  (3); suggests the use of an OID as part of the TLS
exchange.

+ Some consensus that the previous comment should not be part of this
spec.
Tim: agrees its out of scope for this group.  All names should be
equally valid  for the subject; they are for specific contexts.

+ back to multiple names in certificate 

Joe: comments that subjectName may have multiple components.
Sam: mentions that all parts in the subjectName needs to be valid.
Tim: notes that especially for distinguished name, one should not
extract a  portion it should be used as a whole.
Sam: mentions RFC 2818 describes exactly what Tim said not to do. 
Bernard: summarizes it may not take long to resolve.
Paul Hoffman: comments on how prior descriptions still may not give us
interoperability.  Servers tend to be lazy as they will scan for first
match  and then fail (too easily).
Bernard: concurs and notes that we'd need to add more text.
Gregory Liebowitz: mentions that there should be a clear indication of
what name should  be sought.
Hannes: mentions that IPSec has experience on this, 802.16 also has this
application.  We should find out where the MAC address validation
occurs, if it  is terminated by the EAP server, AAA server or otherwise.
Vidya Narayanan: comments TLS cipher suites not supported by the draft,
questions which  ones are.
Several respond that there are quite a few that are documented as SHOULD
and  SHALLs to enumerate the supported ones.
Bernard: mentions behavior of 2716 requires that request for cert is
still be  made.
Sam: mentions that this is last call issues and to be cognizant of this
state  so that we do not open up more new issues.
Bernard: states that we should look at text and see if there's anything
wrong.   If there's nothing broken, then we can open it to a wider group
to get more  eyes that have deeper certificate expertise to help review.


EAP-GPSK - Hannes Tschofenig


Current status and mention of reviewers.
- discussion of cipher suites and KDFs
- 2 current cipher suites:  AES-CBC-128, NULL
- suggested change #1 CBC to CTR in ciphersuite #1
- suggested change #2 KDF use MAC-based vs. hash based KDF.  The
commenter mentions that the change is not aligned with
http://tools.ietf.org/html/draft-dang-nistkdf-01

+ KDF discussion

Tim (with NIST "hat"): tries to clarify without having looked at this
document.   NIST has a standard for keys derived from key establishment
(DH, MQV)...they way  NIST works, it looks at a standard to use one of
the approved methods.  There's  nothing against using MAC's  in KDFs by
NIST, previous guidance may have been  misled on the belief that key
esta

FW: [Emu] Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings

[Joseph Salowey \(jsalowey\)]

Message accidentally discarded by the moderator.  

> -Original Message-
> From: Nicolas Williams [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 12, 2007 8:10 AM
> To: Lakshminath Dondeti
> Cc: [EMAIL PROTECTED]; Sam Hartman; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Emu] Last call 
> comments:draft-williams-on-channel-binding-01.txt: EAP 
> channel bindings
> 
> On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote:
> > After having reviewed 
> "draft-williams-on-channel-binding-01," I feel 
> > that putting EAP in scope of that document would require a rather 
> > involved revision of the document.  As Charles noted it 
> might require 
> > further abstraction of the concept of channel binding as defined in 
> > draft-williams.
> > 
> > Now, I must say, I do see the similarities between the two 
> notions of 
> > channel binding.  But the EAP/AAA model is unique and it is 
> not easy 
> > to map it to the other, let's say simpler, security models.  The 
> > notion of compound binding or crypto binding also has some 
> > similarities to the notion of channel binding in 
> > draft-williams-on-channel-binding-01, but there are also 
> some differences.
> > 
> > Overall though, since expanding 
> draft-williams-on-channel-binding-01's
> > scope to EAP means that the requirements, recommendations and 
> > suggestions of Section 2.1 may be applied to EAP channel 
> binding, it 
> > would be a rather painful exercise to sort it all out.  For 
> now, I am 
> > comfortable with the guidance in Section 7.15 of 3748.
> 
> My impression was that Sam's suggested text was introductory 
> and informative, and not at all intended to cause this doc to 
> normatively constrain EAP.
> 
> I think that having a single abstraction that can describe 
> what went by multiple names in different areas can be very 
> useful because it facilitates cross-area communication.  And 
> missing an opportunity to point out how two things are more 
> similar than they look would help perpetuate a perception 
> that those two things are more different than they actually are.
> 
> Nico
> -- 
> 
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Emu mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/emu

[Emu] RFC 2716bis Section 5.2. Peer and Server Identities

[Joseph Salowey \(jsalowey\)]

At the meeting in Prague we had some discussion on the contents of
section 5.2 of RFC2716bis.  Section 5.2 of
draft-simon-emu-rfc2716bis-08.txt looks to be acceptable according to
the discussion.   Do people approve of or object to the text in section
5.2?




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Some comments on EAP-GPSK

[Joseph Salowey \(jsalowey\)]

I think the document is in good shape, but I have a few minor comments:

1.  The document defines vendor OID. What is this intended to be, is the
SMI OID?  I think the document needs to specify what the registry is.  

2.  There is no IANA registry created for OP-CODES

3.  Are both the PSK not found and authentication error codes necessary.
It appears that the "PSK not found" error is equivalent to "bad
username".  Perhaps this is not as much of an issue with a PSK as with a
password, but it may allow an attacker to probe for valid "accounts". 

4. It seems that there should be a reference to AES. 

5. It seems that the server-ID is a user-visible field and should be
encoded in UTF-8. 


Thanks,

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC 2716bis Issue: Use of rfc822Name

[Joseph Salowey \(jsalowey\)]

RFC4383 is a superset of RFC822.  If a name does not conform to RFC822
then it will not be compliant with RFC3280.  Within a specific community
where everyone has a common understanding of how the extension will be
used then this is probably OK.  If you plan on using the certificates
more generically then it is possible that you will run into problems.  

Joe

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 01, 2007 2:41 PM
> To: emu@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: [Emu] RFC 2716bis Issue: Use of rfc822Name
> 
> The following question has come up in the WiMAX Forum with 
> respect to EAP-TLS peer certificate usage:
> 
> >From RFC 3280:
>When the subjectAltName extension contains an Internet 
> mail address,
>the address MUST be included as an rfc822Name.  The format of an
>rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].  An
>addr-spec has the form "[EMAIL PROTECTED]".  Note that an addr-spec
>has no phrase (such as a common name) before it, has no 
> comment (text
>surrounded in parentheses) after it, and is not surrounded 
> by "<" and
>">".  Note that while upper and lower case letters are 
> allowed in an
>RFC 822 addr-spec, no significance is attached to the case.
> 
> The question is whether any NAI as defined in RFC 4282 meets 
> these requirements for inclusion in subjectAltName using the 
> rfc822Name format.
> 
> For example, what if an NAI does not contain a realm portion?
> 
> My personal take is that as long as the NAI is legal within 
> RFC 4282, it should be legal for inclusion in the 
> subjectAltName field using the rfc822Name format.  This seems 
> preferrable to registering a new type-id.
> 
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Multiple identity issue

[Joseph Salowey \(jsalowey\)]

looks good, except I think that there can be only one Subject Name field
in a valid certificate.  How about something like: 

"It is possible for more than one subjectAltName field to be present
in a peer or server certificate;  similarly, it is possible for a
non-empty subject name field to also be present in a peer or server
certificate.  In this case, EAP-TLS may export more than one Peer-Id
or more than one Server-Id; all of the exported Peer-Id(s) and
Server-Id(s) are considered 
valid. "
 



From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 08, 2007 2:54 PM
To: emu@ietf.org
Subject: [Emu] Multiple identity issue


At  the EMU WG meeting, we discussed the situation where more
than one altsubjectName or subject field are present in a certificate.
Here is some text which can be added to the end of Section 5.2 to
address this issue:
 
"It is possible for more than one subjectAltName field to be
present
in a peer or server certificate;  similarly, it is possible for
more
than one subject name field to be present in a peer or server
certificate.  In this case, EAP-TLS may export more than one
Peer-Id
or more than one Server-Id; all of the exported Peer-Id(s) and
Server-Id(s) are considered 
valid. "


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC 2818 reference

[Joseph Salowey \(jsalowey\)]

So would the section be revised to clarify when 2818 would be
applicable, such as when the hostname and DNS are known ahead of time?




From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 08, 2007 3:10 PM
To: emu@ietf.org
Subject: [Emu] RFC 2818 reference



A question has arisen about the reference to RFC 2818 section
3.1 within Section 5.3:
 
   When performing this comparison implementations MUST follow
the
   validation rules specified in [RFC2818] Section 3.1.  In the
case of
   the server this involves ensuring the certificate presented
by the
   EAP-TLS peer was intended to be used as a client certificate.
   Implementations SHOULD use the Extended Key Usage (see
[RFC3280]
   Section 4.2.1.13) extension and ensure that at least one of
the
   following is true:

   1) The certificate issuer included no Extended Key Usage
  identifiers in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in
  the certificate (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-clientAuth identifier in
  the certificate (see [RFC3280] section 4.2.1.13). 
 
Here is the text from that reference:
 
3.1.  Server Identity

   In general, HTTP/TLS requests are generated by dereferencing
a URI.
   As a consequence, the hostname for the server is known to the
client.
   If the hostname is available, the client MUST check it
against the
   server's identity as presented in the server's Certificate
message,
   in order to prevent man-in-the-middle attacks.

   If the client has external information as to the expected
identity of
   the server, the hostname check MAY be omitted. (For instance,
a
   client may be connecting to a machine whose address and
hostname are
   dynamic but the client knows the certificate that the server
will
   present.) In such cases, it is important to narrow the scope
of
   acceptable certificates as much as possible in order to
prevent man
   in the middle attacks.  In special cases, it may be
appropriate for
   the client to simply ignore the server's identity, but it
must be
   understood that this leaves the connection open to active
attack.

   If a subjectAltName extension of type dNSName is present,
that MUST
   be used as the identity. Otherwise, the (most specific)
Common Name
   field in the Subject field of the certificate MUST be used.
Although
   the use of the Common Name is existing practice, it is
deprecated and
   Certification Authorities are encouraged to use the dNSName
instead.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is
present in
   the certificate (e.g., more than one dNSName name, a match in
any one
   of the set is considered acceptable.) Names may contain the
wildcard
   character * which is considered to match any single domain
name
   component or component fragment. E.g., *.a.com matches
foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

   In some cases, the URI is specified as an IP address rather
than a
   hostname. In this case, the iPAddress subjectAltName must be
present
   in the certificate and must exactly match the IP in the URI.

   If the hostname does not match the identity in the
certificate, user
   oriented clients MUST either notify the user (clients MAY
give the
   user the opportunity to continue with the connection in any
case) or
   terminate the connection with a bad certificate error.
Automated
   clients MUST log the error to an appropriate audit log (if
available)
   and SHOULD terminate the connection (with a bad certificate
error).
   Automated clients MAY provide a configuration setting that
disables
   this check, but MUST provide a setting which enables it.

   Note that in many cases the URI itself comes from an
untrusted
   source. The above-described check provides no protection
against
   attacks where this source is compromised. For example, if the
URI was
   obtained by clicking on an HTML page which was itself
obtained
   without using HTTP/TLS, a man in the middle could have
replaced the
   URI.  In order to prevent this form of attack, users should
carefully
   examine the certificate presented by the server to determine
if it
   meets their expectations.
 
Overall, this reference does seem to have s

RE: [Emu] Multiple identity issue

[Joseph Salowey \(jsalowey\)]

I think it would be more consistent with RFC 3280 if we report a
non-empty  subject name as well as the subjectAltNames since they all
are valid identities within the certificate.  

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 08, 2007 3:55 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Multiple identity issue
> 
> The 3rd paragraph of Section 5.2 says:
>  
>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 subjectAltName.  If subject naming information is 
> present only in
>the subjectAltName extension of a peer or server certificate, then
>the subject field MUST be an empty sequence and the subjectAltName
>extension MUST be critical.  
>  
> Therefore it would seem that presence of both a single 
> subject and single subjectAltName would not result in export 
> of multiple Peer-Id(s) or Server-Id(s).  This can only happen 
> if there are multiple subjectAltName fields. 
>  
> So how about: 
>  
> "It is possible for more than one subjectAltName field to be 
> present in a peer or server certificate; similarly, it is 
> possible for a non-empty subject name field to also be 
> present in a peer or server certificate.  Where more than one 
> subjectAltName field is present in a certificate, EAP-TLS may 
> export more than one Peer-Id or more than one Server-Id; all 
> of the exported Peer-Id(s) and Server-Id(s) are considered valid. "
>  
> 
> Joe Salowey said: 
> 
> > looks good, except I think that there can be only one Subject Name 
> > field in a valid certificate. How about something like:
> > 
> > "It is possible for more than one subjectAltName field to 
> be present 
> > in a peer or server certificate; similarly, it is possible for a 
> > non-empty subject name field to also be present in a peer or server 
> > certificate. In this case, EAP-TLS may export more than one 
> Peer-Id or 
> > more than one Server-Id; all of the exported Peer-Id(s) and
> > Server-Id(s) are considered
> > valid. "
> > 
> > 
> > 
> > 
> > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 08, 2007 2:54 PM
> > To: emu@ietf.org
> > Subject: [Emu] Multiple identity issue
> > 
> > 
> > At the EMU WG meeting, we discussed the situation where 
> more than one 
> > altsubjectName or subject field are present in a certificate.
> > Here is some text which can be added to the end of Section 5.2 to 
> > address this issue:
> > 
> > "It is possible for more than one subjectAltName field to 
> be present 
> > in a peer or server certificate; similarly, it is possible for more 
> > than one subject name field to be present in a peer or server 
> > certificate. In this case, EAP-TLS may export more than one 
> Peer-Id or 
> > more than one Server-Id; all of the exported Peer-Id(s) and
> > Server-Id(s) are considered
> > valid. "
> > 
> > 
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Multiple identity issue

[Joseph Salowey \(jsalowey\)]

Yes, probably, but for EAP-TLS what we are talking about are names for
the same entity which are the peer or the server.  

I think new definitions are needed for these other concepts, which are
not currently part of EAP-TLS. 

Joe

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 09, 2007 9:11 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Multiple identity issue
> 
> I think we may need a way to distinguish multiple names for 
> the same entity (e.g. mutiple subjectAltName/subject fields 
> in a single certificate) from multiple names that may not 
> refer to the same entity (e.g. Server-Id(s) provided within a 
> tunnel method whose Phase 1 and Phase 2 terminate on 
> different entities).  Also, there is a need to distinguish 
> the identities that define the key scope (e.g. Phase 1 
> identities from EAP-TTLSv0) from those that did not 
> contribute to key generation (e.g. Phase 2 identities from 
> EAP-TTLSv0). 
> 
> Joe Salowey said: 
> 
> > I think it would be more consistent with RFC 3280 if we report a 
> > non-empty subject name as well as the subjectAltNames since 
> they all 
> > are valid identities within the certificate.
> > 
> > > -Original Message-
> > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, May 08, 2007 3:55 PM
> > > To: Joseph Salowey (jsalowey); emu@ietf.org
> > > Subject: RE: [Emu] Multiple identity issue
> > > 
> > > The 3rd paragraph of Section 5.2 says:
> > > 
> > > 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 subjectAltName. If subject naming information is 
> present only in 
> > > the subjectAltName extension of a peer or server 
> certificate, then 
> > > the subject field MUST be an empty sequence and the 
> subjectAltName 
> > > extension MUST be critical.
> > > 
> > > Therefore it would seem that presence of both a single 
> subject and 
> > > single subjectAltName would not result in export of multiple 
> > > Peer-Id(s) or Server-Id(s). This can only happen if there are 
> > > multiple subjectAltName fields.
> > > 
> > > So how about: 
> > > 
> > > "It is possible for more than one subjectAltName field to 
> be present 
> > > in a peer or server certificate; similarly, it is possible for a 
> > > non-empty subject name field to also be present in a peer 
> or server 
> > > certificate. Where more than one subjectAltName field is 
> present in 
> > > a certificate, EAP-TLS may export more than one Peer-Id 
> or more than 
> > > one Server-Id; all of the exported Peer-Id(s) and 
> Server-Id(s) are 
> > > considered valid. "
> > > 
> > > 
> > > Joe Salowey said: 
> > > 
> > > > looks good, except I think that there can be only one 
> Subject Name 
> > > > field in a valid certificate. How about something like:
> > > > 
> > > > "It is possible for more than one subjectAltName field to
> > > be present
> > > > in a peer or server certificate; similarly, it is 
> possible for a 
> > > > non-empty subject name field to also be present in a peer or 
> > > > server certificate. In this case, EAP-TLS may export 
> more than one
> > > Peer-Id or
> > > > more than one Server-Id; all of the exported Peer-Id(s) and
> > > > Server-Id(s) are considered
> > > > valid. "
> > > > 
> > > > 
> > > > 
> > > > 
> > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, May 08, 2007 2:54 PM
> > > > To: emu@ietf.org
> > > > Subject: [Emu] Multiple identity issue
> > > > 
> > > > 
> > > > At the EMU WG meeting, we discussed the situation where
> > > more than one
> > > > altsubjectName or subject field are present in a certificate.
> > > > Here is some text which can be added to the end of 
> Section 5.2 to 
> > > > address this issue:
> > > > 
> > > > "It is possible for more than one subjectAltName field to
> > > be present
> > > > in a peer or server certificate; similarly, it is possible for 
> > > > more than one subject name field to be present in a 
> peer or server 
> > > > certificate. In this case, EAP-TLS may export more than one
> > > Peer-Id or
> > > > more than one Server-Id; all of the exported Peer-Id(s) and
> > > > Server-Id(s) are considered
> > > > valid. "
> > > > 
> > > > 
> > > > ___
> > > > Emu mailing list
> > > > Emu@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/emu
> > > 
> > > 
> > > 
> 
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Liaison statement from IEEE 802.11u on "EAP emergency method"

[Joseph Salowey \(jsalowey\)]

The liaison statement from the IEEE 802.11u on "EAP emergency Method" is
now available at https://datatracker.ietf.org/public/liaisons.cgi.  

One of the documents on requirements appears to be missing on the
liaison page (the requirements presentation).  I will work on getting
this updated. 

Joe

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis

[Joseph Salowey \(jsalowey\)]

Looks fine to me. Any particular reason why we emphasize 4.2.2.1?

Thanks,

Joe

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 05, 2007 9:45 PM
> To: Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] Issue: Validation of server certificates 
> in Section 5.3 ofRFC 2716bis
> 
> 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 at Section 5.3 in RFC 2716bis, and I noticed 
> that while RFC 3280 conformant path validation is recommended 
> for EAP-TLS servers, there is no such recommendation for 
> EAP-TLS peers.  This seems odd. 
> 
> For example, Section 5.3 states:
> 
>Since the EAP-TLS server is typically connected to the Internet, it
>SHOULD support validating the peer certificate using RFC 3280
>[RFC3280] conformant path validation, including the ability to
>retrieve intermediate certificates that may be necessary 
> to validate
>the peer certificate. For details, see [RFC3280] Section 4.2.2.1.
> 
> There is no equivalent statement for EAP-TLS peers. 
> 
> I would propose the insert the following sentence in Section 5.3:
> 
>The EAP-TLS peer SHOULD support validating
>the server certificate using RFC 3280 [RFC3280] conformant path
>validation.
> 
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Validation of server certificates in Section 5.3 ofRFC 2716bis

[Joseph Salowey \(jsalowey\)]

Excellent! 

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 06, 2007 12:32 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] Issue: Validation of server certificates 
> in Section 5.3 ofRFC 2716bis
> 
> The 4.2.2.1 reference is in support of "including the ability 
> to retrieve intermediate certificates that may be necessary 
> to validate"; this is particularly important in cases where a 
> server sends only its certificate, sends a incomplete chain 
> or sends a incorrect chain but the right leaf.
> 
> 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 particular reason why we emphasize 4.2.2.1?
> 
> Thanks,
> 
> Joe
> 
> > -Original Message-
> > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 05, 2007 9:45 PM
> > To: Bernard Aboba; emu@ietf.org
> > Subject: RE: [Emu] Issue: Validation of server certificates 
> in Section 
> > 5.3 ofRFC 2716bis
> > 
> > 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 at Section 5.3 in RFC 2716bis, and I noticed 
> that while 
> > RFC 3280 conformant path validation is recommended for EAP-TLS 
> > servers, there is no such recommendation for EAP-TLS peers.  This 
> > seems odd.
> > 
> > For example, Section 5.3 states:
> > 
> >Since the EAP-TLS server is typically connected to the 
> Internet, it
> >SHOULD support validating the peer certificate using RFC 3280
> >[RFC3280] conformant path validation, including the ability to
> >retrieve intermediate certificates that may be necessary to 
> > validate
> >the peer certificate. For details, see [RFC3280] Section 4.2.2.1.
> > 
> > There is no equivalent statement for EAP-TLS peers. 
> > 
> > I would propose the insert the following sentence in Section 5.3:
> > 
> >The EAP-TLS peer SHOULD support validating
> >the server certificate using RFC 3280 [RFC3280] conformant path
> >validation.
> > 
> > 
> > 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue

[Joseph Salowey \(jsalowey\)]

Hi Bernard,

I don't think a valid certificate can have multiple subject
distinguished names. I think it would be more in line with RFC 3280 to
treat the subject distinguished name as part of the valid name set if it
is non-empty.  

"It is possible for more than one subjectAltName field to be present in
a peer or server certificate in addition to a non-empty subject
distinguished name.  EAP-TLS implementations SHOULD export a non-empty
Subject distinguished name along with  all the subjectAltName fields
within Peer-Ids or Server-Ids; all of the exported Peer-Ids and
Server-Ids are considered valid. "

Joe 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 05, 2007 10:05 PM
> To: emu@ietf.org
> Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue
> 
> It has been pointed out that an EAP-TLS certificate can 
> contain multiple subject or subjectAltName fields.  
> 
> To address this, I propose that we add the following text to 
> Section 5.2:
> 
> It is possible for more than one subjectAltName field to be 
> present in a peer or server certificate.  Where more than one 
> subjectAltName field is present in a certificate, EAP-TLS 
> implementations SHOULD export all the subjectAltName fields 
> within Peer-Ids or
> Server-Ids; all of the exported Peer-Ids and 
> Server-Ids are considered valid.  
> 
> Similarly, if more than one subject field is present in a 
> peer or server certificate, and no subjectAltName field is 
> present, then EAP-TLS implementations SHOULD export all of 
> the subject fields
> within Peer-Ids and Server-Ids;   all of the exported Peer-Ids and 
> Server-Ids are considered valid.
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue

[Joseph Salowey \(jsalowey\)]

I believe this is accurate.  Is there a particular ambiguity this is
clearing up?

Thanks,

Joe 

> -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 
> Peer-Id/Server-Id may not be fully explained, so that the 
> following sentence may also need to be added to Section 5.2:  
> 
> "Together the Peer-Id and Server-Id name the entities 
> involved in deriving the MSK/EMSK. "
> 
> 
> 
> 
> > From: [EMAIL PROTECTED]
> > To: emu@ietf.org
> > Date: Tue, 5 Jun 2007 22:04:56 -0700
> > Subject: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> > 
> > It has been pointed out that an EAP-TLS certificate can 
> contain multiple subject or subjectAltName fields.
> > To address this, I propose that we add the following text 
> to Section 5.2:
> > It is possible for more than one subjectAltName field to be 
> present in 
> > a peer or server certificate.  Where more than one subjectAltName 
> > field is present in a certificate, EAP-TLS implementations SHOULD 
> > export all the subjectAltName fields within Peer-Ids or Server-Ids; 
> > all of the exported Peer-Ids and Server-Ids are considered valid.
> > Similarly, if more than one subject field is present in a peer or 
> > server certificate, and no subjectAltName field is present, then 
> > EAP-TLS implementations SHOULD export all of the subject fields
> > within Peer-Ids and Server-Ids;   all of the exported Peer-Ids and
> > Server-Ids are considered valid.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue

[Joseph Salowey \(jsalowey\)]

I agree, my intent wasn't to mandate a DN, my text needs to be improved.


Does this help?

"It is possible for more than one subjectAltName field to be present in
a peer or server certificate in addition to an empty or non-empty
subject distinguished name.  EAP-TLS implementations SHOULD export all
the subjectAltName fields within Peer-Ids or Server-Ids.  If the Subject
distinguished name is non-empty then it SHOULD be exported within the
Peer-Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
considered valid. "
 
Thanks,

Joe

> -Original Message-
> From: Ryan Hurst [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 06, 2007 4:17 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> 
> 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 (jsalowey) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 06, 2007 3:53 PM
> To: Bernard Aboba; emu@ietf.org
> Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> 
> Hi Bernard,
> 
> I don't think a valid certificate can have multiple subject 
> distinguished names. I think it would be more in line with 
> RFC 3280 to treat the subject distinguished name as part of 
> the valid name set if it is non-empty.  
> 
> "It is possible for more than one subjectAltName field to be 
> present in a peer or server certificate in addition to a 
> non-empty subject distinguished name.  EAP-TLS 
> implementations SHOULD export a non-empty Subject 
> distinguished name along with  all the subjectAltName fields 
> within Peer-Ids or Server-Ids; all of the exported Peer-Ids 
> and Server-Ids are considered valid. "
> 
> Joe 
> 
> > -Original Message-
> > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 05, 2007 10:05 PM
> > To: emu@ietf.org
> > Subject: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> > 
> > It has been pointed out that an EAP-TLS certificate can contain 
> > multiple subject or subjectAltName fields.
> > 
> > To address this, I propose that we add the following text 
> to Section 
> > 5.2:
> > 
> > It is possible for more than one subjectAltName field to be 
> present in 
> > a peer or server certificate.  Where more than one subjectAltName 
> > field is present in a certificate, EAP-TLS implementations SHOULD 
> > export all the subjectAltName fields within Peer-Ids or
> > Server-Ids; all of the exported Peer-Ids and 
> > Server-Ids are considered valid.  
> > 
> > Similarly, if more than one subject field is present in a peer or 
> > server certificate, and no subjectAltName field is present, then 
> > EAP-TLS implementations SHOULD export all of the subject fields
> > within Peer-Ids and Server-Ids;   all of the exported Peer-Ids and 
> > Server-Ids are considered valid.
> > 
> > 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue

[Joseph Salowey \(jsalowey\)]

 

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 7:40 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> 
> 
> RFC 3280 says:
> 
> "  In addition, legacy implementations exist where an RFC 822 name is
>embedded in the subject distinguished name as an EmailAddress
>attribute.  The attribute value for EmailAddress is of 
> type IA5String
>to permit inclusion of the character '@', which is not part of the
>PrintableString character set.  EmailAddress attribute 
> values are not
>case sensitive (e.g., "[EMAIL PROTECTED]" is the same as
>"[EMAIL PROTECTED]").
> 
>Conforming implementations generating new certificates with
>electronic mail addresses MUST use the rfc822Name in the subject
>alternative name field (section 4.2.1.7) to describe such 
> identities.
>Simultaneous inclusion of the EmailAddress attribute in the subject
>distinguished name to support legacy implementations is deprecated
>but permitted."
> 
> Based on this, if the certificate is encoding an NAI as a 
> name, then the subject alternative name field MUST be used.  
> Simultaneous inclusion of the NAI within an EmailAddress 
> attribute in the subject distinguished name is deprecated, 
> but permitted. 
> 
> So in the case where an NAI is encoded in the subjectAltName 
> field, the subject DN would be a duplicate, no?  
> 
[Joe] No, the EmailAddress RDN may not be included in the Subject DN. 

> 
> 
> 
> 
> 
> > Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id 
> > Issue
> > Date: Wed, 6 Jun 2007 16:37:08 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> emu@ietf.org
> > CC: 
> > 
> > I agree, my intent wasn't to mandate a DN, my text needs to 
> be improved.
> > 
> > 
> > Does this help?
> > 
> > "It is possible for more than one subjectAltName field to 
> be present 
> > in a peer or server certificate in addition to an empty or 
> non-empty 
> > subject distinguished name.  EAP-TLS implementations SHOULD 
> export all 
> > the subjectAltName fields within Peer-Ids or Server-Ids.  If the 
> > Subject distinguished name is non-empty then it SHOULD be exported 
> > within the Peer-Ids or Server-Ids.  All of the exported 
> Peer-Ids and 
> > Server-Ids are considered valid. "
> >  
> > Thanks,
> > 
> > Joe
> > 
> > > -Original Message-
> > > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 06, 2007 4:17 PM
> > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> > > Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id 
> > > Issue
> > > 
> > > 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 (jsalowey) [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 06, 2007 3:53 PM
> > > To: Bernard Aboba; emu@ietf.org
> > > Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id 
> > > Issue
> > > 
> > > Hi Bernard,
> > > 
> > > I don't think a valid certificate can have multiple subject 
> > > distinguished names. I think it would be more in line 
> with RFC 3280 
> > > to treat the subject distinguished name as part of the valid name 
> > > set if it is non-empty.
> > > 
> > > "It is possible for more than one subjectAltName field to 
> be present 
> > > in a peer or server certificate in addition to a 
> non-empty subject 
> > > distinguished name.  EAP-TLS implementations SHOULD export a 
> > > non-empty Subject distinguished name along with  all the 
> > > subjectAltName fields within Peer-Ids or Server-Ids; all of the 
> > > exported Peer-Ids and Server-Ids are considered valid. "
> > > 
> > > Joe
> > > 
> > > > -Original Message-
> > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > > 

RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates

[Joseph Salowey \(jsalowey\)]

Not all identities are an RFC822 Name so using an RFC822 name is not
always appropriate.   If you are going to include an RFC822 name in the
certificate then it should be in the RFC822 SubjecAltName.  The Subject
distinguished name may include other name elements.

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 7:54 AM
> To: emu@ietf.org
> Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> 
> 
> RFC 3280 Section 4.1.2.6 says:
> 
>Conforming implementations generating new certificates with
>electronic mail addresses MUST use the rfc822Name in the subject
>alternative name field (section 4.2.1.7) to describe such 
> identities.
>Simultaneous inclusion of the EmailAddress attribute in the subject
>distinguished name to support legacy implementations is deprecated
>but permitted.
> 
> This leads me to believe that the statement below from 
> Section 5.2 isn't quite right: 
> 
> "Although the use of the subject name field is existing 
> practice, its use in EAP-TLS is deprecated and Certification 
> Authorities are encouraged to use the subjectAltName field instead. "
> 
> An RFC 3280-equivalent statement would be:
> 
> "Conforming implementations generating new certificates with 
> network access identifiers MUST use the rfc822Name in the 
> subject alternative name field to describe such identities."
> ___
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue with RFC 2716bis key generation

[Joseph Salowey \(jsalowey\)]

Is there a reason why we changed to TLS-PRF-128 for the MSK? 
Is this a huge issue given that there are not likely any existing
implementations of EAP-TLS using TLS 1.2?

Joe


> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 12:05 PM
> To: emu@ietf.org
> Subject: [Emu] Issue with RFC 2716bis key generation
> 
> It has been pointed out by Paul Funk that the key generation 
> formula specified in RFC 2716bis could cause backward 
> compatibility problems once TLS v1.2 is introduced. 
>  
> The formula in -09 is as follows:
>  
> MSK(0,63)= TLS-PRF-64(TMS, "client EAP encryption",
> client.random || server.random)
>EMSK(0,63)   = second 64 octets of:
>   TLS-PRF-128(TMS, "client EAP encryption",
> client.random || server.random)
>IV(0,63) = TLS-PRF-64("", "client EAP encryption",
> client.random || server.random)
> 
> The issue here is that RFC 2716 Section 3.5 specifies a 
> different approach:
>  
>MSK(0,63)   = first 64 octets of:
>   TLS-PRF-128(TMS, "client EAP encryption",
> client.random || server.random)
>EMSK(0,63)   = second 64 octets of:
>   TLS-PRF-128(TMS, "client EAP encryption",
> client.random || server.random)
>IV(0,63) = TLS-PRF-64("", "client EAP encryption",
> client.random || server.random)
>  
> With the current TLS PRF, these two approaches are identical. 
>  However, this is not necessarily true for all PRFs that 
> could conceivably be negotiated within TLS v1.2.  
>  
> The text from RFC 2716 Section 3.5 reads as follows:
>  
>Since the normal TLS keys are used in the handshake, and therefore
>should not be used in a different context, new encryption keys must
>be derived from the TLS master secret for use with PPP encryption.
>For both peer and EAP server, the derivation proceeds as follows:
>given the master secret negotiated by the TLS handshake, the
>pseudorandom function (PRF) defined in the specification for the
>version of TLS in use, and the value random defined as the
>concatenation of the handshake message fields 
> client_hello.random and
>server_hello.random (in that order), the value PRF(master secret,
>"client EAP encryption", random) is computed up to 128 
> bytes, and the
>value PRF("", "client EAP encryption", random) is computed up to 64
>bytes (where "" is an empty string).  The peer encryption key (the
>one used for encrypting data from peer to EAP server) is 
> obtained by
>truncating to the correct length the first 32 bytes of the 
> first PRF
>of these two output strings.  The EAP server encryption 
> key (the one
>used for encrypting data from EAP server to peer), if 
> different from
>the client encryption key, is obtained by truncating to the correct
>length the second 32 bytes of this same PRF output string.  The
>client authentication key (the one used for computing MACs for
>messages from peer to EAP server), if used, is obtained by 
> truncating
>to the correct length the third 32 bytes of this same PRF output
>string.  The EAP server authentication key (the one used for
>computing MACs for messages from EAP server to peer), if 
> used, and if
>different from the peer authentication key, is obtained by 
> truncating
>to the correct length the fourth 32 bytes of this same PRF output
>string.  The peer initialization vector (IV), used for 
> messages from
>peer to EAP server if a block cipher has been specified, 
> is obtained
>by truncating to the cipher's block size the first 32 bytes of the
>second PRF output string mentioned above.  Finally, the server
>initialization vector (IV), used for messages from peer to 
> EAP server
>if a block cipher has been specified, is obtained by truncating to
>the cipher's block size the second 32 bytes of this second PRF
>output.
> 
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue with RFC 2716bis key generation

[Joseph Salowey \(jsalowey\)]

So TLS 1.2 won't change the PRF for TLS 1.1-.  

Shouldn't existing implementations based on RFC2716 interoperate with
RFC2716bis implementations using TLS 1.1 and 1.0?  

What we define in 2716bis is what EAP-TLS implementations based on TLS
1.2 will use.   These implementations should interoperate with one
another.  

I'm not sure where the problem is. 

Joe

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 2:52 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Issue with RFC 2716bis key generation
> 
> RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis 
> is using TLS-PRF-64.  
>  
> 
> 
> > Subject: RE: [Emu] Issue with RFC 2716bis key generation
> > Date: Thu, 7 Jun 2007 14:36:52 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; emu@ietf.org
> > CC: 
> > 
> > Is there a reason why we changed to TLS-PRF-128 for the MSK? 
> > Is this a huge issue given that there are not likely any existing 
> > implementations of EAP-TLS using TLS 1.2?
> > 
> > Joe
> > 
> > 
> > > -Original Message-
> > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 07, 2007 12:05 PM
> > > To: emu@ietf.org
> > > Subject: [Emu] Issue with RFC 2716bis key generation
> > > 
> > > It has been pointed out by Paul Funk that the key 
> generation formula 
> > > specified in RFC 2716bis could cause backward 
> compatibility problems 
> > > once TLS v1.2 is introduced.
> > > 
> > > The formula in -09 is as follows:
> > > 
> > > MSK(0,63) = TLS-PRF-64(TMS, "client EAP encryption", 
> client.random 
> > > || server.random)
> > > EMSK(0,63) = second 64 octets of:
> > > TLS-PRF-128(TMS, "client EAP encryption", client.random || 
> > > server.random)
> > > IV(0,63) = TLS-PRF-64("", "client EAP encryption", 
> client.random || 
> > > server.random)
> > > 
> > > The issue here is that RFC 2716 Section 3.5 specifies a different 
> > > approach:
> > > 
> > > MSK(0,63) = first 64 octets of:
> > > TLS-PRF-128(TMS, "client EAP encryption", client.random || 
> > > server.random)
> > > EMSK(0,63) = second 64 octets of:
> > > TLS-PRF-128(TMS, "client EAP encryption", client.random || 
> > > server.random)
> > > IV(0,63) = TLS-PRF-64("", "client EAP encryption", 
> client.random || 
> > > server.random)
> > > 
> > > With the current TLS PRF, these two approaches are identical. 
> > > However, this is not necessarily true for all PRFs that could 
> > > conceivably be negotiated within TLS v1.2.
> > > 
> > > The text from RFC 2716 Section 3.5 reads as follows:
> > > 
> > > Since the normal TLS keys are used in the handshake, and 
> therefore 
> > > should not be used in a different context, new encryption 
> keys must 
> > > be derived from the TLS master secret for use with PPP encryption.
> > > For both peer and EAP server, the derivation proceeds as follows:
> > > given the master secret negotiated by the TLS handshake, the 
> > > pseudorandom function (PRF) defined in the specification for the 
> > > version of TLS in use, and the value random defined as the 
> > > concatenation of the handshake message fields client_hello.random 
> > > and server_hello.random (in that order), the value PRF(master 
> > > secret, "client EAP encryption", random) is computed up to 128 
> > > bytes, and the value PRF("", "client EAP encryption", random) is 
> > > computed up to 64 bytes (where "" is an empty string). The peer 
> > > encryption key (the one used for encrypting data from peer to EAP 
> > > server) is obtained by truncating to the correct length 
> the first 32 
> > > bytes of the first PRF of these two output strings. The 
> EAP server 
> > > encryption key (the one used for encrypting data from EAP 
> server to 
> > > peer), if different from the client encryption key, is 
> obtained by 
> > > truncating to the correct length the second 32 bytes of this same 
> > > PRF output string. The client authentication key (the one 
> used for 
> > > computing MACs for messages from peer to EAP server), if used, is 
> > > obtained by truncating to the correct length the third 32 
> bytes of 
> > > this same PRF output strin

RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates

[Joseph Salowey \(jsalowey\)]

Ok the text below seems to mandate rfc822 SubjectAltName in all cases.
How about just removing the reference to the emailAddress RDN from that
paragraph.  Perhaps replacing it by:

"If subject naming information is present only in the subject name field
and the peer identity represents a host or device the subject name field
SHOULD contain a CN RDN or serialNumber RDN.  It is RECOMMENDED that
when the peer identity represents a user the Subject distinguished name
should not contain an emailAddress RDN, but rather use the rfc822
SubjectAltName as described above." 

Joe


> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 10:48 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> 
> Right.  The RFC 3280 statement only applies to RFC 822 names. 
>  That's why I think that the text should focus on those names. 
> 
> > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS 
> certificates
> > Date: Thu, 7 Jun 2007 08:57:49 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; emu@ietf.org
> > 
> > Not all identities are an RFC822 Name so using an RFC822 
> name is not 
> > always appropriate. If you are going to include an RFC822 
> name in the 
> > certificate then it should be in the RFC822 SubjecAltName. 
> The Subject 
> > distinguished name may include other name elements.
> > 
> > > -Original Message-
> > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 07, 2007 7:54 AM
> > > To: emu@ietf.org
> > > Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> > > 
> > > 
> > > RFC 3280 Section 4.1.2.6 says:
> > > 
> > > Conforming implementations generating new certificates with 
> > > electronic mail addresses MUST use the rfc822Name in the subject 
> > > alternative name field (section 4.2.1.7) to describe such 
> > > identities.
> > > Simultaneous inclusion of the EmailAddress attribute in 
> the subject 
> > > distinguished name to support legacy implementations is 
> deprecated 
> > > but permitted.
> > > 
> > > This leads me to believe that the statement below from 
> Section 5.2 
> > > isn't quite right:
> > > 
> > > "Although the use of the subject name field is existing practice, 
> > > its use in EAP-TLS is deprecated and Certification 
> Authorities are 
> > > encouraged to use the subjectAltName field instead. "
> > > 
> > > An RFC 3280-equivalent statement would be:
> > > 
> > > 
> > > ___
> > > Emu mailing list
> > > Emu@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/emu
> > > 
> 
> 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu