Re: [Emu] Commitment Message handling in EAP-TLS 1.3

[Jim Schaad]

I think it might be a good idea to specify that the close_notify is always
sent when the TLS channel is closed.  I was thinking that if we really
wanted a content on the EAP Response, then it be reasonable to have the
client respond with a close_notify as well.

-Original Message-
From: Alan DeKok  
Sent: Tuesday, August 4, 2020 10:16 AM
To: Jorge Vergara 
Cc: Jim Schaad ; Mohit Sethi M
; EMU WG ; Benjamin Kaduk

Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Aug 3, 2020, at 2:23 PM, Jorge Vergara  wrote:
> 
> ACK that EAP-TLS does not need to keep the connection open.

  I agree.  I'm happy to change the implementations to send "close notify".

> Question: should some consideration be given to consistency with other EAP
methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP

  When those methods send application data, they don't need to do anything
else.

  When those methods use fast reconnect, they don't send application data.
So the other EAP methods should also send "close notify" in that case.

  Alan DeKok.

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

Re: [Emu] Commitment Message handling in EAP-TLS 1.3

[Jim Schaad]

-Original Message-
From: Alan DeKok  
Sent: Saturday, August 1, 2020 6:53 AM
To: Jim Schaad 
Cc: Mohit Sethi M ; EMU WG ; Benjamin 
Kaduk 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Jul 31, 2020, at 12:30 PM, Jim Schaad  wrote:
> 
> Ok – so this issue was raised at IETF 102.  (presentation 
> https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00)
>  
> Just reading the slides is not telling me what was the problem.  I think I am 
> going to need to hear the audio of the presentation.  I have an extremely 
> vague memory that there was an OpenSSL problem involved here but I would not 
> swear to that.  You might be a better description either from John Mattsson 
> or Jouni.

  IIRC it's that OpenSSL doesn't have an API to send a zero bytes of 
application data.  I think other TLS implementations have similar limitations.

  Regardless of what solution is implemented, the requirement is to have a 
positive acknowledgement that TLS setup is finished.  This step seems to be 
missing by default in TLS 1.3.

  I suspect that most uses of TLS will *always* send application data.  Which 
makes EAP-TLS an outlier.  Hence the need for hacks like "send application data 
as one octet of zero".

[JLS]  Cobwebs are slowly being shaken out of my brain.  
*  I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS 
confused.  Not surprising because I only ever spent any time on EAP-TEAP .  In 
EAP-TLS, once the handshake has been completed the tunnel does not need to be 
kept open.  This is the opposite of the case for EAP-TEAP where the tunnel is 
used for application EAP data.

* Based on that I agree with EKR that the close notification could be used 
instead of sending the one byte of application data.   Sending the close 
notification means that the server will no longer be sending any data and thus 
would not send any new session tickets.

EAP Peer  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
 <  TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 EAP-Request/
EAP-Type=EAP-TLS
 <(close_notify)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Success

Jim



  Alan DeKok.


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

Re: [Emu] Commitment Message handling in EAP-TLS 1.3

[Jim Schaad]

Ok – so this issue was raised at IETF 102.  (presentation 
https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00)

 

Just reading the slides is not telling me what was the problem.  I think I am 
going to need to hear the audio of the presentation.  I have an extremely vague 
memory that there was an OpenSSL problem involved here but I would not swear to 
that.  You might be a better description either from John Mattsson or Jouni.

 

From: Mohit Sethi M  
Sent: Friday, July 31, 2020 7:09 AM
To: emu@ietf.org
Cc: Benjamin Kaduk ; Jim Schaad ; Eric 
Rescorla 
Subject: Commitment Message handling in EAP-TLS 1.3

 

Dear all,

Thanks all for the discussion on the commitment message.

draft-ietf-emu-eap-tls13-10 
(https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the 
ticket establishment and commitment message:

EAP Peer  EAP Server
 
 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
 <  TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 EAP-Request/
EAP-Type=EAP-TLS
   (TLS NewSessionTicket,
 <Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Success

and the relevant text on commitment message: 

When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more
   handshake messages.  The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate EAP-
   Request.  Sending the Commitment Message in a separate EAP-Request
   adds an additional round-trip, but may be necessary in TLS
   implementations that only implement a subset of TLS 1.3.

I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the 
discussion over email will help me understand the issue. 

--Mohit

 

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

Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

[Jim Schaad]

 

 

From: Emu  On Behalf Of Mohit Sethi M
Sent: Monday, July 13, 2020 11:50 AM
To: Jorge Vergara ; Alan DeKok 
; Hannes Tschofenig 
Cc: emu@ietf.org
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message 
handling

 

Hi Alan, Jorge, Jim, Hannes,

One octet of plaintext naturally results in a larger encrypted record (which 
serves as the notification). The current text only explains how to construct 
the encrypted record by setting the TLSPlaintext to one octet of zeros. 

RFC 8446 in any case says the following in Section 5.1.  Record Layer: 
"Application Data messages contain data that is opaque to TLS. Application Data 
messages are always protected."

Perhaps the text can be made more explicit as follows:

When an EAP server has sent its last handshake message (Finished or a 
Post-Handshake), it commits to not sending any more handshake messages by 
sending an encyrpted Commitment Message.  The Commitment Message is an 
encyrpted TLS record constructed with application data 0x00 (i.e. a TLS record 
with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and 
TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext is 
greater than the 

 

[JLS] I tend to find the above confusing.  Why not stop with saying the commit 
message is a single byte of 0 in the application data stream.  All of the rest 
I find to just be confusion.

 

corresponding TLSPlaintext.length due to the inclusion of 
TLSInnerPlaintext.type and any padding supplied by the sender.  EAP server 
implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer 
implementations MUST accept any application data as a Commitment Message from 
the EAP server to not send any more handshake messages.  The Commitment Message 
may be sent in the same EAP-Request as the last handshake record or in a 
separate EAP-Request.  Sending the Commitment Message in a separate EAP-Request 
adds an additional round-trip, but may be necessary in TLS implementations that 
only implement a subset of TLS 1.3.

Is this amenable to all? 

--Mohit

On 7/13/20 9:24 PM, Jorge Vergara wrote:

Windows expects an encrypted octet. My brain had automatically translated the 
plaintext -> encrypted based on the timing of the commitment message - which 
was apparently an incorrect translation at the time. Interop has been tested 
with FreeRADIUS and hostapd.
 
-Original Message-
From: Emu    On Behalf Of 
Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M   

Cc: Roman Danyliw   ; emu@ietf.org 
 
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message 
handling
 
On Jul 13, 2020, at 1:44 PM, Mohit Sethi M   
 wrote:

 
Dear all,
 
draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD 
Followup". Our AD (Roman) had done an excellent review 
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2F
 

 
data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3Dreserved=0),
 which I addressed in version 10 
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2F
 

 
data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3Dreserved=0).
 

Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 
implementation. He made 3 alternative suggestions for achieving the 
functionality of the commitment message 
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2F
 

Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

[Jim Schaad]

My expectation would be that the third option from Hannes is what should be 
done.  The commit message should be encrypted and not a plain text message.

 

Jim

 

 

From: Mohit Sethi M  
Sent: Monday, July 13, 2020 10:44 AM
To: emu@ietf.org
Cc: Jim Schaad ; Alan DeKok 
; j...@w1.fi; Roman Danyliw ; Hannes 
Tschofenig 
Subject: Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

 

Dear all,

draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD 
Followup". Our AD (Roman) had done an excellent review 
(https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which 
I addressed in version 10 
(https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyVVKpObzyFc0CAJ-Pig/). 

The only outstanding issue is the handling of the commitment message. The 
current text in the draft says the following:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more
   handshake messages.  The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate EAP-
   Request.  Sending the Commitment Message in a separate EAP-Request
   adds an additional round-trip, but may be necessary in TLS
   implementations that only implement a subset of TLS 1.3.


Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 
implementation. He made 3 alternative suggestions for achieving the 
functionality of the commitment message 
(https://mailarchive.ietf.org/arch/msg/emu/eM-14QdDQjg7DvhAVJMzpvPz5wg/).  

I would like to close this issue and would like to receive feedback from others 
who have commented before or are working on implementations: Jim, Alan, Jouni; 
please let us know what do you think about the change? 

--Mohit

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

Re: [Emu] Proposal: SASL over EAP

[Jim Schaad]

-Original Message-
From: Emu  On Behalf Of Rick van Rein
Sent: Wednesday, April 22, 2020 12:52 AM
To: Alan DeKok 
Cc: EMU WG 
Subject: Re: [Emu] Proposal: SASL over EAP

Hi Alan / EMU,

I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs Eduroam
and I think he has mentioned Diameter before.  Our use case is completely
new anyway, so we have a free choice.

Good to hear that EAP-SASL sounds implementable.  We haven't built it, but I
usually "mentally program" the stuff while spec'ing.

>   The concern is that the document does not explain *who* would use this
solution, or *why* they would use it.  Or, why it would be used instead of
existing EAP methods.

I can add that, thanks for asking.  There are WG's where I've been requested
to remove such contextual aspects.

>   The ABFAB working group standardized precisely this many years ago.  One
implementation is Moonshot:
> 
> https://www.jisc.ac.uk/rd/projects/moonshot

I know about Moonshot, and that the project was abandoned.  What it does iss
the reverse; Moonshot runs EAP on top of GSS-API / SASL, whereas I am
proposing SASL on top of EAP.

[JLS] I am a bit surprised at hearing this is abandoned given that they
released an update of the software on the 20th of April


>   They demonstrated roaming users authenticating to home networks using
EAP over AAA.  Not just for network access, but for SSH, Web login, etc.  It
would be good to explain why ABFAB is not applicable to this problem.

That is fair crisicism, and I will think it over for a new version.


Thanks for the input, they are good input to a new version.  I'll think
about a few for a while, as that usually helps to better balance things.

-Rick

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

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Jim Schaad]

I am going to come down on the side of no PSK should not be supported.
However my issues have nothing to do with how things are implemented and
more to do with the security properties of the EAP method.

When you use certificates, there is no leakage of who the client is as this
is encrypted by TLS.  When you use a restore session ticket, it is possible
to limit the number of times that the ticket can be used (for example once).
The PSK identity is public and unprotected so it can be used to track.  If
one is using PSK for the purpose of authentication then that value will
always be visible to intermediate parties for the purpose of tracking.
This can be slightly mitigated by using restore session tickets with PSK,
but you are going to send that PSK identifier over the wire many times.


This is just informational and can be ignored:

My current favorite way to deal with PSK/ticket identifiers is with
encryption:

32 bytes of index into table
32 bytes of date information
32 bytes of SIV (synthetic IV)

Encrypt the first two items using the SIV.  You can then have multiple keys
for decryption.  One for PSKs and a resolving one for session tickets.  If
the identifier does not decrypt then you reject.  Otherwise you look at the
date information and the index in the table for the secret information.  

It is even possible to play games with AAD to do things like scope the
tickets up front - if you put in the name/address of the NAS then you have a
prescreen on where the ticket can be used.

Jim




-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Wednesday, September 18, 2019 2:59 PM
To: Owen Friel (ofriel) 
Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> Giving some implementation guidance seems appropriate here. Naively, one
could envisage the implementation simply having a DB table for extern PSKs
and a table that holds NewSessionTickets. An implementation could simply
check the extern PSK table using the PskIdentity.identity, and if no match
is found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK
identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3
resumption means that OpenSSLL will choose whatever PSK identity it deems
fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK
identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c
8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if
there is a clash (poor randoms, etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the
draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be
generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?
If "end users" shouldn't be doing this, the draft also needs to call that
out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not
the actual PSK of course.

  Sure.

> And the PSK *must not* be a user-manageable string such as the
>> NAI.  On the other hand, if the PSK is sent after encryption begins, 
>> then the PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> ...
> so TLS-PSK is not suitable for a user entered low entropy password. We 
> need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT
onboarding where a TLS-PSK authentication has definite value, and we really
don't want to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.
I'm not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be
using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be
automatically provisioned with long binary data for both PSK identity and
PSK itself".  Or even "PSK identities and/or passwords that are composed
solely of printable ASCII characters are likely to be humanly entered, and
thus insecure".

  Which means, of course, that people will ignore that and demand simple
user names / passwords for EAP-TLS with PSK.  Because that's ever so much
easier than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding
it.

  Alan DeKok.

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

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

[Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Jim Schaad]

I am just finally getting caught up on mail for the EMU WG and am getting
this done.

It should probably be clarified that Figure 1has the additional restriction
that the server is not sending any resumption tickets as well.It would
also be better to label the TLS Application Data as the commitment message
as no other TLS Application data is being sent.

I think that it might be reasonable to put in a note for Figure 2 that if a
client does receive a fatal from the hello message, then changing the
offered key share algorithm is one thing that might be successful in the
future - That is put in a note to match what the request retry message does.
Okay - I found the use of the retry down below but it is not referenced from
here but it is still labeled as a server rejects the client hello.

In section 2.1.5 - You are mandating support for resumption.  Is this really
what you are planning to do?  If this is true then lots of the previous text
seems to be off because this is not part of that discussion.

In section 2.1.6 - Should there be a recommendation (or not) that when a
resumption ticket is used, then a new ticket (or set of tickets) ought to be
provided to the client.

In section 2.5 - I don't know that I have the ability to control what the
TLS block looks like to the extent that this seems to be wanting to do.

In section 5.7 - I am not sure why one could not re-check for revocation
when doing a resumption, I would expect that this is only server side that
would do it but the current paragraph two outlaws it.

I am a little surprised that the padding feature of TLS 1.3 received
absolutely no mention in this document.

Jim


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

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Jim Schaad]

I cannot speak to PEAP, but it would seem that TEAP might need this feature
as, at least on resumption, it is totally optional for both sides to use any
TLVs an thus the same issue might be present.  TTLS seems to always require
that the client send a AVP, but I am not sure that it is required for the
server based on a really fast read.

Jim


-Original Message-
From: Jouni Malinen  
Sent: Sunday, July 28, 2019 12:58 PM
To: John Mattsson 
Cc: Alan DeKok ; Jim Schaad
; EMU WG 
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

On Thu, Jul 25, 2019 at 10:49:40AM +, John Mattsson wrote:
> Question: How will the use of Application data with TLSPlaintext.fragment
= 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I
assume they will need to send the same 0x00 to commit to not sending any
more handshake messages as well as using application data for other
purposes. I do not know exactly how the TLSPlaintext fragments look like in
EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be
chosen so that the string does not collide with any other strings used.

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or at
least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before concluding
Phase 2. With TEAP, there is some more discussion about use of the
NewSessionTicket option for provisioning the new PAC (which seem a bit
inconvenient for some use cases IMHO, but nevertheless, I don't see this
needing any additional mechanism for indicating when the NewSessionTicket is
not going to be showing up).

-- 
Jouni MalinenPGP id EFC895FA

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

Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

[Jim Schaad]

> -Original Message-
> From: John Mattsson 
> Sent: Thursday, March 21, 2019 8:56 AM
> To: Jim Schaad ; draft-ietf-emu-eap-tl...@ietf.org
> Cc: 'EMU WG' 
> Subject: Re: Review of draft-ietf-emu-eap-tls13-04
> 
> Thanks for the thorough review Jim!
> 
> -Original Message-
> From: Jim Schaad 
> Date: Wednesday, 20 March 2019 at 11:03
> To: "draft-ietf-emu-eap-tl...@ietf.org" 
> Cc: 'EMU WG' 
> Subject: Review of draft-ietf-emu-eap-tls13-04
> Resent-From: 
> Resent-To: John Mattsson ,
> 
> Resent-Date: Wednesday, 20 March 2019 at 11:03
> 
> General Comment:  I have a strong tendency to like positive rather than
> negative statements in documents, thus the use of MUST rather than
> MUST NOT.
> Additionally, I have a general tendency to like to know what should happen
> if a statement is violated.  Thus consider the following from section 
> 2.1.1:
> 
> Agree, if possible it is often better with "MUST" statements describing what
> is happening. The disadvantage with MUST statements are that they rule out
> things that may be specified in updates to RFC 8446.
> 
> TLS 1.3 introduces early application data; early application data SHALL 
> NOT
> be used with EAP-TLS.
> 
> I would prefer to see this as
> 
> TLS 1.3 introduced early application data;  if a server receives a client
> hello with early application data it MUST abort the handshake with an
> EAP-Failure.  The server MAY generate a TLS-Alert as well.
> 
> In the case of early data, Section 4.2.10 of RFC 8446 states that "A server
> which receives an "early_data" extension MUST behave in one of three
> ways:". The three ways are: ignoring early_data, send HelloRetryRequest,
> and accepting early_data.
> 
> Aborting the handshake would not follow RFC 8446, so I don't think we want
> that. I would suggest to follow RFC 8446 and specify that the server ignore
> the early_data extension or replies with HelloRetryRequest. I suggest
> writing:
> 
> TLS 1.3 introduced early application data which is not used in EAP-TLS. A
> server which receives an "early_data" extension MUST ignore the extension
> or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC
> 8446.

That is better, an additional note that new session tickets MUST NOT include 
the early data extension would also be relevant.


> 
> This made me realize that draft-ietf-emu-eap-tls13-04 does not mention
> HelloRetryRequest at all. I think draft-ietf-emu-eap-tls13-04 should mention
> HelloRetryRequest add add a figure describing the message flow.
> Alternatively state that HelloRetryRequest MUST NOT be used (or positively
> that the server MUST respond with ServerHello).
> 
> Section 2.1.2 - The following sentence:
> If the EAP peer did not supply a "key_share" extension
>when offering resumption, the EAP server needs to reject the
>ClientHello and the EAP peer needs to restart a full handshake.
> 
> Appears to state that the key share MUST be provided even though the
> previous sentence said that it was only a SHOULD.  Which is it?
> 
> Good catch. Definitely something missing in that sentence. Should be
> SHOULD following RFC 8446. Suggested update:
> 
> "If the EAP peer did not supply a "key_share" extension when offering
> resumption, an EAP server declining resumption needs to reject the
> ClientHello and force the EAP peer to restart a full handshake.  The message
> flow in this case is given by Figure 4 followed by Figure 1 or Figure 2."

Yes better

> 
> Section 2.1.3 - I am having a problem understanding why you have Figure 8
> in
> the system.
> 
> There was an earlier comment from someone requesting more figures
> describing messages flows for various use cases and errors.
> 
> First, a new session ticket would only be returned if the
> client asked for one to be returned.  Thus the client will never receive 
> one
> that is unexpected.
> 
> That is not my understanding of how NewSessionTicket works according to
> RFC 8446. The session_ticket extension is a far as I understand deprecated in
> TLS 1.3. The only text I can find in RFC 8446 is that

Oh fudge.  Losing the indicator that a client wants this seems to be a stupid 
decision on the part of TLS.I guess that I just assumed it was still there 
because it was in the past.  

> 
> "At any time after the server has received the client Finished message, it
> MAY send a NewSessionTicket message."
> 
> Secondly, the authentication has finished and you are
> in a situation where if you had not asked for the ticket everything 

Re: [Emu] Notes on session resumption with TLS-based EAP methods

[Jim Schaad]

I would totally agree that this type of guidance needs to be added to this
document.

Jim


> -Original Message-
> From: Alan DeKok 
> Sent: Sunday, March 10, 2019 5:58 AM
> To: Jim Schaad 
> Cc: Michael Richardson ; EMU WG
> 
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
> 
> On Mar 9, 2019, at 7:46 PM, Jim Schaad  wrote:
> > Yes - The resumption credential is on the user's device and on the TLS
> > server.  If the user's device moves then things are just fine.  Again,
> > the TLS server would need to check the credentials from the cached
> > session
> 
>   My point is that neither RFC 5216 nor this document gives any guidance
> here.  They don't even mention checking cached authentication data.
> 
>   Alan DeKok.

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

Re: [Emu] Notes on session resumption with TLS-based EAP methods

[Jim Schaad]

> -Original Message-
> From: Emu  On Behalf Of Michael Richardson
> Sent: Saturday, March 9, 2019 3:51 PM
> To: 'EMU WG' 
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
> 
> 
> Jim Schaad  wrote:
> > I am finally getting caught up on this thread and I have found it to
be very
> > frustrating because it appears to make an assumption which I do not
> believe
> > is warranted.
> 
> > I do not see any problems with allowing TLS session to be used
across
> > different types of EAP assuming that EAP correctly checks the output
of
> TLS
> > before continuing.  When a session ticket is issued for a TLS
session it
> > contains the authentication done by that TLS authentication session.
It
> > does not contain any of the containing EAP authentication
information
> that
> > has been done.
> 
> I have been following along the discussion, and I think that I missed the
use
> case.
> Why are we having this discussion?
> 
> alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his
> alan> session, but this time uses TTLS.  It's not clear that anything in
> alan> the spec forbids or prevents this.
> 
> What's in it for the user?
For the user, the win is that the TLS handshake is much smaller and
therefore runs both faster and more reliably.  

> Is this an attack?

Depends on what you think session resumption gives you.  From my point of
view there is absolutely no attack as the server still needs to check that
the client certificate credentials are acceptable.  Whether this is none or
specific trust anchors.  

> Does it avoid an interaction with a human?

Yes - this would be cached locally in some way.  The assumption is that you
would not do this on a kiosk type situation or make sure that they are
strongly protected to the user.

> Does it enable mobility between different networks?

Yes - The resumption credential is on the user's device and on the TLS
server.  If the user's device moves then things are just fine.  Again, the
TLS server would need to check the credentials from the cached session
against the new network to make sure that nothing bad is happening and the
client can operate on that new network.

> Does this avoid some interaction with a two-factor authenticator?

That depends on how the two-factor authentication is being done.  If both
factors are some how  bound up in the TLS protocol itself, then it boils
down to single factor authentication.  If the two factors are a client
certificate - using TLS - and some type of pass phrase which is being passed
in EAP or over the application protocol - then there is nothing that is
being released.  One assumes that the same type of access to the private key
is still needed for running TLS and then the second factor is going to be
required to be entered in some manner and sent as part of 
EAP or the application.

Jim

> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

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

Re: [Emu] Notes on session resumption with TLS-based EAP methods

[Jim Schaad]

I am finally getting caught up on this thread and I have found it to be very
frustrating because it appears to make an assumption which I do not believe
is warranted.

I do not see any problems with allowing TLS session to be used across
different types of EAP assuming that EAP correctly checks the output of TLS
before continuing.  When a session ticket is issued for a TLS session it
contains the authentication done by that TLS authentication session.  It
does not contain any of the containing EAP authentication information that
has been done.

Example:

Run EAP where you do TLS anonymous followed by a password and get the
session ticket.  This session ticket is associated with ZERO client
authentication information, not even the password because the session ticket
would be issued before the password was obtained.

Take that session ticket and run it in an EAP-TLS session.  The TLS would
check to see if there was client authentication associated with the session
ticket and either a) say that the ticket is not valid or b) validates the
ticket and then does a post handshake client authentication for the client
certificate.  It could then issue a new ticket which contained the client
authentication information obtained in TLS.

