Draft IETF 65 meeting minutes

Attached are draft minutes for IETF 65 EMU meeting.  Please let me know
if you have any additions or corrections.  

Thanks,

Joe

IETF 65 EAP Method Update (EMU)
-----------------------------------
Tuesday March 21, 2006

Compiled from notes taken by Laksminath Dondeti and Nancy Cam-Winget

=========================================================
1. EMU pre shared key design team update (Uri Blumenthal)
=========================================================

Presentation (Uri): EAP method update from the PSK design team
- Goals: Create an EAP method based on a PSK, meets 3748 and 4017 reqs,
  and simple and compact 

- Decisions:
  Not based on TLS-PSK
  symmetric credentials only, no public key based credentials
  No multi-party
  Fast resumption is unnecessary
  Must support channel bindings
  Algorithm agility
  Provisioning out of scope

draft-simon-emu-rfc2716bis-01

I think this draft is a good start.  At the meeting at IETF 65 the
working group desired to take this draft as a working group item.  Would
the authors submit this draft as draft-ietf-emu-rfc2716bis-00.txt.

Comments on the draft:

1. Section 2.4 Identity verification

The document specifies that the peer as server ID is carried in the
subjectAltName extension.  

A. It is possible that this extension may be empty and the name be
carried in the subjectName.  Should this be taken into account?  What is
the format of the ID, is it represented in ASN.1 format?  

B. It seems that there may be more than one SubjectAltName.  Are both
used as the ID?  It seems that order would matter for constructing a key
name.  

C. This document should probably reference RFC 3280. 

D. I think the last paragraph might not be quite correct:

"... Please note that in the case where the EAP authentication is
remoted that
   the EAP server will not reside on the same machine as the
   authenticator, and therefore the name in the EAP server's certificate
   cannot be expected to match that of the intended destination. In this
   case, a more appropriate test might be whether the EAP server's
   certificate is signed by a CA controlling the intended destination

ICV in EAP-PAX

Hi all, 
the following question arose while re-reading several specs. 

EAP-PAX computes an ICV (Integrity Check Value) as follows (Sect. 3.3)

   The ICV is computed as the MAC over the entire EAP packet, including
   the EAP header, the EAP-PAX header, and the EAP-PAX payload.  The MAC
   is keyed using the 16-octet ICK, using the MAC type specified by the
   MAC ID in the EAP-PAX header.  For packets of type PAX_STD-1,
   PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been
   derived, the MAC is keyed using a zero-octet NULL key.
   If the ICV field is incorrect, the receiver MUST silently discard the
   packet.

But RFC 3748 days in Section 3.1 

       [...] EAP methods may not
       include a MIC, or if they do, it may not be computed over all the
       fields in the EAP packet, such as the Code, Identifier, Length,
       or Type fields.   [...]

So, is the ICV of EAP-PAX compliant to RFC 3748 at all? 

And which additional security is obtained through the ICV ? 

(Compare the packet-wise MAC to the strategy of TLS: There, it suffices
to compute at the end a checksum (by means of the Finished messages) 
over the whole handshake messages to ensure the handshake's
integrity).  

RE: ICV in EAP-PAX

>    The ICV is computed as the MAC over the entire EAP packet, including
>    the EAP header, the EAP-PAX header, and the EAP-PAX payload.  The MAC
>    is keyed using the 16-octet ICK, using the MAC type specified by the
>    MAC ID in the EAP-PAX header.  For packets of type PAX_STD-1,
>    PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been
>    derived, the MAC is keyed using a zero-octet NULL key.
>    If the ICV field is incorrect, the receiver MUST silently discard the
>    packet.
>
>But RFC 3748 days in Section 3.1
>
>        [...] EAP methods may not
>        include a MIC, or if they do, it may not be computed over all the
>        fields in the EAP packet, such as the Code, Identifier, Length,
>        or Type fields.   [...]
>
>
>So, is the ICV of EAP-PAX compliant to RFC 3748 at all?

Yes, it is compliant.  The text above was meant to convey that not all EAP 
methods will be able to cover the entire EAP packet in their MAC.

>And which additional security is obtained through the ICV ?

The ability to protect against modification of the EAP header fields 
including Code, Identifier, Length and Type.

>(Compare the packet-wise MAC to the strategy of TLS: There, it suffices
>to compute at the end a checksum (by means of the Finished messages)
>over the whole handshake messages to ensure the handshake's