A similar analysis can be done for all EAP methods.  The session ticket only
has the information that is discovered by TLS and as such any new TLS
session that is created needs to look a the client authentication that was
done when the ticket was issued.

Jim


> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Thursday, March 7, 2019 5:41 PM
> To: Arran Cudbard-Bell 
> Cc: EMU WG 
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
> 
> On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell
>  wrote:
> > 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session
> tickets in TLS 1.3.'
> >
> > I know it's pedantic, but RFC 8446 obsoletes RFC 5077.
> 
>   Sure.
> 
> >>  Any authorization applied during resumption MUST be done using the
> >> cached data,
> >
> > 'or data resolved or obtained using that cached data.'
> >
> > authorization doesn't need to performed in a sandboxed environment with
> only the cached data.
> 
>   True.  It can be used to look up data in a database, or to do something
else.
> 
> > Cross resumption between VPNs and Wired/Wireless infrastructure could
> be a big issue.
> > It might be worth mentioning that explicitly as I think it'll be a blind
spot for
> implementors.
> >
> > Out of the box, if someone used our EAP server implementation for
> > authenticating VPN users and wired/wireless users, we would allow
> > cross resumption, because the EAP server doesn't allocate session
tickets
> based in different contexts by default.
> 
>   That depends on the deployment, too.
> 
>   To be strictly technical, an HTTPS server and EAP server could share TLS
> session tickets.  It would then be possible for users to authenticate via
> HTTPS, and "resume" via EAP-TLS.
> 
>   The only reason resumption works across media types in EAP is that
there's
> generally one common EAP server for all media types.  If instead there are
> multiple EAP servers, or the TLS implementations don't share data, then
> cross-method resumption won't work.
> 
> >>  When EAP servers make policy decisions based on unauthenticated
> >> information, they MUST then add that information to the cached data
> >
> > maybe 'then it MUST be used in combination with the cached data
> described above'
> 
>   Perhaps.
> 
> > Took a couple of readings to understand exactly what you meant there.
> 
>   It's a difficult subject to explain properly.
> 
> > The cached data isn't being updated, but it's being used together with
> > the unauthenticated information, right?
> 
>   Yes.
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

[Jim Schaad]

This message had my response in the wrong place.  I was responding to Tim's 
comments and not to Alan's comments.  I completely agree with Alan that this 
information needs to be fed back to the NAS and not rely on what the client 
starts out saying.

> -Original Message-
> From: Emu  On Behalf Of Jim Schaad
> Sent: Wednesday, November 14, 2018 10:35 AM
> To: 'Cappalli, Tim (Aruba Security)' ; 'Alan DeKok'
> 
> Cc: emu@ietf.org; 'John Mattsson' 
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
> tls13-03.txt
> 
> 
> 
> > -Original Message-
> > From: Emu  On Behalf Of Cappalli, Tim (Aruba
> > Security)
> > Sent: Wednesday, November 14, 2018 6:49 AM
> > To: Alan DeKok 
> > Cc: emu@ietf.org; John Mattsson 
> > Subject: Re: [Emu] FW: New Version Notification for
> > draft-ietf-emu-eap- tls13-03.txt
> >
> > The question was asked about making it anonymous NAI mandatory in the
> > Identity Response. That is what my comments were targeted to.
> >
> > In terms of infrastructure, logging into a wireless controller, switch
> > or NMS and seeing hundreds of "anonym...@enterprise.co" makes an
> > administrator's life miserable. Most folks in a large enterprise
> > responsible for troubleshooting end user access do not have access to the
> EAP server.
> >
> > The only way to provide the real identity back to the NAS would be
> > sending it back as the IETF User-Name in the Access-Accept with the
> > assumption that the NAS would honor it.
> 
> My first response to this would be - what happens as an attacker I supply one
> name in the outer and validate using a different (and correct) inner name.
> This is going to make the administrator's life miserable since they are going
> to be looking at the wrong name and not have any ability to recognize that
> that is the problem.
> 
> Jim
> 
> >
> > tim
> >
> > On 11/14/18, 8:38 AM, "Alan DeKok" 
> wrote:
> >
> >
> >
> > On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security)
> >  wrote:
> >
> > >
> >
> > > Making it mandatory to use an anonymous NAI will be a huge issue
> > in enterprise where the infrastructure, device and enterprise identity
> > is owned by the enterprise. There is no proxy or third party provider.
> >
> >
> >
> >  I don't see that in Section 2.1.4.  It says:
> >
> >
> >
> >... a client supporting TLS 1.3 MUST NOT send its
> >
> >username in cleartext in the Identity Response.  It is
> > RECOMMENDED to
> >
> >use anonymous NAIs, but other solutions where the username is
> >
> >encrypted MAY be used.
> >
> >
> >
> >   So username *hiding* his mandatory.  But the method is left to
> > the implementation.
> >
> >
> >
> > > Seeing "anonym...@enterprise.com" across all network
> > infrastructure is not going to be acceptable.
> >
> >
> >
> >   In what context will you "see" that across all network infrastructure?
> >
> >
> >
> >   Since this is the enterprise, you control your own RADIUS
> > server.  You can associate the *inner* identity with the users
> > session.  There is no requirement that you only look at the outer
> > identity for tracking user sessions.  This tying of inner / outer
> > identities is common in ISP and enterprise environments.
> >
> >
> >
> >   In the absence of specific reasons behind this statement, I just
> > don't see how anonymous identities are a problem for anyone, anywhere.
> >
> >
> >
> >   If I had to guess, I'd say that the problem comes from *other*
> > devices on the network.  Devices that snoop EAP, but aren't involved
> > in the actual authentication.  The solution there would be to have the
> > local RADIUS server talk to the local snooping device.  Or, the local
> > snooping device looks at MAC addresses instead of EAP identities.  And
> > then uses the RADIUS DB to correlate MAC address to EAP inner identity.
> >
> >
> >
> > > Why not provide a flag that can be passed in the EAP exchange
> > from the supplicant that enables this behavior so users with full
> > control of their device can use this while enterprise or other use
> > cases that require real identity can configure the supplicant to provide a
> different flag?
> >
> >
> >
> >   Given the horrific nature of implementations and
> > inter-operability, I would oppose yet another point of negotiation.
> > It does not add anything IMHO.  And, it makes implementations and inter-
> operability more complex.
> >
> >
> >
> >   Alan DeKok.
> >
> >
> >
> >
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis

[Jim Schaad]

> -Original Message-
> From: Jari Arkko 
> Sent: Wednesday, November 14, 2018 9:47 AM
> To: Jim Schaad 
> Cc: emu@ietf.org; draft-ietf-emu-rfc5448...@ietf.org
> Subject: Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis
> 
> Thanks for your review, Jim.
> 
> > Any issues that I have here might have already been raised and discussed.
> If so just not that and ignore.
> >
> > Section 3.4 - I am curious why you did not make the hash function a
> property of the HKDF function rather than making it a hard coded value.  I
> would kind of expect that section 3.4 (top) and 3.4.1 would be part of the
> KDF function and not stand alone values.   I am not sure if I think that the
> MAC function should also be defined by this as well.  Doing so would allow
> for an easier jump to SHA3 at a later date if needed.
> >
> > Other than that question the document is clear and the EMU parts seem to
> be correct.  I cannot comment on any of the 3GPP parts.
> 
> Good questions.
> 
> I’m not sure I can entirely answer what the thinking was without going
> through past correspondence; I can’t recall. I’m not sure we were clever
> enough to do what you suggested back then, this could be just a missed
> opportunity. But I could be missing some reason why we didn’t do it.
> 
> Thinking about it now, tying AT_MAC, AT_CHECKCODE, PRF, *and* KDF all to
> AT_KDF value would make sense. However, that would seem like a change to
> a design that was in RFC 5448, and if we change that there will be two
> questions: (a) can we do it and (b) should we do it?
> 
> It seems like that answer to the first question is that we can, because even 
> if
> (e.g.) AT_MAC appears before KDF negotiation is completed, if the peer does
> not want to do the requested KDF/hash functions, it will in any case propose
> new KDF before running the actual crypto.
> 
> The answer to the second question may be trickier. If I’m right above, we
> could make a change without requiring any new code lines in existing
> implementations, but it would still be a change. And if we made that kind of
> change, there’d probably be a wish from 3GPP to review that change as well.
> And possibly a request to discuss the change, or do further development. This
> is what makes me hesitate a bit.
> 
> But I’ll also observe that a future document that introduces SHA-16384 could
> certainly define all this anyway; peers that can not do the KDF/hash that is
> proposed would suggested the older algorithms instead, and crypto would
> only run once both parties agree on what is negotiated in AT_KDF. I’ll think
> about this some more, but this seems at the moment preferable to me.

Jari,

All of what you said makes complete sense to me.  As I said I was asking for 
curiosity value and not because I thought this should hold up the document from 
progressing.

The one change I think you might consider doing is to put a "future version 
note" into the document with the suggestion that this be considered.  If the 
reason was just oversight I would hate for the same oversight to be made later 
and a new EAP method be registered.

Jim

> 
> Jari


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

Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

[Jim Schaad]

> -Original Message-
> From: Emu  On Behalf Of Cappalli, Tim (Aruba
> Security)
> Sent: Wednesday, November 14, 2018 6:49 AM
> To: Alan DeKok 
> Cc: emu@ietf.org; John Mattsson 
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
> tls13-03.txt
> 
> The question was asked about making it anonymous NAI mandatory in the
> Identity Response. That is what my comments were targeted to.
> 
> In terms of infrastructure, logging into a wireless controller, switch or NMS
> and seeing hundreds of "anonym...@enterprise.co" makes an
> administrator's life miserable. Most folks in a large enterprise responsible 
> for
> troubleshooting end user access do not have access to the EAP server.
> 
> The only way to provide the real identity back to the NAS would be sending it
> back as the IETF User-Name in the Access-Accept with the assumption that
> the NAS would honor it.

My first response to this would be - what happens as an attacker I supply one 
name in the outer and validate using a different (and correct) inner name.  
This is going to make the administrator's life miserable since they are going 
to be looking at the wrong name and not have any ability to recognize that that 
is the problem.

Jim

> 
> tim
> 
> On 11/14/18, 8:38 AM, "Alan DeKok"  wrote:
> 
> 
> 
> On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security)
>  wrote:
> 
> >
> 
> > Making it mandatory to use an anonymous NAI will be a huge issue in
> enterprise where the infrastructure, device and enterprise identity is owned
> by the enterprise. There is no proxy or third party provider.
> 
> 
> 
>  I don't see that in Section 2.1.4.  It says:
> 
> 
> 
>... a client supporting TLS 1.3 MUST NOT send its
> 
>username in cleartext in the Identity Response.  It is RECOMMENDED to
> 
>use anonymous NAIs, but other solutions where the username is
> 
>encrypted MAY be used.
> 
> 
> 
>   So username *hiding* his mandatory.  But the method is left to the
> implementation.
> 
> 
> 
> > Seeing "anonym...@enterprise.com" across all network infrastructure is
> not going to be acceptable.
> 
> 
> 
>   In what context will you "see" that across all network infrastructure?
> 
> 
> 
>   Since this is the enterprise, you control your own RADIUS server.  You 
> can
> associate the *inner* identity with the users session.  There is no
> requirement that you only look at the outer identity for tracking user
> sessions.  This tying of inner / outer identities is common in ISP and
> enterprise environments.
> 
> 
> 
>   In the absence of specific reasons behind this statement, I just don't 
> see
> how anonymous identities are a problem for anyone, anywhere.
> 
> 
> 
>   If I had to guess, I'd say that the problem comes from *other* devices 
> on
> the network.  Devices that snoop EAP, but aren't involved in the actual
> authentication.  The solution there would be to have the local RADIUS server
> talk to the local snooping device.  Or, the local snooping device looks at MAC
> addresses instead of EAP identities.  And then uses the RADIUS DB to
> correlate MAC address to EAP inner identity.
> 
> 
> 
> > Why not provide a flag that can be passed in the EAP exchange from the
> supplicant that enables this behavior so users with full control of their 
> device
> can use this while enterprise or other use cases that require real identity 
> can
> configure the supplicant to provide a different flag?
> 
> 
> 
>   Given the horrific nature of implementations and inter-operability, I
> would oppose yet another point of negotiation.  It does not add anything
> IMHO.  And, it makes implementations and inter-operability more complex.
> 
> 
> 
>   Alan DeKok.
> 
> 
> 
> 


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

Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis

[Jim Schaad]

Any issues that I have here might have already been raised and discussed.  If 
so just not that and ignore.

Section 3.4 - I am curious why you did not make the hash function a property of 
the HKDF function rather than making it a hard coded value.  I would kind of 
expect that section 3.4 (top) and 3.4.1 would be part of the KDF function and 
not stand alone values.   I am not sure if I think that the MAC function should 
also be defined by this as well.  Doing so would allow for an easier jump to 
SHA3 at a later date if needed.   

Other than that question the document is clear and the EMU parts seem to be 
correct.  I cannot comment on any of the 3GPP parts.

Jim


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

Re: [Emu] Call for adoption of draft-arkko-eap-rfc5448bis-01.txt

[Jim Schaad]

It is on my long list of documents to review

> -Original Message-
> From: Emu  On Behalf Of Mohit Sethi
> Sent: Monday, May 28, 2018 11:54 PM
> To: Alan DeKok ; Joseph Salowey
> 
> Cc: emu@ietf.org
> Subject: Re: [Emu] Call for adoption of draft-arkko-eap-rfc5448bis-01.txt
> 
> I will review it as well.
> 
> --Mohit
> 
> 
> On 05/28/2018 11:59 PM, Alan DeKok wrote:
> >I will review it.
> >
> >> On May 28, 2018, at 4:58 PM, Joseph Salowey  wrote:
> >>
> >> I didn't see any objections, but I want to make sure we have some folks
> willing to review the draft.  Please respond to this thread if you would
be
> willing to review the draft.
> >>
> >> Thanks,
> >>
> >> Joe
> >>
> >> On Sun, Apr 1, 2018 at 4:03 PM, Joseph Salowey 
> wrote:
> >> At the IETF 101 EMU meeting in London there was good support for
> adopting draft-arkko-eap-rfc5448bis-01.txt as a working group item.  This
is a
> call for adoption of this draft as a working group item.  If you have an
> objection or concern about adopting this draft please respond to the list
by
> April 14, 2018.
> >>
> >> Cheers,
> >>
> >> Joe
> >>
> >>
> >>
> >>
> >> ___
> >> Emu mailing list
> >> Emu@ietf.org
> >> https://www.ietf.org/mailman/listinfo/emu
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] EAP-TLS with large certificates

[Jim Schaad]

There are already a couple of things in TLS 1.3 that can be used to address 
some of these issues

 

From: Emu [mailto:emu-boun...@ietf.org] On Behalf Of Bernard Aboba
Sent: Friday, January 19, 2018 9:46 AM
To: emu@ietf.org
Subject: Re: [Emu] EAP-TLS with large certificates

 

Alan DeKok said: 

 

" It may also be worth re-examining EAP-TLS. Modern certificates are getting 
large, and people are using longer certificate chains. The result can be that 
initial EAP-TLS authentication takes many packets. This has issues not just for 
latency, but also access point implementations. Most implementations will drop 
an EAP session if it hasn't finished after 40-50 packets.

  I've seen people run into this issue with large certificates and long 
certificate chains. It would be good to find a way to allow this use-case."

 

[BA] I have encountered this problem in a number of situations, particularly in 
enterprise deployments with several levels of intermediate CAs.  Since the 
certificate hierarchy is relatively static, this seems like a problem that 
could be addressed via caching. 

 

[JLS] There is already a way to say that you have a specific set of 
certificates and CRLs  in RFC 7924 – TLS Cached Information Extension.  There 
is also a new TLS 1.3 extension that is being looked at for compressions of 
certificates.  This seems to get some decent compressions, but it is still up 
in the air just how good it is going to be.

 

For example, if client A has previously authenticated to server B and has 
cached the certificate chain, why does it need to be transmitted again? 
Similarly, if server B has already cached certificates from intermediate CAs, 
why does the client need to transmit that information again? 

 

Seems like this could be addressed by a small extension to TLS. 

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

Re: [Emu] salted EAP-pwd

[Jim Schaad]

I can see two problems right off the bat.

1.  It does not allow me to use a different salted method for different
people so I can upgrade by salt function piecemeal.

2.  It does not allow me to do both SASLprep and salting on the same
password.

Jim


-Original Message-
From: Emu [mailto:emu-boun...@ietf.org] On Behalf Of Dan Harkins
Sent: Tuesday, September 30, 2014 12:02 PM
To: emu@ietf.org
Subject: [Emu] salted EAP-pwd


  Hello EMU,

  I've had requests to add support for salted password databases to EAP-pwd.
A newly posted draft does just that:

   http://tools.ietf.org/html/draft-harkins-salted-eap-pwd-00

  Please take a look and comment.

  regards,

  Dan.



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

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

Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT)

[Jim Schaad]

Looking for a piece of information.

Are there cases in TLS before 1.3 where the PRF and the MAC are not inferred
from the cipher suite that was negotiated?

I think it would be surprising if the cipher suite was not obtainable.  The
question would be if these are ever independent of the suite there could be
a problem. 

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Joseph Salowey (jsalowey)
 Sent: Thursday, November 07, 2013 4:38 PM
 To: emu@ietf.org
 Cc: draft-ietf-emu-eap-tunnel-met...@tools.ietf.org; emu-
 cha...@tools.ietf.org; Stephen Farrell
 Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-
 method-07: (with DISCUSS and COMMENT)
 
 I'd like to hear from the working group on this.
 
 I think Stephen is raising a fair point that trying to use the TLS PRF in
this way
 creates a very tight binding between a TLS implementation and a TEAP
 implementation that may make implementations difficult depending upon the
 interfaces provided by a TLS library.   I think its very possible that
some
 libraries would not provide this information.   If you think reusing the
TLS PRF
 is a good idea then please state why.   If you think we should define a
PRF
 please indicate what approach you think we should take.
 
 Thanks,
 
 Joe
 
 
 On Nov 7, 2013, at 4:15 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
  wrote:
 
 
  Hi Joe,
 
  On 10/04/2013 05:58 PM, Joseph Salowey (jsalowey) wrote:
 
 
  Apologies for the glacial response.
 
  Your suggestion for point 3 looks fine. Point 1 is already a comment.
 
  But point 2 needs a bit more discussion.
 
  The concern is that you're doing a layering violation and we know that
  the layer below (TLS) is changing, possibly in a way that'd impact on
  this. Why not just pick a KDF?
 
  S.
 
  On Oct 4, 2013, at 7:07 AM, Stephen Farrell
  stephen.farr...@cs.tcd.ie
  wrote:
 
 
  Hi Joe,
 
  Sorry for the slow response and if I've missed anything...
 
  On 09/25/2013 07:21 AM, Joseph Salowey (jsalowey) wrote:
 
  On Aug 14, 2013, at 10:58 AM, Stephen Farrell
  stephen.farr...@cs.tcd.ie wrote:
 
  Stephen Farrell has entered the following ballot position for
  draft-ietf-emu-eap-tunnel-method-07: Discuss
 
  When responding, please keep the subject line intact and reply to
  all email addresses included in the To and CC lines. (Feel free to
  cut this introductory paragraph, however.)
 
 
  Please refer to
  http://www.ietf.org/iesg/statement/discuss-criteria.html for more
  information about IESG DISCUSS and COMMENT positions.
 
 
  The document, along with other ballot positions, can be found
  here:
  http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
 
 
 
  --
  
 
 
  DISCUSS:
  --
  
 
 
 
 
  These discuss points are more questions I'd really like
  answered than blocking points (depending on the answers I guess:-)
  but I expect should be easily resolved.
 
  (1) 3.4: when x.500 names or SubjectAltNames are exported is it
  clear how those are formatted? Maybe a pointer to where that's
  defined would be good in case implementers get it wrong. You might
  also want to warn here (or somewhere) about names that contain a
  null byte in case that attack is used e.g. with a TLS server cert
  subject name like CN=www.paypal.com\0.badguy.com Even though
  that's really a PKI failure, not detecting it here would be bad
  too.
 
 
  [Joe]  We could add a note about the null, is there some text in an
  existing document we could reuse?
 
  That one's a comment now.
 
 
  (2) 5.2, at the end: this adds a dependency on the TLS-PRF.  I
  don't suppose TLS1.3 will be a big enough change for that to be a
  problem, but what if it was? E.g. if someone convinced the TLS WG
  to use IKE instead? Do you really need the same PRF or could you
  pick one for TEAP and remove the dependency? Same question for the
  MAC in 5.3.
 
 
  [Joe] We chose to have the dependence so we would rely on the same
  crypto-algorithms as TLS so our crypto agility would track with TLS.
  We figured TLS would track advances in cryptography better than EMU.
 
  Well, two things - if TLS 1.3 makes changes then that could mean
  that this has to run over TLS 1.2 or earlier to get interop and that
  seems like a bad plan.
  And secondly, is there really a good API to see what PRF has been
  used by TLS for a given session in common TLS implementations?
 
  [Joe] The TLS 1.2 the PRF is no longer fixed and it depends upon the
 ciphersuite.  In most TLS implementations I'm aware of you can find the
 ciphersuite.  While this does not directly give you the PRF it does allow
you to
 determine what it is.  THis does mean that a TEAP implementation would
need
 to have a mapping between ciphersuite and PRF.   THis means that if a new
 ciphersuite is defined TEAP implementations would need to 

Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method

[Jim Schaad]

 -Original Message-
 From: Sam Hartman [mailto:hartmans-i...@mit.edu]
 Sent: Monday, March 04, 2013 6:19 PM
 To: Joseph Salowey (jsalowey)
 Cc: Sam Hartman; Jim Schaad; emu@ietf.org
 Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
 
  Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com
 writes:
 
 [Joe] THis is a reasonable request.  We'll need to make sure there is no
 ambiguity in the use of the empty message.   Should this be covered in RFC
 6677?
 
 RFC 6677 doesn't talk about how you decide you're going to do channel
 binding.  I had mostly assumed you'd throw it in with some other message I
 guess, although once you consider crypto binding that gets more complex
 because you want CB after crypto binding some of the time.
 
 Note that I'm not requesting any specific behavior.  I'm simply requesting
 that you document either that a server cannot request CB (must start with
 client) or document how a server requests cb.
 
 The message defined in RFC 6677 always has a code, so an empty message is
 clearly not a 6677 message.

I agree - this is behavior that is described in this document and not in RFC
6677 - this is a how do you do it not a what is included type question.

Jim


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

[Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2

[Jim Schaad]

I have been doing my best not to send this message but it has finally
slipped out.

 

I keep wondering if we need to do something much more explicit in terms of
both identifying and purposing the certificates that are being used for this
method.

 

Question #1 - Do we expect that the client certificates would only be used
for this purpose and not for general purpose TLS client authentication?  I
would be shocked if this was not true for the server certificates.  If so
does this mean that we should define an EKU for the purpose of doing EAP
Tunnel Method (allow it to be used for all of the previous and future
versions thus being generic)?

 

Question #2 - Do we want to try and solve the question Sam has raised about
naming of entities in certificates.  This would mean defining a new
OtherName extension to PKIX for the purpose of placing NAIs into
certificates.  This would allow for an NAI of the form @realm to be placed
in a server certificate to define that it is the EAP server for the realm.
This does assume that there will not be two different servers which are
disjoint servicing the same realm but that would be a very unusual case.

 

Jim

 

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

Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method

[Jim Schaad]

Sam,

My responses are inline.  May not agree with the authors however.

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Sam Hartman
 Sent: Saturday, February 23, 2013 5:47 PM
 To: emu@ietf.org
 Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
 
 
 
 First, the document has been improved a lot in its clarity since the last
time I
 read it. I'd really like to thank the editors, Jim and everyone else who
gave
 comments for some excellent work.
 
 
 TEAP is by far the best EAP method I've ever reviewed, and I think
security of
 EAP conversations would be significantly improved if people implement and
 deploy TEAP.
 
 Section 3.4:
 
 Does the server_id depend on whether the identifier is actually
 authenticated?
 That is, let's say the server is using a certificate but the client has no
way to
 validate the certificate back to a trust anchor.
 However, the client uses some strong inner method and EMSK-based crypto
 binding to verify the server.
 Does the  subject from the server cert make its way into the server ID in
this
 case?
 
 Is it important that implementations get binary identical strings for
server_id
 on both sides of the conversation?
 I think the text in 3.4 is sufficient that you'd get the right security
properties
 out of the identity, but I suspect different implementations could get
slightly
 different encoding etc.
 I have never used peer id, server id or session id, so I'm not sure if
anyone
 cares about that.

I would expect that the id from the certificate would be returned if the
inner method provided mutual authentication and the crypto bindings were
successful.  At that point one would have a statement about the certificate
that says it matches that of any server id stated inside of the tunnel.  The
certificate would be the one presented by the certificate - could not change
without TLS failing.  The channel binding would give you validation of the
tunnel and mutual auth would give you validation of the server.

I don't know what it would be to have binary identical strings on both
sides.  Only the peer side would get server ids and only the server side
would get peer ids.  

As with you I have never used the ids - so I would not know what they are
used for in general either.

 3.5:
 
 old:
   tls_unique = tls_unique for the phase 1 outer tunnel as defined by
 [RFC5929].
 
 new:
   tls_unique = tls_unique for the phase 1 outer tunnel at the
   beginning of phase 2 as defined by  section 3.1 of [RFC5929].
 
 
 rationale: The quantity described in section 3.1 of rfc 5929 can change
when
 there is TLS renegotiation.
 This should avoid that.
 Section 3.8-3.10:

This is a reasonable change.

 All of these sections  involve peer services in the terms of
draft-ietf-abfabf-
 emu-crypto-bind.
 I believe the advice in section 4.2 of  draft-ietf-emu-crypto-bind applies
quite
 strongly here.
 In particular, the peer MUST track whether it has authenticated the
server.
 
 There's text repeated at various points in the TEAP spec that tries to say
this,
 including some text in 3.8 and a hint at 3.10.
 
 I think this needs to be more unified.
 In particular I propose that:
 
 * A new section 3.11 titled Mutual Authentication for Peer Services be
   added:
 
 
 Several TEAP services including server unauthenticated provisioning, PAC
 provisioning, certificate provisioning and channel binding depend on the
peer
 trusting the TEAP server.  Peers need to mutually authenticate the server
 before these peer services are used.
 
 TEAP peers MUST track whether mutual authentication has taken place.
 Mutual authentication results if the peer trusts the provided server
 certificate belongs to the server; typically this involves both validating
the
 certificate to a trust anchor andconfirming the entity named by the
certificate
 is the intended server. Mutual authentication also results when the
 procedures of section 3.3 are used to resume a session in which the server
 was previously mutually authenticated. Alternatively, if an inner EAP
method
 providing mutual authentication and an Extended Master Session Key
 (EMSK) is executed and cryptographic binding with the EMSK compound
 MAC present (section 4.2.13), then the session is mutually authenticated
and
 peer services can be used. TEAP implementations SHOULD Not use peer
 services by default unless the session is mutually authenticated. TEAP
 implementations SHOULD have a configuration where authentication fails if
 mutual authentication cannot be achieved.
 
 An additional complication arises when a tunnel method authenticates
 multiple parties such as authenticating both the peer machine and the peer
 user to the EAP server. Depending on how mutual authentication is
 achieved, only some of these parties may have confidence in it. For
example
 if a strong shared secret is used to mutually authenticate the user and
the
 EAP server, the machine may not have confidence 

Re: [Emu] crypto binding: why did I want a survey of methods

[Jim Schaad]

Sam,

I think it would be useful to do a partial survey and just say that it is a
partial survey.  In part I think this would be useful just so that the
points that you feel are important for the CB are highlighted.  I would be
perfectly  willing for such a survey to cover only a couple of the most
recent EAP methods with a statement that it is a partial survey and stating
why.

However I can also understand why you would not want to do this because I
would be afraid that the IESG would want to know why it is not a more
complete survey.

Jim


 -Original Message-
 From: Sam Hartman [mailto:hartmans-i...@mit.edu]
 Sent: Sunday, February 24, 2013 10:56 AM
 To: Jim Schaad
 Cc: 'Sam Hartman'; emu@ietf.org; draft-ietf-emu-crypto-
 bind...@tools.ietf.org
 Subject: Re: [Emu] crypto binding: why did I want a survey of methods
 
 Hi.  I've included a survey of tunnel methods that have made it to RFC and
 TEAP.  It's quite possible that people want to cover more tunnel methods
in
 the summary (LEAP, PEAP, EAP-TTLS v1).
 People who want to supply text are welcome to do so.
 
 After looking at it, I don't feel comfortable volunteering to do the inner
 method summary.  For the more modern methods the answer tends to
 always be yeah, nothing wrong there.  Now, the method itself may be
 weaker than you'd like, but the mutual authentication and key handling
 tends not to be of particular note.  At least that seems to be true for
the
 PAKE methods, for GPSK and for revised AKA.  Note that is an initial
guess, I
 don't have enough confidence in that statement to go write it down in the
 draft, and I'm not convinced it's all that useful.
 
 As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets
 more complex. EAP-SIM has some significant challenges with mutual
 authentication and I think with key generation. Being able to summary more
 than what is in the eap-sim security considerations section would involve
a
 lot more operational knowledge than I have.
 
 I don't even know where to find documentation for EAP-MSCHAPv2. I'm
 strongly suspecting it's got problems, given its age and attachment to
 md4 and rc4. However, the mschapv2 PPP extensions got away with a one
 sentence security considerations section, so it's definitely not just
 summarizing already current security analysis.
 
 So, I don't think what I could do with inner method surveys is going to be
 helpful enough to write up.
 
 I'm dropping that section but if text emerges within the WG I'd be happy
to
 include it.
 I think though that we're doing a good enough job with security
 considerations sections for post-RFC 3748 EAp inner methods that we don't
 need such a summary.

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

[Emu] FW: Last call comments on emu-eap-tunnel-method-05

[Jim Schaad]

 -Original Message-
 From: Jim Schaad [mailto:jim...@augustcellars.com]
 Sent: Thursday, February 21, 2013 1:10 PM
 To: draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
 Cc: emu@ietf.org
 Subject: Last call comments on emu-eap-tunnel-method-05
 
 I have no comments that I would consider to be blocking.  There are couple
 of issues that should be considered to be dealt with in the last call.
 
 Jim
 
 
 
 1.  Lower case must/may in the document.  There are disputes about the
role
 of a lower case must in a document.  Some people consider it to be an RFC
 2119 usage and some people don't.  If it is then these all need to be
looked
 at, if it doesn't then I would suggest putting in text as part of the
RFC2119
 boiler plate to say that lower case versions of these words have their
natural
 language meaning.
 
 
 2.  I am not completely clear on this, but don't know if it needs to be
clarified.
 Server and client rune one inner EAP method.
 Server sends Crypto-Binding TLV and Result TLV Client sends Crypto-Binding
 TLV, Request-Action TLV [Negotiate EAP] Server sends EAP-Payload [EAP
 start method] Does the server also needs to send an Intermediate-Result
 TLV per section 3.3.1?
  Note - in section 3.3.3 - it would appear that there is a may
 recommendation that the server actually send Crypt-Binding TLV,
 Intermediate-Result TLV, Result TLV thus making the problem not a problem.
 However this is not required behavior.
 
 3.  Not completely sure the second to last paragraph in 3.3 is correct.
Should
 the server return the EAP success or failure based on the peer's result
TLV or
 the peer's request-action tlv?  I think that either could be a correct
answer I
 just want to verify that the text presented is correct.
 
 4.  Last chance to change our minds and allocate an extra flag in section
4.2.1
 just in case we needed it.  I have no idea which is going to be the more
scarce
 resource.  But only one reserve flag might be an issue.
 
 5.  It is technically incorrect to say that the TLV Type is two octets
(section
 4.2.2).  I don't know that there is any reason to correct this as it is
essentially
 correct.  Just a we need to be sure we don't want to fix it.  (Note: text
is
 different in section 4.2.2)
 
 6.  section 4.2.13 - I think that the received version number is supposed
to
 say set to the TEAP version number received not the EAP version
 number
 
 7.  section 4.3 s/multiple multiple Basic/multiple Basic/
 
 8.  Section 5.2  There are two possible confusions that could result in
the
 computation of the text string for the IMSK
a) It is possible that the string \0 could be misinterpreted.   This
could be
 stated as 0x00.
b) It is possible that the 64 could be misinterpreted as being longer
than a
 byte and thus could be stated as 0x40.  (Oops just looked at the
referenced
 document and it is 0x00 0x40).
Not clear if this really needs to be changed.
 
 9.  Section 5.2 - s/thendoesn/?/
 
 
 
 
 


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

Re: [Emu] TEAP Comments

[Jim Schaad]

Expanding on the issues so that you have full descriptions of the problem
from the last message

1.  When either an EMSK or MSK is not present in the Crypto-Binding TLV,
there is no way to indicate this.  At the f2f it was said that this was
going to be by setting it to all zeros.  If this is the case, then it does
need to be noted that there is a 1 in 2^n chance that it will signal the
wrong thing leading to an error in binding being generated.  It might be
better to steal bits from the Sub-Type octet instead.

2.  I find that I have probably not correctly understood when the S bit is
set.   I have been setting the S bit on all fragments (but not fragment
responses) of the original Start request and Start response.  I have since
found text that says it is only sent from the server to the peer.  It would
be nice to have the one direction comment in the description of the flags as
well (section 4.1)

3.  I would like to have the description of the L bit in section 4.1
expanded to state the following:
  - It MUST be present for the first fragment of a fragmented message
  - It MUST NOT be present for any other message

The first can be found in section 3.7 (if you hunt) but the second is not
stated anywhere

4.  I would like to have the description of the O bit in section 4.1
expanded to state the following:
 - It MUST be present only in the initial request and response messages.
 - If the initial message is fragmented, then it MUST be present only on the
first fragment.

5.  I don't think point 3 below needs expansion, but I may be too close to
it.  If you disagree please let me know.

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Jim Schaad
 Sent: Wednesday, November 07, 2012 4:48 PM
 To: emu@ietf.org
 Subject: [Emu] TEAP Comments
 
 I just wanted to make sure that the mail list had at least the basics of
what I
 mentioned in the f2f today
 
 1.  The document does not appear to have an indicator that the EMSK was or
 was not used to generate a confirmation value.  I have not done a final
check
 that this is true but I did try and find it a couple of times
 
 2.  The flags on the outer packet need to be defined a bit better.
a)  is the S bit set only on the first fragment of the first message or
on all
 fragments of the first message
b)  are the two length bits set only on the first message in  a
fragment
 sequence or can they be on any of the messages in a fragment sequence
 (but the values must then be the same in all fragment messages)
c)  Can the O bit be set only in the first piece of a fragment, or
could it be in
 the last one without being in any previous one
d)  Should the L bit never be set on a non-fragmented message since it
is
 redundant
 
 3.  There needs to be a signaling mechanism when running inner EAP
 messages to say that
   a) that this is a reliable transport and therefore there should be
no-retries
   b) If a packet is dropped on the floor by somebody, then some type of
 signaling mechanism needs to be created to signal this to the other party.
 Also there should be text saying that re-sending the message does not
 necessarily make sense as the packet would probably just be re-dropped
 again
   c) There needs to be some type of policy on the server for what to do
for
 either failing or continuing a validation - for example should a new EAP
 method be tried in this case.
 
 Jim
 
 
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu

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

[Emu] TEAP Comments

[Jim Schaad]

I just wanted to make sure that the mail list had at least the basics of
what I mentioned in the f2f today

1.  The document does not appear to have an indicator that the EMSK was or
was not used to generate a confirmation value.  I have not done a final
check that this is true but I did try and find it a couple of times

2.  The flags on the outer packet need to be defined a bit better.
   a)  is the S bit set only on the first fragment of the first message or
on all fragments of the first message
   b)  are the two length bits set only on the first message in  a fragment
sequence or can they be on any of the messages in a fragment sequence (but
the values must then be the same in all fragment messages)
   c)  Can the O bit be set only in the first piece of a fragment, or could
it be in the last one without being in any previous one
   d)  Should the L bit never be set on a non-fragmented message since it is
redundant

3.  There needs to be a signaling mechanism when running inner EAP messages
to say that
  a) that this is a reliable transport and therefore there should be
no-retries
  b) If a packet is dropped on the floor by somebody, then some type of
signaling mechanism needs to be created to signal this to the other party.
Also there should be text saying that re-sending the message does not
necessarily make sense as the packet would probably just be re-dropped again
  c) There needs to be some type of policy on the server for what to do for
either failing or continuing a validation - for example should a new EAP
method be tried in this case.

Jim


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

Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

[Jim Schaad]

I think that picks up all of my current comments.  Looking forward to seeing
the draft update.

 

Jim

 

 

From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] 
Sent: Wednesday, October 10, 2012 11:15 AM
To: Jim Schaad
Cc: emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

 

Jim:

 

Please see comments below inline.

 

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

Re: [Emu] More comments for eap-tunnel-method

[Jim Schaad]

There does not seem to be anything in the TEAP document about the length of
the TLS data.   Are you suggesting that one should crack the TLS data blob
to find the length of that data blob?

Jim


 -Original Message-
 From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
 Sent: Tuesday, October 09, 2012 11:43 AM
 To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
 met...@tools.ietf.org
 Subject: Re: [Emu] More comments for eap-tunnel-method
 
 Jim:
 
 Please see comments inline below.
 
 On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote:
 
 
 
  -Original Message-
  From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
  Sent: Thursday, October 04, 2012 2:56 PM
  To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
  met...@tools.ietf.org
  Subject: Re: [Emu] More comments for eap-tunnel-method
 
  Jim:
 
  Thanks for the review. Please see my comments below.
 
  On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote:
 
  1.  Should the Message Length field be present if the TLS Data field
  is absent?
  [HZ] According to the text in the draft, the message length field
  should
 only
  be present if the L bit is set, usually for fragmented packets. In
  those
 cases,
  the TLS data field will be present, not absent. The only case TLS
  data
 will be
  absent is when empty TEAP packet it is used to
   indicate TEAP acknowledgement for either a fragmented message,
   a TLS Alert message or a TLS Finished message. So the
  message
 length
  field is not needed. We can clarify that in the draft.
 
 
 [JLS]  I am not clear - are you saying that the first sever message
 sent with just TLVs cannot be fragmented?
 [HZ] No, they can be fragmented. However, currently, Outer TLVs are only
 allowed in the first 2 messages in TEAP exchanges, 1st server to peer with
 TEAP start, and 2nd message client to server with Client_hello. It is
unlikely
 the first server message will have lots of outer TLVs that needs the
 fragmentation (only one or two outer TLV is being defined so far). The 2nd
 message from client to server with client _hello might if the ticket
extension
 is too big, but unlikely.
 
 
 [JLS]  There is a potential issue in the way that the Message Length
 field is described.  For finding the location of the Outer TLVs it
 provides the length of the TLS Data field, but the internal description
 says that it gives the length of the message data in the event of a
 fragmented message.
 If the first client response message is both fragmented on length and
 contains TLVs, then the message length field must be the length of the
 TLS data in order to find the Outer TLV data but that means it is not
 the length of all of the fragmented data.  This is not an issue after
 the first pair of messages as the Outer TLVs are no longer allowed at
 that point.
 [HZ] The message length is the total length of the TEAP packet if
fragmented,
 to provide a hint for the peer to allocate the buffer. The start of the
outer
 TLV can be calculated from the EAP message length and length field inside
 the TLS data, not dependent on the Message Length field. The current draft
 text in Section 4.1 Outer TLVs description incorrectly refers to message
 length field, will need to be corrected.
 Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is
one
 type and relatively simple,  it should not be too hard to figure out the
start.
 
 [JLS] I presume that the Length needs to be present only if the message
 is fragmented as a hint to the receiver on the length of the buffer to
 allocate as I don't remember any error checks that the length of the
 message match the re-constructed message from the fragments (and if it
 did then the previous paragraph makes that faulty).  Should there be an
 error check on the message length w/ the length of the re-constructed
 buffer?
 [HZ] I don't know if current TLS implementations do check for that error.
 Message length is only used for a hint. The EAP-TLS RFC doesn't cover that
 either. Thought it did provide more detailed description of the message
 length and L bit description, something we could use for the TEAP draft.
 
 
  
  2.  There is nothing to say which TLVs can and cannot occur in the
  Outer TLVs in any easily findable method.  Either a table or the
  string outer in descriptions would be helpful.  As an example,  does
  the Authority-ID TLV in the outer TLV make sense?
  [HZ] We will add that table.
  
  3.  I have gone through the fragmentation and did an implementation
  rather than just reading it.  The questions that I have on it now
  are slightly different.  Do TLVs need to be on a fragment boundary?
  Or do we just build the entire message, fragment it into convenient
  sizes regardless of the actual content of the message contents and
  sent the pieces across?  If so then the text should probably be
  re-written to be clearer.  Specifically, the message length is not
  useful for allocating the buffer on the first round

Re: [Emu] More comments for eap-tunnel-method

[Jim Schaad]

I would be really against the idea that I needed to crack the TLS data blob
to figure this out.   Either adding a length for the TLS data field, or a
length of the Outer TLV data would be preferable to me.  If you did the
second, then it would only affect processing on the first two messages.

Jim

 -Original Message-
 From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
 Sent: Tuesday, October 09, 2012 12:46 PM
 To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
 met...@tools.ietf.org
 Subject: Re: [Emu] More comments for eap-tunnel-method
 
 That is the current thinking, and the only concrete use case for Outer TLV
 now is in the 1st message from server to peer with no TLS data. I am ok
with
 adding another optional TLS data length field.
 
 On 10/9/12 3:31 PM, Jim Schaad i...@augustcellars.com wrote:
 
 There does not seem to be anything in the TEAP document about the
 length of
 the TLS data.   Are you suggesting that one should crack the TLS data
blob
 to find the length of that data blob?
 
 Jim
 
 
  -Original Message-
  From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
  Sent: Tuesday, October 09, 2012 11:43 AM
  To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
  met...@tools.ietf.org
  Subject: Re: [Emu] More comments for eap-tunnel-method
 
  Jim:
 
  Please see comments inline below.
 
  On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote:
 
  
  
   -Original Message-
   From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
   Sent: Thursday, October 04, 2012 2:56 PM
   To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
   met...@tools.ietf.org
   Subject: Re: [Emu] More comments for eap-tunnel-method
  
   Jim:
  
   Thanks for the review. Please see my comments below.
  
   On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote:
  
   1.  Should the Message Length field be present if the TLS Data
   field is absent?
   [HZ] According to the text in the draft, the message length field
   should
  only
   be present if the L bit is set, usually for fragmented packets. In
   those
  cases,
   the TLS data field will be present, not absent. The only case TLS
   data
  will be
   absent is when empty TEAP packet it is used to
indicate TEAP acknowledgement for either a fragmented
 message,
a TLS Alert message or a TLS Finished message. So the
   message
  length
   field is not needed. We can clarify that in the draft.
  
  
  [JLS]  I am not clear - are you saying that the first sever message
  sent with just TLVs cannot be fragmented?
  [HZ] No, they can be fragmented. However, currently, Outer TLVs are
 only  allowed in the first 2 messages in TEAP exchanges, 1st server to
 peer with  TEAP start, and 2nd message client to server with
 Client_hello. It is
 unlikely
  the first server message will have lots of outer TLVs that needs the
 fragmentation (only one or two outer TLV is being defined so far). The
 2nd  message from client to server with client _hello might if the
 ticket
 extension
  is too big, but unlikely.
 
  
  [JLS]  There is a potential issue in the way that the Message Length
  field is described.  For finding the location of the Outer TLVs it
  provides the length of the TLS Data field, but the internal
  description says that it gives the length of the message data in the
  event of a
  fragmented message.
  If the first client response message is both fragmented on length
  and contains TLVs, then the message length field must be the length
  of the TLS data in order to find the Outer TLV data but that means
  it is not the length of all of the fragmented data.  This is not an
  issue after the first pair of messages as the Outer TLVs are no
  longer allowed at that point.
  [HZ] The message length is the total length of the TEAP packet if
 fragmented,
  to provide a hint for the peer to allocate the buffer. The start of
  the
 outer
  TLV can be calculated from the EAP message length and length field
 inside  the TLS data, not dependent on the Message Length field. The
 current draft  text in Section 4.1 Outer TLVs description incorrectly
 refers to message  length field, will need to be corrected.
  Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS
 data is
 one
  type and relatively simple,  it should not be too hard to figure out
  the
 start.
  
  [JLS] I presume that the Length needs to be present only if the
  message is fragmented as a hint to the receiver on the length of the
  buffer to allocate as I don't remember any error checks that the
  length of the message match the re-constructed message from the
  fragments (and if it did then the previous paragraph makes that
  faulty).  Should there be an error check on the message length w/
  the length of the re-constructed buffer?
  [HZ] I don't know if current TLS implementations do check for that
 error.
  Message length is only used for a hint. The EAP-TLS RFC doesn't cover
 that  either. Thought it did provide more detailed

Re: [Emu] Client Auth with TLS

[Jim Schaad]

Stefan,

Thanks for the input.

For the authors,

Does this need to be documented as a mode of operation for TEAP or are we
going to say that this is not a supported mode?

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Stefan Winter
 Sent: Wednesday, October 03, 2012 11:10 PM
 To: emu@ietf.org
 Subject: Re: [Emu] Client Auth with TLS
 
 Hi,
 
  3.  The client provides the certificate in a protected manner - I had
  a problem at this point because I don't know enough TLS to properly go
  through this scenario, and I could not really read documents while
  driving.  If the encrypted certificate extension was used, then there
  is no issue as the protected certificate would be passed in the
  initial handshake.  However if the client starts the negotiation and
  then restarts it after it is encrypted, I don't know if this occurs
before or
 after the finish message.
  If it starts after the finish method then there is an issue with
  having the server close an anonymous session if the client is then
  going to provide the certificate encrypted.  Help on how this works
would
 be appreciated.
 
 FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client
 credential exchange (for client privacy protection reasons). I didn't ever
see it
 used (anyone?), but it's clearly a foreseen mode of operation. The text
 describing this is in section 2.1.4:
 
 ...In order to avoid disclosing the peer username, an EAP-TLS peer
configured for privacy MUST negotiate a TLS ciphersuite supporting
confidentiality and MUST provide a client certificate list containing
no entries in response to the initial certificate_request from the
EAP-TLS server.
 
An EAP-TLS server supporting privacy MUST NOT treat a certificate
list containing no entries as a terminal condition; instead, it MUST
bring up the TLS session and then send a hello_request.  The
handshake then proceeds normally; the peer sends a client_hello and
the server replies with a server_hello, certificate,
server_key_exchange, certificate_request, server_hello_done, etc.
 
For the calculation of exported keying material (see Section 2.3),
the master_secret derived within the second handshake is used.
 
An EAP-TLS peer supporting privacy MUST provide a certificate list
containing at least one entry in response to the subsequent
certificate_request sent by the server.  If the EAP-TLS server
supporting privacy does not receive a client certificate in response
to the subsequent certificate_request, then it MUST abort the
session.
 
 
 There is a sequence diagram shortly afterwards which shows clearly that
the
 first negotiation ends with a 'finished' and then immediately a new
 'hello_request' - all in one EAP message.
 
 Greetings,
 
 Stefan
 
 
  Jim
 
 
  ___
  Emu mailing list
  Emu@ietf.org
  https://www.ietf.org/mailman/listinfo/emu
 
 
 
 --
 Stefan WINTER
 Ingenieur de Recherche
 Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
 la Recherche 6, rue Richard Coudenhove-Kalergi
 L-1359 Luxembourg
 
 Tel: +352 424409 1
 Fax: +352 422473


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

Re: [Emu] More COmments 2 on eap-tunnel-method

[Jim Schaad]

 -Original Message-
 From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
 Sent: Thursday, October 04, 2012 3:06 PM
 To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
 met...@tools.ietf.org
 Subject: Re: [Emu] More COmments 2 on eap-tunnel-method
 
 Jim:
 
 Please see comments below.
 
 On 10/1/12 1:10 PM, Jim Schaad i...@augustcellars.com wrote:
 
 I found two that I forgot to include in the last message
 
 1.  When exporting the user-id, does there need to be a way to
 distinguish at export time between the different types of ids that are
 authenticated by the server?  This does not seem to be an issue on the
 peer as it will only do mutual authentication to servers and thus only
 have server ids, however a server may authenticate to different types
 of identities on the peer.  At the moment we have identified user and
 machines as types of entities to be identified, I suppose in the future
 we could add Ewoks as a different type of entity that could be
 identified.  However the export function of user-ids does not make a
 distinction between the different types of authenticated entities.
 Should it do so or should it just export user authentications?
 [HZ] It helps to export the identities as well as the corresponding
identity
 types (from the Identity Type TLV). Will add text.
 
 2.  Is there a map of TLVs that should not be sent together or need to
 be processed in a specific order?  The case I was looking at was for
 the Identity TLV and the EAP TLV.  Is there a difference in how a peer
 should react for the following?
 
   Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP
 type
 XX)
   EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine
 Identity)
 
 Or should these two TLVs never occur in a single message?
 [HZ] We had some discussion in WG and take the design principal of TLV
 ordering should not matter. We disallow simultaneous EAP inner methods
 and/or with Basic Password Authentication, so rest of the TLVs order
should
 not matter. If it does matter, it should be a nested TLV, as in Result TLV
and
 Request-Action TLV. Need to add text to disallow Inner EAP method with
 parallel Basic Password Authentication TLV.

[JLS]  If order of TLVs does not matter, then there is an implied order that
the TLVs should be processed.  That is one should always process the
Identity TLV before processing the EAP TLV as the identity TLV is a hint to
the type of identity that is to be used in the EAP method.  Conversely it
might be that these two TLVs should never occur in the same message.

Ditto with the Basic Password Authentication TLV and the Identity TLV.

Jim

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

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

Re: [Emu] More comments for eap-tunnel-method

[Jim Schaad]

 -Original Message-
 From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
 Sent: Thursday, October 04, 2012 2:56 PM
 To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
 met...@tools.ietf.org
 Subject: Re: [Emu] More comments for eap-tunnel-method
 
 Jim:
 
 Thanks for the review. Please see my comments below.
 
 On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote:
 
 1.  Should the Message Length field be present if the TLS Data field is
 absent?
 [HZ] According to the text in the draft, the message length field should
only
 be present if the L bit is set, usually for fragmented packets. In those
cases,
 the TLS data field will be present, not absent. The only case TLS data
will be
 absent is when empty TEAP packet it is used to
  indicate TEAP acknowledgement for either a fragmented message,
  a TLS Alert message or a TLS Finished message. So the message
length
 field is not needed. We can clarify that in the draft.
 

[JLS]  I am not clear - are you saying that the first sever message sent
with just TLVs cannot be fragmented?

[JLS]  There is a potential issue in the way that the Message Length field
is described.  For finding the location of the Outer TLVs it provides the
length of the TLS Data field, but the internal description says that it
gives the length of the message data in the event of a fragmented message.
If the first client response message is both fragmented on length and
contains TLVs, then the message length field must be the length of the TLS
data in order to find the Outer TLV data but that means it is not the length
of all of the fragmented data.  This is not an issue after the first pair of
messages as the Outer TLVs are no longer allowed at that point.

[JLS] I presume that the Length needs to be present only if the message is
fragmented as a hint to the receiver on the length of the buffer to allocate
as I don't remember any error checks that the length of the message match
the re-constructed message from the fragments (and if it did then the
previous paragraph makes that faulty).  Should there be an error check on
the message length w/ the length of the re-constructed buffer?


 
 2.  There is nothing to say which TLVs can and cannot occur in the
 Outer TLVs in any easily findable method.  Either a table or the string
 outer in descriptions would be helpful.  As an example,  does the
 Authority-ID TLV in the outer TLV make sense?
 [HZ] We will add that table.
 
 3.  I have gone through the fragmentation and did an implementation
 rather than just reading it.  The questions that I have on it now are
 slightly different.  Do TLVs need to be on a fragment boundary? Or do
 we just build the entire message, fragment it into convenient sizes
 regardless of the actual content of the message contents and sent the
 pieces across?  If so then the text should probably be re-written to be
 clearer.  Specifically, the message length is not useful for allocating
 the buffer on the first round trip of messages where one can have a TLV
 added in to the content.
 [HZ] Message length covers the whole TEAP packet even if fragmented.
 TLVs do not need to be on a fragment boundary. Just build the whole
 message contents and send the pieces across. We will provide some text
 to clarify this.

[JLS] - see note above about finding the start of the Outer TLV data block
on the first pair of messages.

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

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

Re: [Emu] IMSK derivation issue

[Jim Schaad]

I have no problems with adding the Policy steps to the processing.

 

From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] 
Sent: Thursday, October 04, 2012 8:56 PM
To: Jim Schaad; emu@ietf.org
Subject: Re: [Emu] IMSK derivation issue

 

Jim:

 

Thanks for pointing out this issue. How about the following text with slight
modification with policy control from both sides to prevent downgrade
attack. Added text in red.

 

1. The first sender of the Crypto-Binding TLV needs to create it as

follows:

a) If the EMSK is not available, then it computes the Compound MAC as is

currently documented

b) If the EMSK is available, and the sender's policy accepts MSK based MAC,
then it computes two Compound MAC values. The

first is computed with the EMSK as is currently documented. The second is a

Compound MAC that uses the MSK and the Buffer is modified by adding the

string EMSK (or something similar). Both MACs are then send to the other

Side.

c) If the EMSK is available, but the sender's policy doesn't allow downgrade
to MSK generated MAC, then it should only send EMSK based MAC. 

 

2. The second sender of the Crypto-Binding TLV then:

a) If the EMSK is available and an EMSK Compound MAC was sent validates it

and creates a response using the EMSK and sends it back

b) If the EMSK is not available and an EMSK compound MAC was sent - it

validates the MSK using the modified BUFFER string and sends back a MSK

generated response

c) If no EMSK Compound MAC was sent, and its policy accepts MSK based MAC,
then it validates using the MSK - and if

successful generates and returns an MSK generated response. 

d) If no EMSK Compound MAC was sent, and its policy doesn't accept MSK based
MAC, then it handles like an invalid crypto-binding TLV with fatal error.

 

On 9/29/12 4:47 PM, Jim Schaad i...@augustcellars.com wrote:

 

I agree that the IMSK needs to take into account the existence of the EMSK,

however the current text has a severe problem with the way that it is done.

It assumes that if the EMSK is exportable on one side, then it will be

exportable on the other side as well.  I don't believe this is the case.

 

In order for this to work, and to prevent the downgrade attack by a MITM, I

believe that the following changes need to be made:

 

1.  The first sender of the Crypto-Binding TLV needs to create it as

follows:

a) If the EMSK is not available, then it computes the Compound MAC as is

currently documented

b) If the EMSK is available, then it computes two Compound MAC values.  The

first is computed with the EMSK as is currently documented.  The second is a

Compound MAC that uses the MSK and the Buffer is modified by adding the

string EMSK (or something similar).  Both MACs are then send to the other

side.

 

2.  The second sender of the Crypto-Binding TLV then:

a) If the EMSK is available and an EMSK Compound MAC was sent validates it

and creates a response using the EMSK and sends it back

b) If the EMSK is not available and an EMSK compound MAC was sent - it

validates the MSK using the modified BUFFER string and sends back a MSK

generated response

c) If no EMSK Compound MAC was sent, it validates using the MSK - and if

successful generates and returns an MSK generated response.  

 

If the EMSK compound MAC is removed in transit, then the MSK validated value

will fail as the BUFFER string is not modified to recognize that an EMSK

Compound MAC was sent.

 

3.  The first send then validates the returned values by:

 

a) If it sent an EMSK Compound value - attempt to validate using the EMSK

value.  If it fails then go to b else succeed

b) Validate using the MSK value using the unmodified buffer.

 

Both sides will then need to remember if the MSK or EMSK value was used for

validation in this step, but that is no different than the fact that the MSK

is currently being remembered.

 

Jim

 

 

___

Emu mailing list

Emu@ietf.org

https://www.ietf.org/mailman/listinfo/emu

 

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

[Emu] Client Auth with TLS

[Jim Schaad]

This issue is one that I was dealing with while driving grapes back from the
vineyard yesterday.  I don't know that it needs to have any changes in the
draft.  I am putting this out to see if there is any controversy on the
decisions that I would make about this issue.

The client is going to use client authorization with the TLS tunnel.  I make
the assumption that the client does successfully authenticate the server's
certificate and we are not in a total anonymous situation.  At this point I
believe the following possible scenarios exist:

1.  The client provides no certificate - This would be accepted depending on
the server policy about requiring a client certificate to be presented.

2.  The client provides a certificate in the clear - This could be either a
user or machine certificate, the server would check the identity against Its
database (with the proviso that the certificate could be the entry in the
database) and either accepts or rejects the TLS connection based on the
identity presented.  This would be done via a TLS alert.  Note, I did have
an argument with myself about the possibility that the server would accept
the certificate and treat it as if it was an anonymous client.

3.  The client provides the certificate in a protected manner - I had a
problem at this point because I don't know enough TLS to properly go through
this scenario, and I could not really read documents while driving.  If the
encrypted certificate extension was used, then there is no issue as the
protected certificate would be passed in the initial handshake.  However if
the client starts the negotiation and then restarts it after it is
encrypted, I don't know if this occurs before or after the finish message.
If it starts after the finish method then there is an issue with having the
server close an anonymous session if the client is then going to provide the
certificate encrypted.  Help on how this works would be appreciated.

Jim


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

[Emu] More comments for eap-tunnel-method

[Jim Schaad]

1.  Should the Message Length field be present if the TLS Data field is
absent?

2.  There is nothing to say which TLVs can and cannot occur in the Outer
TLVs in any easily findable method.  Either a table or the string outer in
descriptions would be helpful.  As an example,  does the Authority-ID TLV in
the outer TLV make sense?

3.  I have gone through the fragmentation and did an implementation rather
than just reading it.  The questions that I have on it now are slightly
different.  Do TLVs need to be on a fragment boundary? Or do we just build
the entire message, fragment it into convenient sizes regardless of the
actual content of the message contents and sent the pieces across?  If so
then the text should probably be re-written to be clearer.  Specifically,
the message length is not useful for allocating the buffer on the first
round trip of messages where one can have a TLV added in to the content.



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

[Emu] IMSK derivation issue

[Jim Schaad]

I agree that the IMSK needs to take into account the existence of the EMSK,
however the current text has a severe problem with the way that it is done.
It assumes that if the EMSK is exportable on one side, then it will be
exportable on the other side as well.  I don't believe this is the case.

In order for this to work, and to prevent the downgrade attack by a MITM, I
believe that the following changes need to be made:

1.  The first sender of the Crypto-Binding TLV needs to create it as
follows:
a) If the EMSK is not available, then it computes the Compound MAC as is
currently documented
b) If the EMSK is available, then it computes two Compound MAC values.  The
first is computed with the EMSK as is currently documented.  The second is a
Compound MAC that uses the MSK and the Buffer is modified by adding the
string EMSK (or something similar).  Both MACs are then send to the other
side.

2.  The second sender of the Crypto-Binding TLV then:
a) If the EMSK is available and an EMSK Compound MAC was sent validates it
and creates a response using the EMSK and sends it back
b) If the EMSK is not available and an EMSK compound MAC was sent - it
validates the MSK using the modified BUFFER string and sends back a MSK
generated response
c) If no EMSK Compound MAC was sent, it validates using the MSK - and if
successful generates and returns an MSK generated response.  

If the EMSK compound MAC is removed in transit, then the MSK validated value
will fail as the BUFFER string is not modified to recognize that an EMSK
Compound MAC was sent.

3.  The first send then validates the returned values by:

a) If it sent an EMSK Compound value - attempt to validate using the EMSK
value.  If it fails then go to b else succeed
b) Validate using the MSK value using the unmodified buffer.

Both sides will then need to remember if the MSK or EMSK value was used for
validation in this step, but that is no different than the fact that the MSK
is currently being remembered.

Jim


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

[Emu] Review - draft-ietf-emu-crypto-bind-00.txt

[Jim Schaad]

As was pointed out to me, the subject message on the message had the wrong
draft name (even if the version number was right).

I am re-posting so that searches on the subject will find the correct
document for comments.

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Jim Schaad
 Sent: Tuesday, September 25, 2012 9:11 PM
 To: emu@ietf.org
 Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00
 
 Version 0 of the document is not ready for a last call as security
 considerations are missing.
 
 Other comments
 
 
 1.  I think in figure #1, there would be improved clarity if the line for
Pear
 initiates connection to a service would have the following under the
attacker
 line  --|-- to indicate that the attacker is intercepting the traffic
at this
 point and forwarding it.
 
 2.  The last paragraph in section 1 need to be re-organized.
 a) It says there are several strategies, but I can only see two that are
outlined
 here
 b) It is not clear where the second strategy starts.  That is is the
technical
 solution part of the security solution. (yes I know that it is
 not)
 c) It is unclear if the cryptographic binding is unable to make the proof
to the
 peer, or if this is just not done because the peer has traditionally not
cared
 that it was so.
 
 3.  In section 2 I have a problem with the sentence Channel bindings are
 used to tell the peer which application service is being connected to.  I
don't
 know that this is a good characterization of what is happening with
channel
 bindings esp with the updated RFC in process.  The issue I have is that
not all
 of the information about the service is communicated to the peer, and the
 peer is told information about the service, but still might not know what
 service it is connected to.  I think a better characterization might be
Channel
 bindings are used to provide the peer with information about the
application
 service it is connecting to.
 
 4.  I would add an introductory sentence to paragraph #2 in section 2 to
say
 this is the start of an example.
 
 5.  In section 3.2.2 - Item #1 seems to be a hardship to get implemented
and
 get right.  There is an easy argument that servers can have a policy
 configured about what inner methods can be used, but imposing it on the
 peer and making the configuration be server based can be problematic.  I
 think that this issue probably deserves more text.  How is the
configuration
 updated and transferred to the peer.
 
 6.  In section 3.2.4 - then condition 3 need to tell me where condition
3 is -
 what section?
 
 7.  Missing paran  (see Section 3.3. insert
 
 8.  In section 3.3 - can the intended intermediary be on the other side -
that is
 between the NAS and the authenticator rather than the peer and the NAS?
 This is not clear from the text
 
 9.  In section 4.2 - there may be another piece of state tracking that
should be
 added.  It is not enough to know that mutual authentication has occurred,
it
 might also be important to know who it has occurred with.  Thus having
 performed mutual auth with a user is different than performing mutual auth
 with a machine and the operations that are allowed to take place may be
 different.
 
 10.  Section 5, 6 and 7 appear to be completely absent in the current
draft.
 
 Jim
 
 
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu

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

[Emu] Review of draft-ietf-emu-eap-tunnel-method-00

[Jim Schaad]

1.  In section 3.2.3, it says that a new PAC can be requested after a full
TLS handshake.  Can one be requested following an abbreviated handshake?  Or
do you just re-use the existing PAC?

2.  Section 3.3 s/descried/described/

3.  Section 3.4 - Is it possible to have multiple server ids after the
authentication - one from the tunnel and others from the inner EAP methods.
I realize that most EAP methods don't send a sender id, but some (IBAKE for
example) currently do.  Also, the client might have an idea of what the
sender id is from configuration.  If so, do these all need to get exported
as server-id values?

4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent
when 1) the server sends a fatal alert to the peer, 2) the peer requests a
restart via a ClientHello and 3) the peer declines to permit the restart to
occur.

5.  In section 3.6.1 - Is the restart only an issue for fatal alerts, or is
it a problem for all alerts?

6.  In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure?

7.  In section 3.6 - do we need to discuss the question of errors in the
outer EAP layer that is carrying the TLVs which contain the TLS content?
This is a distinct location from the current list of where to handle errors.
There is going to be a distinction (possibly) between errors that occur
during phase 1 and errors during phase 2.  Should the error return reflect
if the error occurred inside or outside of the TLS tunnel?

8.  In section 3.8 - I have the following questions
a) In the text The request MAY be issued, I don't understand the MAY at
this point.  Is it supposed to say that the request can be issued either
before or after the authentication has finished, or is it saying that the
peer has the option of issuing or not issuing the request, but must wait
until the authentication level has been reached?
b) If a peer issues a PAC request, but the server has not yet satisfied it's
policy, does the server remember the PAC request and send back the response
after the internal policy has been satisfied or should it send back an error
saying that policy has not yet been satisfied along with additional TLVs to
attempt and satisfy that policy?
c) What should a peer do if it receives a PAC TLV with an unknown attribute?

9.  In section 3.9 - there is leaking on the POP, but not on identity at
this point.  I believe that there needs to be a requirement that an EAP
method needs to be run which will provide an identity proof on the client
prior to a certificate being issued.  You may or may not then want to add
text that says that the subject name(s) in the certificate request need to
be checked against the set of authenticated identities prior to the
certificate being issued.

10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode
is because the server or the peer is unauthenticated at this point in time.
The cipher suite would indicate that the server is not authenticated,
however what about the case of the server providing an authenticated id to
the peer, but the peer is unable to validate the identity of the server for
some reason.  This is also a Server Unauthenticated mode.

11.  In section 4.1 - I would like to see a discussion that says that the
following situation can never occur.  The initial EAP message from the peer
to the server (or the response) plus the Outer TLV data plus the EAP message
headers exceeds the underlying packet size of the transport.  In the event
that it does, I am not sure how one finds the Outer TLV data start and where
the fragmentation would occur to get the Outer TLV data between the peer and
the server.

12.  Section 4.2 - I understand what is happening with an EMPTY TEAP message
being sent in response to a list of TLVs that are marked optional, however I
question if the statement that is MUST be sent is correct.  There are two
reasons for the question:  

a.  A server could send a RESULT TLV in response to a message from the
client that contains no TLVs that are either mandatory or recognized.
b.  I am (very slightly) worried about the fact that the response is not
authenticated by the tunnel in many manner.  I would think that a NAK to any
of the TLVs would be a better response if no other TLV messages are to be
sent.  The entity sending the TLV should know if it marked it as mandatory
or not.  The NAK is not the same as an Error TLV.

13.  Section 4.2.2 - Should Type in the outdented list be TLV Type? 
 s/filed/field/

14.  Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a
peer?

15.  Section 4.2.3 - I assume that there should only be one Identity-Type
TLV in a TEAP packet.  Should a request for authentication be present in the
packet as well?  If multiple are allowed then information about how to treat
this should be included.  What should the peer respond with if it does have
an identity of the type?  This is not explicitly stated.

16.  Section 4.2.4 - I don't understand the default in the event that an
unknown value 

[Emu] Review - draft-ietf-emu-eap-tunnel-method-00

[Jim Schaad]

Version 0 of the document is not ready for a last call as security
considerations are missing.

Other comments


1.  I think in figure #1, there would be improved clarity if the line for
Pear initiates connection to a service would have the following under the
attacker line  --|-- to indicate that the attacker is intercepting the
traffic at this point and forwarding it.

2.  The last paragraph in section 1 need to be re-organized.
a) It says there are several strategies, but I can only see two that are
outlined here
b) It is not clear where the second strategy starts.  That is is the
technical solution part of the security solution. (yes I know that it is
not)
c) It is unclear if the cryptographic binding is unable to make the proof to
the peer, or if this is just not done because the peer has traditionally not
cared that it was so.

3.  In section 2 I have a problem with the sentence Channel bindings are
used to tell the peer which application service is being connected to.  I
don't know that this is a good characterization of what is happening with
channel bindings esp with the updated RFC in process.  The issue I have is
that not all of the information about the service is communicated to the
peer, and the peer is told information about the service, but still might
not know what service it is connected to.  I think a better characterization
might be Channel bindings are used to provide the peer with information
about the application service it is connecting to.

4.  I would add an introductory sentence to paragraph #2 in section 2 to say
this is the start of an example.

5.  In section 3.2.2 - Item #1 seems to be a hardship to get implemented and
get right.  There is an easy argument that servers can have a policy
configured about what inner methods can be used, but imposing it on the peer
and making the configuration be server based can be problematic.  I think
that this issue probably deserves more text.  How is the configuration
updated and transferred to the peer. 

6.  In section 3.2.4 - then condition 3 need to tell me where condition 3
is - what section?

7.  Missing paran  (see Section 3.3. insert

8.  In section 3.3 - can the intended intermediary be on the other side -
that is between the NAS and the authenticator rather than the peer and the
NAS?  This is not clear from the text

9.  In section 4.2 - there may be another piece of state tracking that
should be added.  It is not enough to know that mutual authentication has
occurred, it might also be important to know who it has occurred with.  Thus
having performed mutual auth with a user is different than performing mutual
auth with a machine and the operations that are allowed to take place may be
different.

10.  Section 5, 6 and 7 appear to be completely absent in the current draft.

Jim


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

[Emu] Delegation

[Jim Schaad]

In the Plasma work effort we have spent much of the last month thinking
about and doing some discussions on the question of delegated access.   In
the process we have located the following SAML document
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cs-01.
pdf which discusses how to create a SAML statement which has the delegation
information built in.  This gives us what we need in order to do the
evaluation on the RP about what delegation has occurred.

The problem is that there is currently no way to discuss the questions of
delegation in the EAP protocols that I know of.  This has not been a problem
when we were looking at just the question of accessing a network; however
the additional resources that we are now looking at because of ABFAB are now
starting to make this an interesting question to looking at.

The questions that I would have for the EMU group are:

1.  Is there any interest in looking at the issues of how one requests a
delegated access to occur?

2.  What set of restrictions are going to be necessary for doing delegation.
At present, since the only cases that I care about are going to be the ABFAB
cases all I would actually need to the ability to say in one of the tunneled
messages a simple statement to the effect that I want delegate access to
name which would either be granted or denied.

3.  If we do delegated access, what things other than the SAML statement
returned in the ABFAB context need to be changed?  

4.  Do we need to be able to do both delegation, where the delegation
process is understood by the RP, and impersonation where the RP may not be
able to tell that the authenticated entity is not really the same as the
named entity returned to the RP from the IdP.

5.  Are there other issues that need to be discussed?

Jim


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

Re: [Emu] Multiple Request Action Items

[Jim Schaad]

Hao,

The idea that I thought you had presented would not make it a very
complicated item.

1.  Change the specification so that multiple Request TLVs are permitted to
occur in the TLV sequence.
2.  Change to specification so that the Request TLV item now looks like
M|R|TLV Type | Length |
Status | TLV sequence

The TLV Sequence is the set of TLV items to be processed for that sequence
code.

Then need some oddball text to the effect that:

Two Request TLVs MUST NOT occur in the message if they have the same Status
value.
The order of processing multiple Request TLVs is implementation dependent.
If the server process the optional (non-fatal) items first, it is possible
that the fatal items will disappear at a later time.  If the server process
the fatal items first, the communication time will be shorter.

The client MAY return a new set of Request TLV items after one or more of
the requested items has been processed and the server has signaled it wants
to end the EAP conversation.

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Hao Zhou
 Sent: Monday, April 02, 2012 4:29 AM
 To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
 Cc: emu@ietf.org
 Subject: Re: [Emu] Multiple Request Action Items
 
 Jim:
 
 Good question. The current draft allows for multiple request TLV items,
but
 only says a single Result TLV, indicating the what EAP Success/Failure
result
 the peer would expect if the requested action is not granted.
 
 I can definitely see the need for the case you cited. If we want to extend
 existing design to include individual Result TLVs for the individual
request
 items, we can do that. But I think this might be more complicated and
 unnecessary.  Maybe we can use the mandatory bit in the requested TLVs to
 indicate whether ignoring it would cause the failure in the result TLV.
 
 Thoughts?
 
 On 3/30/12 3:34 AM, Jim Schaad jim...@augustcellars.com wrote:
 
  In the presentation you stated that the plan was to make the TLVs that
  are requested become a sub TLV of the request TLV items.  If that is
  true, then should it be possible to allow for multiple request TLVs to
  be present in a message.  Thus one could say:
Please do A - and if not then fail authentication
Please do B - and if not then succeed authentication
 
  Jim
 
 
  ___
  Emu mailing list
  Emu@ietf.org
  https://www.ietf.org/mailman/listinfo/emu
 
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu

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

[Emu] Multiple Request Action Items

[Jim Schaad]

In the presentation you stated that the plan was to make the TLVs that are
requested become a sub TLV of the request TLV items.  If that is true, then
should it be possible to allow for multiple request TLVs to be present in a
message.  Thus one could say:
  Please do A - and if not then fail authentication
  Please do B - and if not then succeed authentication

Jim


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

[Emu] Comments on emu-eap-tunnel-method-02

[Jim Schaad]

1.  After the first exchange of messages, if the version does not match the
agreed on version - what happens?

2.  Section 3.2 says that one should be able to do a renegotiate for getting
the peers identity certificate.  Do the following points need to be made?
a) If you are doing a re-negotiation - then you SHOULD not be using an
anonymous cipher suite
b) Once you have started phase 2, re-negotiation MUST NOT be done.

3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? For
example, EAP-TLS...  If not, then I would suggest changing to a std track
protocol.

4.  In section 3.4 - I want to make sure that what I read is what you
intend.
 == If I do multiple (one or more) inner EAP methods, the authenticated peer
identity is the set of all of these identities.
 == If I do zero inner EAP methods and I do a client auth TLS, the
authenticated peer identity comes from the certificate.
 == If I do zero inner EAP methods and do not do a client auth TLS, then I
have no authenticated peer identity.

 -- specifically - should the client auth TLS identity be excluded if I run
an inner EAP method
 -- Specifically - should the all non EAP methods be excluded -- include the
TEAP defined user name/password
 -- Specifically - should any EAP server name established in an EAP method
be excluded from its name set?

5.  In section 3.8 - potentially ambiguous statement:  The request MAY be
issued after the peer has determined...  Is the request the MAY or the
timing of the request the MAY?
 
6.  In section 4.2.3 - What is the registration policy for the Identity-Type
field of the Identity-Type TLV?  Do there need to be reserved ranges for use
by specific Servers - i.e. local use? Or is that insane?

7. In section 4.2.4 - What do I do for an defined value.  Do these values
only match those of the available through the base document or are other 

8.  In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate
to be included in the peer response?

9.  Does the order of items in the TLV list matter?  Or are specific TLVs
expected to be processed first.  For example what would be the expected
order on the  Identity-Type TLV and the EAP-Payload TLV?

10.  Section 4.2.12.2 says the key is of a specific length, yet there is
length field.  Why is a specific length mentioned esp as the length was just
changed in the last version.  I assume this key length is dependent on the
PAC type and should not be fixed.

11. Section 4.2.15 - If we change the standard way of doing name
preparation, should we be creating a new item, or should we have a byte
field that specifies the username/password processing function.

12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold
true if the TLS-PRF were to use a new cypher suite that used P_SHA512?

Jim


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

Re: [Emu] Comments on emu-eap-tunnel-method-02

[Jim Schaad]

You might also need to put in an IANA consideration for the use of the TLS
Exporter
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter-
labels)

Jim


 -Original Message-
 From: Hao Zhou [mailto:hz...@cisco.com]
 Sent: Wednesday, March 21, 2012 11:26 AM
 To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
 Cc: emu@ietf.org
 Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02
 
 Jim:
 
 Thanks for the detailed review. My comments are below inline:
 
 
 On 3/21/12 6:15 AM, Jim Schaad i...@augustcellars.com wrote:
 
  1.  After the first exchange of messages, if the version does not
  match the agreed on version - what happens?
 
 [HZ] Good catch. Both sides should stick with the version negotiated. I
guess
 we will add some language to describe the behavior handling exceptions. My
 initial thoughts are both sides should treat it as fatal error and proceed
with
 fatal error processing, e.g., server should just send back EAP-Failure and
peer
 sends back EAP-Nak.
 
  2.  Section 3.2 says that one should be able to do a renegotiate for
  getting the peers identity certificate.  Do the following points need to
be
 made?
  a) If you are doing a re-negotiation - then you SHOULD not be using an
  anonymous cipher suite
  b) Once you have started phase 2, re-negotiation MUST NOT be done.
 
 [HZ] Good points. I will add them.
 
  3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP?
  For example, EAP-TLS...  If not, then I would suggest changing to a
  std track protocol.
 
 [HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std
track
 RFC.
 
  4.  In section 3.4 - I want to make sure that what I read is what you
  intend.
   == If I do multiple (one or more) inner EAP methods, the
  authenticated peer identity is the set of all of these identities.
   == If I do zero inner EAP methods and I do a client auth TLS, the
  authenticated peer identity comes from the certificate.
   == If I do zero inner EAP methods and do not do a client auth TLS,
  then I have no authenticated peer identity.
 
 [HZ] Correct except last one. I would say the authenticated peer identity
 comes from any inner method, not necessary EAP method. So if a password
 TLV exchange happened, then the authenticated peer identity is coming
 from that password authentication TLV exchange. I think we will change the
 word inner EAP method to inner authentication method.
 
   -- specifically - should the client auth TLS identity be excluded if
  I run an inner EAP method
 [HZ] No.
   -- Specifically - should the all non EAP methods be excluded --
  include the TEAP defined user name/password
 [HZ] No.
   -- Specifically - should any EAP server name established in an EAP
  method be excluded from its name set?
 
 [HZ] It could be included as part of the Server-ID if the server is not
 authenticated as part of the tunnel establishment. I will add some text to
 address this.
  5.  In section 3.8 - potentially ambiguous statement:  The request
  MAY be issued after the peer has determined...  Is the request the
  MAY or the timing of the request the MAY?
 
 [HZ] Good catch. It is the request MAY. Timing is should be after
validating
 the crypto-binding TLV. I will address that.
  6.  In section 4.2.3 - What is the registration policy for the
  Identity-Type field of the Identity-Type TLV?  Do there need to be
  reserved ranges for use by specific Servers - i.e. local use? Or is that
 insane?
 
 [HZ] I missed that in IANA section. It should be Spec Required as others.
I
 don't see need for local use types.
 
  7. In section 4.2.4 - What do I do for an defined value.  Do these
  values only match those of the available through the base document or
  are other
 
 [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or
others?
 
  8.  In section 4.2.9 - Are the TLVs to be processed and the EAP to
  negotiate to be included in the peer response?
 
 [HZ] Yes. I will add a sentence or two describe this.
 
  9.  Does the order of items in the TLV list matter?  Or are specific
  TLVs expected to be processed first.  For example what would be the
  expected order on the  Identity-Type TLV and the EAP-Payload TLV?
 
 [HZ] It shouldn't matter. But I would think Identity-Type TLV should
precede
 EAP-Payload TLV. Let me think about maybe some other cases order is
 important and document that.
 
  10.  Section 4.2.12.2 says the key is of a specific length, yet there
  is length field.  Why is a specific length mentioned esp as the length
  was just changed in the last version.  I assume this key length is
  dependent on the PAC type and should not be fixed.
 [HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix
that. 48
 octets are just an example, maybe minimum length.
 
  11. Section 4.2.15 - If we change the standard way of doing name
  preparation, should we be creating a new item, or should we have a
  byte field that specifies the username/password

[Emu] Comments on draft-hartman-emu-mutual-crypto-bind

[Jim Schaad]

Sam et al,

1. In section 1 after the Classic Tunnel Attack figure, I believe there are
three methods listed as possible mitigation strategies, however I don't
understand how the second one - a sufficiently strong inner method - could
possibly be a mitigation by itself.  The three I see are 1) Policy 2) strong
inner method 3) Cryptographic binding.


2.  In section 3.2.2 - For the more traditional MITM attack.  There is a
requirement for this defense that the internal authentication methods are
going to be able to support the cryptographic binding that you are
postulating.  If this is not true then this would not be a detectible
attack.  I think this should go into the paragraph before the diagram rather
than being (kind of) implicit in the paragraph after the figure.

3.  3.2.3 or 3.2.2 - If you had a non EAP method, and it derived a key (just
like a good EAP method).  Is there any reason why you could not do the
cryptographic binding?  Other than it is not currently defined in one of the
current tunneling methods.  One could see that it could be defined as saying
after you do this, then perform the same binding as any key deriving EAP
method would do,.

4.  Section 3.2.4 - Item #4 - did you mean that it MUST prevent an attacker
from downgrading the binding from mutual to just MSK-based?  Also if the
down grade occurs, do you still want to claim that it is still mutual if
step 4 is downgraded?  The current text implies this to me and that seems
wrong.

5.  Section 3.2.4 - last paragraph - the last sentence confuses the heck out
of me.

6. Section 4.2 - I don't understand why things like doing channel binding
require that a mutual authentication be present.  I can understand a
statement that the peer MUST have doing an adequate job of authenticating
the server, but I am less clear why the server needs to have authenticated
the client.  Thus for example I think that cryptographic binding should be
sufficient to deal with these cases.  (i.e. Tunnel is authenticated to
certificate and mutual auth is tied to the tunnel).

Jim


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

Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation

[Jim Schaad]

There is one other item that is also worrying me about this.

In doing the check of certificates, one should be doing revocation checking.
However if one is trying to get network access, one cannot independently
download the revocation information until access is granted, and one cannot
get access granted until one has finished the EAP negotiation.

Currently there is only a limited ability to download the information inside
of the TLS exchange, but that needs to be a requirement. 

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Sam Hartman
 Sent: Friday, February 17, 2012 2:04 PM
 To: emu@ietf.org
 Subject: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for
 interoperable implementation
 
 
 Hi.
 I'm writing up a draft on mutual crypto binding.
 As such, I happened to glance at section 7.6 on server certificate
validation.
 
 The advice there is entirely inadequate for interoperable implementation
 and violates the tunnel method requirements:
 
 1) .  There's a SHOULD check the server name, but there are no mandatory-
 to-implement name forms.
 That is, I don't know how to map something the peer is likely to have such
as
 the realm in a NAI to something that could be in a certificate.
 
 
 2) Section 3.9 of the tunnel method requirements talks about
certificateless
 authentication.  this is incompatible with  MUST verify server cert as
well as
 the false claim that during TLS negotiation a server always sends a
certificate
 to a client.
 
 I'd recommend  resolving as follows:
 
 1) Peers and servers MUST implement certificate modes of TLS; covered
 elsewhere in the doc.
 
 2) Peers MUST implement and SHOULD validate server certs to a known trust
 anchor.
 
 3) Pick a name form. Peers MUST implement validation of names against this
 name form. Describe where peers get the name to check against (obvious
 options include the NAI and separate configuration).
 
 4) Peers SHOULD default to checking the name.
 
 5) Describe other certificate properties such as keyusage, EKU, etc or
point
 back to TLS if appropriate.
 
 6) we probably need language dealing with the sort of stuff I'm writing up
 when some of these shoulds need to be upgraded. For example I think it's
 highly unadvisable to run channel bindings without checking the cert and
 binding back to a specific name or strong mutual crypto binding.
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation

[Jim Schaad]

TLS can present an OCSP response for the end certificate,  if you have
TA-CA1-EE then you can't get it for the CA1 certificate.

Jim


 -Original Message-
 From: Sam Hartman [mailto:hartmans-i...@mit.edu]
 Sent: Saturday, February 18, 2012 11:28 AM
 To: Jim Schaad
 Cc: 'Sam Hartman'; emu@ietf.org
 Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for
 interoperable implementation
 
  Jim == Jim Schaad i...@augustcellars.com writes:
 
 Jim There is one other item that is also worrying me about this.
 Jim In doing the check of certificates, one should be doing
 Jim revocation checking.  However if one is trying to get network
 Jim access, one cannot independently download the revocation
 Jim information until access is granted, and one cannot get access
 Jim granted until one has finished the EAP negotiation.
 
 
 TLS these days has the ability to present an OCSP response inline, right?
 Wouldn't that be a eaiser-to-implement strategy?

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

[Emu] Channel Bindings Document

[Jim Schaad]

I should probably read it when I am not so tired and distracted, however I
believe that all of my issues have been addressed in the last version

Jim


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

Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09

[Jim Schaad]

* In section 5.1 (para 3) - The following sentence does not make sense to
me.
   Message i2 is the information the AAA server receives from the last hop
in the AAA  proxy chain which is not necessarily the authenticator.

  Specifically I do not follow the last clause and what it is referring to.
Are you stating that the element in the AAA proxy chain may not be the
authenticator?  If so, I would omit the clause as it seems obvious to me
since you are talking about a chain.

* How does authenticated vs non-authenticated information get denoted in a
AAA message?  Given that some information can be authenticated at an early
point in the chain and some must be deferred until the last node this would
need to be denoted as authenticated vs non-authenticated information.  And
who validated it? WARNING: may be stupid question by somebody who does not
know Radius/Diameter

* s/thatwere/that were/

* section 5.2
s/have gone lost/have got lost/

* It  is not clear to me if the EAP server is to reflect the values from the
EAP client in the response message or if it should reflect values from the
NAS/AAA path.  

* Is it reasonable/possible that a policy would pull some attribute from the
AAA path that is not supplied by the EAP client and therefore need to
reflect it to the EAP client as part of the response?  Or is the set of
values to be reflected back to the EAP client restricted by the set of
values that it supplies?

* Section 7.2 - I am afraid I don't understand what this new RADIUS
attribute is supposed to be carrying.   I am doubly confused since the
introductory text in sections 7 and 7.1 talk about the values of i1, but my
understanding is that i1 is sent from the NAS to the peer, using some
unknown protocol and then from the peer to the EAP server using an EAP
method and thus the reason for the RADIUS attribute is confusing.  I would
understand it better if we are talking about sending i2 data for things
which are not already RADIUS attributes, but that does not seem to be how
the text is designed. 

This might just be talking about the EAP method to be used, but this is also
confusing since that is not something I would expect the NAS to be involved
in.

I might have gotten a better grasp on this, and I think that part of my
problem is that I think that this could be a mis-named attribute.  I now
understand that this is dealing with what is the method that is being used
to talk between the EAP peer and the NAS.   I think it is partly misleading
because this is only part of what is carrying the EAP data layer (along with
a AAA layer currently) and thus is not completely true.  It might be better
to call it the Peer-NAS transport layer or something similar.

* Section 8 - You are talking about this information as being validated by
the AAA server as oppose to being validated for consistency against the i1
data by the EAP server.  Is this what you are really intended?



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

Re: [Emu] Submitted 10

[Jim Schaad]

I want to make sure that we have distinguished between the two statements

1.  The server says that I don't support these specific attributes and
2.  The server does not tell me that it did or did not do matching of some
attributes.

The first I think is totally optional, but the second is necessary for the
tunnel draft and should be made explicit in this draft as something that
needs to be done.  I will be reading this document with this in mind.

Jim


 -Original Message-
 From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
 Sam Hartman
 Sent: Friday, October 21, 2011 12:34 PM
 To: Hao Zhou
 Cc: Sam Hartman; emu@ietf.org
 Subject: Re: [Emu] Submitted 10
 
 I'll respond to the question of channel binding support now.  I think the
 current text permits an EAP method to not send channel binding if it knows
 the server fails to support it.  If your method can discover that and
 optimistically avoid sending channel binding that's fine.
 
 I think we discussed the flow in a fair bit of detail and I think we have
 consensus on the current flow including the lack of server telling the
peer
 which channel binding attributes it supports.  As an individual, I do not
 support opening that up again, although if there is WG consensus to make a
 change we should do so.
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] Comments on the eap-tunnel-method-00 draft

[Jim Schaad]

 -Original Message-
 From: Hao Zhou [mailto:hz...@cisco.com]
 Sent: Wednesday, October 19, 2011 12:31 PM
 To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
 Cc: emu@ietf.org
 Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft
 
 Jim:
 
 Thanks for reviewing the draft in detail and comments provided. Please see
 my response inline below.
 
 
 On 10/17/11 6:08 PM, Jim Schaad i...@augustcellars.com wrote:
 
  I have gathered these comments over time and therefore some of them
  are not fully fleshed out.  If you have any questions I will try and
  reconstruct my ideas at the time.
 
  Jim
 
 
 
  Version Negotiation - terminate the conversation - w or w/o a fail?
  Edge case - what if peer only supports a higher version than the
  server supports?  NAK?
 
 [HZ] It depends. Server might want to proceed with other EAP type
 negotiation by proposing a different EAP type, or terminate the
conversation
 with an EAP-Failure. I will clarify that in the next rev.

Yes - but in this case I would expect a NAK from the client - possibly
proposing other methods.  Is this correct?

 
  EAP Server Name Checking - On what basis does the client accept or not
  accept the EAP server name?You are suggesting that it is signed by a
CA
  controlling the intended domain, but what does this mean?   Are you
  suggesting that the CA should have a DNS subject alt name in it for
  the domain in question?
 
 [HZ] It's up to client's policy, especially if the server cert is issued
by a public
 CA. Client needs not only verify that the server cert presented is a valid
cert
 signed by the trusted CA, but also the server name presented in the cert
is
 matching the domain it tried to authenticate with. A FQDN in the CN or SAN
 would be a way to do it.
 
  If no embedded EAP methods run, then no crypto check and thus no
  version # checking is done.
 [HZ] That's true.

Ok - this would be in violation of the last paragraph in section 3.1 which
says that the version numbers MUST be done.

 
 Also no checking done if only one inner EAP method is  used as this
 only sends the Result TLV and not the Crypto-Binding TLV
 
 [HZ] That's not true. Crypto-binding would still be exchanged with Result
TLV.
 Actually using of the Result TLV in lieu of IM-Result TLV is for legacy
reason in
 EAP-FAST, which could be removed in next rev since we are designing a new
 EAP method.

Please tell me where it says this is done.  All I can see is that one CAN
send intermediate-result, result and crypto-binding TLVs in the same
message.  (Unless of course only one is sent in which case the
Intermediate-Reuslt TLV MUST NOT be sent).   However these is nothing that
says that the Crypto-binding TLV would be sent after the first and only EAP
method - or indeed after a sequence of EAP methods.


  'serially in a sequence' is redundant - section 3.3.1
 
 [HZ] Ok. The text is trying to distinguish from running multiple EAP
methods
 in parallel.
 
  Not only does it not allow initiating multiple EAP methods in
  parallel, it requires that they not be running in parallel.  This is a
  more strict condition
 
 [HZ] For simplicity, otherwise implementation would need to trace when the
 1st method finishes and applies the key from the authentication to the
 crypto-binding. Supporting them in complete sequence makes it simpler and
 securer, as 2nd method might not be safe to run if the crypto-binging
after
 1st method fails.

Do you ever expect a version to allow multiple EAP sequences to be run at
the same time?  If not then just the statement that they MUST be executed
serially is probably sufficient.

 
  Para #3 - can the peer return an error and treat the failure of a
  specific EAP method as a total failure for the overall process - or at
  least recommend that it should be an overall failure?
 
 [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send
up some
 Fatal Error TLV and Result TLV to indicate the end.

Ok - either I don't see the text or my comment is not sufficiently clear.

Consider:
Client is running EAP-BLAH and returns inside of the EAP-BLAH method a
failure. 
If the client wants an overall failure rather than leaving it up to the
server, does it send both the Result TLV failure and the EAP-Message w/ the
failure - or just the result TLV failure or is this not reasonable for the
client?

 
  Confused messages in 3.3.1 and 3.3.3 about sending intermediate
  results and final results at the same time.  Specifically 3.3.1 says
  MUST NOT for one inner EAP method,  but text is not reflected in
  section 3.3.3
 
 [HZ] I think we can change to always send IM result after each inner EAP
 method, if only one inner method, then Result TLV could be sent as well.
See
 explanation above.


  Conflict between 3.3.3 and security considerations (7.5) about sending
  a different value in the Result TLV and the clear result in the event
  of not doing a Request-Action TLV from the client.  Is the server
  required

[Emu] Comments on the eap-tunnel-method-00 draft

[Jim Schaad]

I have gathered these comments over time and therefore some of them are not
fully fleshed out.  If you have any questions I will try and reconstruct my
ideas at the time.

Jim



Version Negotiation - terminate the conversation - w or w/o a fail?
Edge case - what if peer only supports a higher version than the
server supports?  NAK?

EAP Server Name Checking - On what basis does the client accept or not
accept the EAP server name?You are suggesting that it is signed by a CA
controlling the intended domain, but what does this mean?   Are you
suggesting that the CA should have a DNS subject alt name in it for the
domain in question?

If no embedded EAP methods run, then no crypto check and thus no version #
checking is done.  Also no checking done if only one inner EAP method is
used as this only sends the Result TLV and not the Crypto-Binding TLV

'serially in a sequence' is redundant - section 3.3.1

Not only does it not allow initiating multiple EAP methods in parallel, it
requires that they not be running in parallel.  This is a more strict
condition

Para #3 - can the peer return an error and treat the failure of a specific
EAP method as a total failure for the overall process - or at least
recommend that it should be an overall failure?

Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and
final results at the same time.  Specifically 3.3.1 says MUST NOT for one
inner EAP method,  but text is not reflected in section 3.3.3

Conflict between 3.3.3 and security considerations (7.5) about sending a
different value in the Result TLV and the clear result in the event of not
doing a Request-Action TLV from the client.  Is the server required to use
the client suggested result in the event it does not perform the request
action - could it use a different failure message or a success message?
Does it matter?

Section 3.4 - Need to address the following issues:
1.  what if both certificates and an inner EAP method are run - what is the
Peer-Id then?
2.  What if multiple inner EAP methods are run - which Peer-Id is used then?
3.  What if client and machine EAP methods are run - which one to use then?
(Internal what are the ids used for?)

Section 3.6 - item #2 - it should be noted that not all failure indications
would be transmitted.  The failure/success of the last EAP method may not be
sent as it gets wrapped into the Result TLV message

Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV
itself need to be acknowledged?

Section 3.7 - Can I assume that the identifier value is monotonically
increasing and does not wrap?

Section 3.7 - it might be useful to tell me how to error for a message too
big or response time too long in dealing with fragmentation - are both just
final errors? Or should it potentially be treated as a TLS error?

Section 3.2 - possible clarification.  If all TLVs in a message are marked
optional and none are understood by the peer, then an EMPTY response message
must still be sent to the server.  

Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV -
not what it says in section 3.3

Section 4.2.3 - NAK TLV should not be accompanied by other TLVs.   Not sure
I understand why.  If I send an EAP plus a vendor w/ mandatory set, should
not I get back a NAK on the vendor plus a result for the EAP?
I might be happy to not do the vendor, but want to distinguish between you
cannot do this vs you choose not to do this.  Not fully sure that I really
care about this case as long I can assume that if the mandatory bit is set
then I would always fail the overall EAP conversation.

Section 4.2.10 - How can I know if the server does or does not process the
channel binding TLV?  This may be part of my policy as a peer depending on
circumstances.

Section 4.2.8 -  Currently says that version should be 1 while the version
defined in the intro sections is 2 - would be correct if we change the EAP
method.




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