This page contains information on the PEAPv2 specification, including the list of open and resolved issues.
Documents
Current Specification
Open Issues List
A description in red implies that no issue has been submitted (if you are the owner of such a message, please send PEAP an issue). An asterix following an Issue number (e.g. Issue#666*) means that the issue entry is not up to date, and the author is expected to send additional text to PEAP .
To submit a new issue, send an e-mail to the PEAP Mailing List, using the following template:
Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Document: Document Requiring change [PEAPv2]
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem
Requested change:
Proposed changes to the document. Please be specific about what text you want to change, add or delete. Issues cannot be considered until specific text is provided.
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
|
PEAPv2 Issue Number |
Status | Type | Description | Owner |
| Issue 31 | PEAP-10 | Editorial | "Issue:" Cleanup | Bernard Aboba |
Resolved Issues List
The following table contains the issues that have already been resolved,and the fix included in a revision of the specifications.
The following are the long form versions of the issues:
Issue 1: Examples Update
Submitter:
Ashwin Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: Appendix A
Rationale/Explanation of issue:
The examples have not been changed to show Outer TLVs.
[Ashwinp] Here is the proposed resolution:
A.12 Successful Session Resume with Server-Identifier TLV
In the case where an server-identifier TLV is used by server to
indicate its identity,
the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
// The T bit is set to indicate the TLS message length. The bytes after
TLS Data (which is in this case is zero length) are the Outer-TLVs. The
Server-Identifier-TLV is sent in the clear.
<- EAP-Request/
EAP-Type=PEAP, V=2
(PEAP Start, S bit set, T bit set), TLS
message length=0, Server-Identitifer-TLV
// The server identifier TLV identifies the server. The peer selects a
session handle that corresponds to that specific server to that the TLS
session could be resumed (instead of going through the full handshake)
EAP-Response/
EAP-Type=PEAP, V=2
(TLS client_hello)->
// subsequent packets are same as example "session resume success"
------------------------------------------------
Other changes
1. Crypto-binding version in ALL examples should be set to 2.
2. The draft refers to "Server-Identity TLV" at one place. It should be
renamed to "Server-Identifier TLV"
Proposed Resolution: Accept
Issue 2: TLS Alerts
Submitter: Ashwin
Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 2.2.3
Rationale/Explanation of issue:
Can the peer use some other TLS alert to indicate the
failure
to EAP server? In Anon-DH, the server explicitly knows
that the
client will use provisioning mode. Will this in anyway
make this
provisioning mode less secure?
Proposed Resolution: Reject
Issue 3: Provisioning Mode
Vulnerabilities
Submitter: Ashwin Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 2.2.3
Rationale/Explanation of issue:
Since the server does not know upfront that the peer has
decided to go
into provisioning mode, does this result in any attacks like privacy et
al?
[BA] The server will find out when the peer sends a Credential Provisioning Request. It can then modify the EAP methods it will allow.
Proposed Resolution: Reject
Issue 4: Version
Verification
Submitter: Ashwin Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 4.5
Rationale/Explanation of issue:
Shouldn't the MAC include the version number of the
Crypto-Binding TLV and
nonce et al?
[BA] It's already included.
Proposed Resolution: Reject
Issue 5: Length in MAC
Submitter:
Ashwin Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 4.5
Rationale/Explanation of issue:
The length in the TLS payload TLV will not be included in calc of the MAC. Is this ok?
[Ashwinp] The proposed resolution is as follows.
Add the following text to Section 4.5:
"The EAP-Payload-TLV Message Length field in the PEAPv2 header is not
protected, and hence can be modified by a attacker. The TLS record length
in the TLS data inside EAP-Payload-TLV is protected. Hence, if the
EAP-Payload-TLV Message length received in the first packet (with L bit
set) is greater or less than the total size of TLS messages received
including multiple fragments, then the EAP-Payload-TLV message length
should be ignored."
[Hao Zhou] I think it's transposed. It should be
(after outer-TLV issue resolvance):
"The TLS Message Length field in the PEAPv2 header is not protected, and
hence can be modified by an attacker. The EAP length in the TLS data inside
EAP-Payload-TLV is protected. Hence, if the TLS Message length received in
the first packet (with L bit set) is greater or less than the total size of
TLS messages received including multiple fragments, then the TLS message
length should be ignored."
I am not sure it's needed here. We have used the same language somewhere else
already (Section 2.4).
[Ashwinp] Remove all the above. The text already exists. Replace this text in section 4.6:
“[c] The first two Outer-TLV packets sent by peer to the EAP-server. If
a single outer-TLV packet is fragmented in multiple PEAP packets;
then all fragments for that message MUST be included. The TLS-
Payload TLV MUST NOT be included in the calculation of the MAC.
[Issue] The length in the TLS payload TLV will not be included in
calc of the MAC. Is this ok?”
with:
a) If the party has received a crypto-binding TLV from the other party,
then the entire Crypto-Binding TLV attribute received from the other party
b) The EAP Type sent by the other party.
c) All the Outer-TLVs from the first PEAP message sent by EAP-server to peer. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
d) All the Outer-TLVs from the first PEAP message sent by peer to EAP-Server. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
Issue: The algorithm to calculate MAC seems to be calculating the MAC in the wrong order. Ashwin to check the algorithm. [I checked together with Dan, but couldn’t find the problem-Ashwin].
[Hao Zhou]
a) If the party has received a crypto-binding TLV from the other party,
then the entire Crypto-Binding TLV attribute received from the other party --
Change this to Crypto-binding tlv generated by the sender – Ashwin to check with Dan Simon.
b) The EAP Type sent by the other party.
c) All the Outer-TLVs from the first PEAP message sent by EAP-server to peer. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
d) All the Outer-TLVs from the first PEAP message sent by peer to EAP-Server. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
"
a) The entire Crypto-Binding TLV attribute with the MAC field zeroed out.
b) The EAP Type sent by the other party in the first PEAP message.
c) All the Outer-TLVs from the first PEAP message sent by EAP-server to peer. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
d) All the Outer-TLVs from the first PEAP message sent by peer to EAP-Server. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
[Ashwinp] Here is the proposed resolution:
“The
Compound MAC field is 20 octets. This can be the Server MAC
(B1_MAC) or the Client MAC (B2_MAC). It is computed using the
HMAC-SHA1-
160 that provides 160 bits of output using the CMK_B1or CMK_B2
key. The MAC is computed over the buffer createda)
The entire Crypto-Binding TLV attribute with the MAC field zeroed out.b) The EAP Type sent by the other party
in the first PEAP message.c) All the Outer-TLVs from the first PEAP message sent by EAP-server to peer. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included.
d) All the Outer-TLVs from the first PEAP message sent by peer to EAP-Server. If a single PEAP message is fragmented into multiple PEAP packets; then the Outer-TLVs in all the fragments of that message MUST be included."
Proposed Resolution: Accepted
Issue 6: Tunnel Compromise
Error
Submitter: Ashwin Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 4.5
Rationale/Explanation of issue:
If Outer-TLVs are modified, the compound
MAC would fail, but is this really
a tunnel compromise error?.
[Ashwinp] The proposed resolution of this issue is
to insert the following text
(does not overwrite the existing section 4.4):
"4.4. Error TLV
The Error TLV allows a PEAPv2 peer or server to indicate errors to
the other party. A TLV packet can contain 0 or more Error TLVs.
Error TLVs MUST be marked as Mandatory. PEAPv2 implementations MUST
support the Error TLV, which cannot be responded to with a NAK TLV.
The Error TLV is defined as follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type
|
Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Error-Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
22
Length
4
Error-Code
The Error-Code field is four octets. Error Codes 1-999 represent
successful outcomes (informative messages), 1000-1999 represent
warnings, and codes 2000-2999 represent fatal errors.
If an Error-Code TLV with a fatal error has been sent, then the conversation MUST be terminated.
Currently defined values for Error-Code include:
2001 Tunnel compromise error
2002 Unexpected-TLVs exchanged"
[Hao Zhou] Type 13 is already used for
Calling-Station-Id TLV.
Don't we want to define one error code for Crypto-binding Error (used to be
called Tunnel Compromise Error)?
What does Outer-TLV compromise mean? I am not sure we can detect that, other
than crypto-binding failed. Maybe that's the Crypto-binding Error.
Also don't forget to change Section 2.3, error handling, "crypto-binding
(tunnel compromise errors) are communicated via Result TLV with Error TLV
instead of TLS alert messages."
[Ashwinp]
Change this text in section 2.3 (Error handling):
REPLACE
“[3] Violation of the TLV rules for inner-TLVs are handled using Result-TLVs.”
WITH:
“[3] Violation of the TLV rules for inner-TLVs are handled using Result-TLVs
together with Error-Code TLV.”
REPLACE:
“Any time the peer or the EAP server finds an error when processing
the sequence of exchanges, such a violation of TLV rules, it should
send a Result TLV of failure and terminate the tunnel. This is
usually due to an implementation problem and is considered an fatal error.”
WITH:
“Any time the peer or the EAP server finds an error when processing
the sequence of exchanges, such a violation of TLV rules, it should
send a Result TLV of failure with Error-Code TLV =Unexpected-TLVs-Exchanged, and terminate the tunnel. This is
usually due to an implementation problem and is considered an fatal error.”
>> Make sure the following is included in the draft à if crypto-binding error, then raise error code xxx
[Ashwinp] Here is the proposed resolution:
4.4. Error TLV The Error TLV allows a PEAPv2 peer or server to indicate errors to the other party. A TLV packet can contain 0 or more Error TLVs. Error TLVs MUST be marked as Mandatory. PEAPv2 implementations MUST support the Error TLV, which cannot be responded to with a NAK TLV. The Error TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type
22 Length 4 Error-Code The Error-Code field is four octets. Error Codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and codes 2000-2999 represent fatal errors. If an Error-Code TLV with a fatal error has been sent, then the conversation must be terminated. Currently defined values for Error-Code include: 2001 Tunnel compromise error 2002 Unexpected-TLVs exchanged" In PEAPv2 draft Error Handling section: REPLACE "[3] Violation of the TLV rules for inner-TLVs are handled using Result-TLVs." WITH: "[3] Violation of the TLV rules for inner-TLVs are handled using Result-TLVs together with Error-Code TLV."
REPLACE: "If a tunnel compromise error (see Section 2.2) is detected by the peer, the peer SHOULD send a TLS Internal Error alert (a Fatal error) message instead of the next EAP-response packet to the EAP server. Similarly, if a tunnel compromise error is detected by the EAP server, the EAP server SHOULD send a TLS Internal error alert (a Fatal error) message instead of the next EAP-response packet to the peer." WITH "If a tunnel compromise error (see Section 2.2) is detected by the Peer or EAP server, the party SHOULD send a Result TLV of failure without a crypto-binding TLV, AND Error-Code TLV=Tunnel-compromise-error (a Fatal error), and terminate the tunnel. The party that receives the Error-code TLV=Tunnel-compromise error should terminate the tunnel."
[Hao Zhou] Looks fine in the text proposed. In addition: 1. Change Section 2.3 error handling [1] Errors in TLS and errors related to crypto-binding (tunnel compromise errors) are communicated via TLS alert messages. To [1] Errors in TLS layer are communicated via TLS alert messages. 2. Change Section 2.3 error handling " Any time the peer or the EAP server finds an error when processing the sequence of exchanges, such a violation of TLV rules, it should send a Result TLV of failure and terminate the tunnel. This is usually due to an implementation problem and is considered an fatal error." To " Any time the peer or the EAP server finds an error when processing the sequence of exchanges, such a violation of TLV rules, it should send a Result TLV of failure and Error-Code TLV=Unexpected-TLVs Exchanged (a Fatal error), and terminate the tunnel. This is usually due to an implementation problem and is considered an fatal error. The party that receives the Error-code TLV=Unexpected-TLVs Exchanged should terminate the tunnel."
I would suggest to use TLV type 5 (instead of 22) for Error TLV. We have 5, 19, maybe 18 (if we eliminate Credential TLV) unused.
[Ashwinp] Agreed. (we should open up another issue to track the renumbering of TLV numbers; and this can be easily done after we finish discussions on Error TLV and Credential-TLV).
Proposed Resolution: Accept
Issue 7: Reporting
Submitter: Ashwin
Palekar
Submitter email address: ashwinp@microsoft.com
Date first
submitted: May 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 5.12
Rationale/Explanation of issue:
Reporting??
Proposed Resolution: Reject
Issue 8: Miscellaneous NITs
Submitter:
Joe Salowey
Submitter email address: mailto:ashwinp@microsoft.com
Date
first submitted: March 15, 2004
Reference:
Document: PEAP-08
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
During subsequent authentications, the peer is expected to use regular authentication process in PEAP part 1 and PEAP part 2."
to
"During subsequent authentications, the peer is not expected to use the initial credential provisioning mode."
[BA] Incorporated (section # has changed)
4. Section 4
Remove text on MIP binding update unless we can answer Jari's comment.
[BA] Done.
Proposed Resolution: Accept
Issue 9: Outer TLVs
Submitter: Joe
Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted:
March 15, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
[Hao Zhou] These are the new proposed changes
after today's discussion:
3.1. PEAP Protocol Layers
PEAP packets may include TLVs both inside and outside the TLS
tunnel. The term "Outer TLVs" is used to refer to optional TLVs outside
the TLS tunnel, which are only allows in the first two messages in this
version of the PEAP protocol. That is the first EAP server to peer message
and first
peer to EAP server message. If the message is fragmented, the whole set of
messages is counted as one message. The term "Inner TLVs" is used to refer
to TLVs
sent within the TLS tunnel.
In PEAPv2 Part 1, Outer TLVs are used to help establishing the TLS
tunnel, but no Inner TLVs are used. Therefore the layering of PEAPv2
Part 1 is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TLS | Opt. Outer TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
PEAP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
EAP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In PEAPv2 Part 2, TLS records may encapsulate zero or more Inner TLVs,
but no Outer TLVs. EAP packets (including EAP header fields) used
within tunneled EAP
authentication methods are carried within Inner TLVs. Therefore the layering
of
PEAPv2 Part 2 is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
EAP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner-TLVs (EAP-Payload TLV)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TLS
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
PEAP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
EAP
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. PEAPv2 Packet Format
A summary of the PEAPv2 packet format is shown below. The fields are
transmitted from left to right.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code |
Identifier |
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
Flags | Ver | Frag Message Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frag Message Length |
TLS Message Length...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length
| TLS Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
2 - Response
Identifier
The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each
Request packet. The Identifier field in a Response packet MUST
match the Identifier field from the corresponding Request.
Length
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, Flags,
Version, Fragmented Length, TLS Message Length, TLS Data, and Outer-TLV fields. Octets
outside the range of the Length field should be treated as Data
Link Layer padding and should be ignored on reception.
Type
25 - PEAP
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S T R|
+-+-+-+-+-+
L = Length included
M = More fragments
S = PEAP start
T = TLS Length included
R = Reserved (must be zero)
The L
bit (Fragmented Message Length included) is set to indicate the
presence of the four octet Fragmented Message Length field, and MUST
be set for
the first fragment of a fragmented PEAP message or set of
messages. The M bit (more fragments) is set on all but the last
fragment. The S bit (PEAP start) is set in a PEAP Start message.
This differentiates the PEAP Start message from a fragment
acknowledgment. The T bit (TLS Message Length included) is set to
indicate the presence of the four octet TLS Message Length field, and
MUST
only be set for packet that contains Out-TLVs. It can be used to calculate
the
start of the Outer-TLVs.
Version
0 1 2
+-+-+-+
|R|1|0|
+-+-+-+
R = Reserved (must be zero)
Fragmented Message Length
The Fragmented Message Length field is four octets, and is present
only if the L bit is set. This field provides the total length of
the data after the Fragmented Message Length field in the PEAP message
or set of messages that is being fragmented.
TLS Message Length
The TLS Message Length field is four octets, and is present
only if the T bit is set. This field provides the total length of
the TLS Data in the PEAP message. Data after this length of TLS data
are the Outer-TLVs.
TLS Data
The TLS data consists of the encapsulated packet in TLS record format.
Outer-TLVs
The Outer-TLVs consists of the optional data used to help establishing
the TLS tunnel in TLV format. The start of the Outer-TLV can be derived from
the EAP
Length field and TLS Length field.
Section 4.1, change "2 - TLS-Payload TLV" to "2 - Reserved"
Remove Section 4.2
4.20.1. Outer TLVs
The following table provides a guide to which TLVs may be included in
the PEAPv2 packet outside the TLS channel, which kind of packets, and
in what quantity:
Request Response Success
Failure TLV in unencrypted-TLVs field
0-1 0
0 0
Server-Identifier TLV
0+ 0+
0 0
Vendor-Specific TLV
Outer-TLVs MUST be marked as optional. Vendor-TLVs inside
Vendor-Specific TLV MUST be marked as optional when included in
Outer TLVs. Outer-TLVs MUST NOT be included in messages after the first
two PEAPv2 messages sent by peer and EAP-server respectively. That is the
first EAP server to peer message and first peer to EAP server message. If
the message is fragmented, the whole set of messages is counted as one
message. If Outer-TLVs are included in messages after the first two
PEAPv2 messages, they MUST be ignored.
Proposed Resolution: Accept
Issue 10: AES Ciphersuites
Submitter:
Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted:
March 15, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 2.1.2
Rationale/Explanation of issue:
[BA] The proposed resolution is to change the ciphersuite support text in Section 2.1.2 to the following:
"
To ensure interoperability, PEAPv2 peers and servers MUST support the
TLS v1.0 [RFC2246] mandatory-to-implement ciphersuite:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
In addition, PEAPv2 servers SHOULD support and be able to negotiate
the following TLS ciphersuites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
In addition, PEAPv2 peers SHOULD support at least one of the
following TLS ciphersuites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA"
Proposed Resolution: Accept
Issue 11: Draft Review
Submitter: Hao
Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: March
25, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
9. Section 4.13 should be removed, as Crypto-binding is number 12 now. Actually, it should be moved to here.
10. Section 4.12.1, changes are in red, old text in (). Shouldn't be any TLVs in EAP-Success and Failure. Do we want to peer to send some credentials(encrypted) to server in outer TLVs to allow fast resume?
Request Response Success Failure TLV in unencrypted-TLVs field
0-1 0(0-1) 0(0-1) 0(0-1) Server-Identifier TLV
0+ 0+ 0(0+) 0(0+) Vendor-Specific TLV
1 1 0(1 ) 0(1 ) TLS-Payload TLV
0 0-1 0 0 Credential-Payload TLV
14. Section 4.18, Credential TLV is a lot like PAC-TLV we defined in EAP-FAST, which is reserved for TLV type 11. Maybe we can converge them.
15. I thought we only allow outer TLS in first packet from server and first response from peer, not like currently described first two packets from both sides.
[Ashwinp] Here is the proposed resolution:
1) Section 2.5: In the definition of ISK1...ISKn..
In some cases where the inner EAP method does
not provide keys: ISKi, for some i, may be the
null string (""). In some cases where the inner
EAP method provides keys less than 32 bytes long,
then the key should be extended to 32 bytes using
PRF+(ISKi,"EAP method key", 32)"
2) Section 4.5: The compound MAC is described as 20 bytes long, but then immediately afterward as 16 bytes long. It might as well be the full, untruncated 160-bit HMAC output.
The Compound MAC field is 20 octets. This can be the Server MAC
(B1_MAC) or the Client MAC (B2_MAC). It is computed over the
entire Crypto-Binding TLV attribute using the HMAC-SHA1-160 that
provides 160 bits of output using the CMK_B1 or CMK_B2 with the
MAC field zeroed out. The MAC is computed over the buffer created
after concatenating these fields in the following order:
In Section 4.12.1:
Request Response Success Failure TLV in unencrypted-TLVs field
0-1 0 0 0 Server-Identifier TLV
0+ 0+ 0 0 Vendor-Specific TLV
1 1 0 0 TLS-Payload TLV
0 0-1 0 0 Credential-Payload TLV
Correction:
Remove all references to TLS-Payload TLV in the draft
Proposed Resolution: Accept
Issue 12: WLAN Requirements
Compliance
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: June 4, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 5.13
Rationale/Explanation of issue:
Specifically, I'm not clear that the "State Synchronization" requirement is met:
"This
requirement applies when the EAP
method completes successfully.
The exact state attributes that are
shared may vary from method to
method but typically include the
protocol both executed, what
credentials were presented and
accepted by both parties, what
cryptographic keys are shared and
what EAP method specific attributes
were negotiated, such as cipher
suites and limitations of usage on all
protocol state. Both
parties must be able to distinguish this
instance of the protocol
from all other instances of the protocol and
they must share the
same view of which state attributes are public and
which are
private to the two parties alone."
For example, the EAP Type Code (PEAP) is not currently included in any of the cryptographic hashes.
[BA] Proposed resolution:
Add "State Synchronization [Walker]: Yes" to Section 5.13.
Proposed Resolution: Accept
Issue 13: Various Issues
Submitter:
Hao Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: March
25, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
Why are we excluding EAP-TLV here? We established that we only run crypto-binding after EAP method, not after TLV exchanges. Even if we count EAP-TLV as an EAP method, usually it doesn't generate keys. For consistency, I would recommend to run crypto-binding after all EAP methods, including EAP-TLV. If no key is generated from EAP method, then use all null strings for ISK. I don't see the need to run EAP-TLV at all especially after TLVs are available now.
7. Section 2.2.1, "Alternatively, if a subsequent EAP conversation is being attempted, then in order to
reduce round trips, both TLVs SHOULD be sent in the EAP-Payload of the first EAP packet of the next EAP conversation (for example, EAP-Identity or EAP-packet of the EAP method)". "Sent in" should be "sent with"
8. Section 3.4, TLS Payload TLV has a maximum length of 64K octets, as it falls into a TLV format. What if the TLS data is more than that, breaking into multiple TLS Payload TLVs in fragments and reassemble them? It might be simpler to leave TLS data as before in PEAP data field, and add optional outer TLV right after the Flag and version field, before the TLS data, and have a flag to indicate outer TLVs. It would be easier to reassemble fragmented TLS data and calculate crypto-binding over header and outer TLVs.
The section number is wrong too.
11. Section 4.12.1 Inner TLVs, should be Section 4.12.2. And
Request Response Success Failure Inner-TLVs
0+ (0) 0+ 0+ 0+ Credential-Payload TLV
Server can send credentials to peer after successful authentication without peer requesting it.
12. Section 4.12.2 EAP-Payload TLV, I don't know why NAK-TLV needs to be in EAP-Payload TLV. If all Vendor Specific TLVs in EAP-Payload TLV are optional, they shouldn't be NAKed.
16 - Server-Identifier TLV
17 - Identity-Type TLV
18 - Credential-Payload TLV
20 - PKCS#7 TLV (should it be 19?)
21 - Request-Action TLV (should it be 20?)
Proposed Resolution: Accept
Issue 14: Mandatory Bit for Identity-Type,
Credential-Payload and PKCS#7 TLVs
Submitter: Hao Zhou
Submitter email
address: hzhou@cisco.com
Date first
submitted: June 7, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: 4.16, 4.17, 4.18
Rationale/Explanation of
issue:
:If mandatory bit is set, it's mandatory TLV.
Length description of
problem: In Identity-Type TLV, Credential-Payload TLV,
PKCS#7 TLV these
optional TLV format section, mandatory bit is set.
Requested change:
Change from "1 - Optional TLV" to "0 - Optional TLV"
Proposed changes to the
document.
Proposed Resolution: Accept
Issue 15: Mandatory Bit for Request-Action
TLV
Submitter: Hao Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: June
7, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 4.19
Rationale/Explanation of issue:
If mandatory bit is set, it's mandatory TLV.
Length description of
problem: In Request-Action TLV format section, description of
mandatory bit
is wrong.
Requested change: Change from "0 - Mandatory TLV 1 - Optional
TLV" to "1 - Mandatory TLV 0
- Optional TLV"
Proposed Resolution: Accept
Issue 16: Reserved TLV
Submitter: Hao
Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: June
7, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 4.11
Rationale/Explanation of issue:
TLV number 12 is not reserved anymore. It is used for Crypto-Binding TLV.
Proposed Resolution: Accept
Issue 17: Parallel vs. Serial Sequencing
Submitter: Joe
Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted:
June 24, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: 1
Section: 1.2
Rationale/Explanation of issue:
[Ashwinp] Here is the proposed resolution:
Replace:
“PEAPv2 supports two types of sequences:
[1] Serial authentication. Initiating additional EAP method(s) after a
first successful authentication. In this case the sequence is
successful if each of the EAP authentication methods completes
successfully. For example, successful authentication might require
a successful machine authentication followed by a successful user
authentication.
[2] Parallel authentication. Initiating an alternative EAP method after
failure of one or more initial methods. In this case the overall
authentication is successful if any of the methods is successful.
For example, if machine authentication fails, then user
authentication can be attempted.”
WITH:
“PEAPv2 supports initiating additional EAP method(s) after a
successful or a failed EAP method. The result of failure of a
EAP method does not always imply a failure of the overall
authentication. The overall result of authentication depends
on the policy at EAP server and the peer. For example,
successful authentication might require a successful
machine authentication followed by a successful user
authentication. Alternatively, if machine authentication
fails, then user authentication can be attempted.
PEAP does not support initiating multiple EAP methods simultaneously. “
Proposed Resolution: Accept
Issue 18: Technical issues
Submitter:
Nancy Cam-Winget
Submitter email address:
ncamwing@cisco.com
Date first submitted:
June 24, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
pg. 13 Section
2.1.2
* The last paragraph of this section is not clear. The description implies
that the client side
authentication can be done once the tunnel is established using server side
authentication but outside the
EAP sequencing. Why add this additional state in PEAPv2? Why not have the
client authentication be an
EAP method (for instance use EAP-TLS with a client side cert only)?
pg. 14 Section 2.1.3
* The 5th and 6th paragraph seem unclear and or confusing:
- What "devices" are being round-robin'ed, I am assuming the APs? Why would
such a configuration
exist?
- Since the conversation is between an EAP peer and server, it is unclear
why the issues highlighted
on the NAS are raised in these two paragraphs? Are these paragraphs even
needed? I would recommend
either their removal or rephrasing to better highlight the benefit of the
use of the Server-Identifier
TLV.
pg. 17 Section 2.2.1
* The last sentence in 4th paragraph states:
'...both peer and EAP server MUST use the Intermediate Result TLV to
communicate the result."
Do we really want to expend 2 extra results for the final EAP method, e.g.
an Intermediate as well as a
Final Result?
pg. 18 Section 2.2.2
* The first two sentences describe the inclusion of Crypto-Binding TLVs in
the Final Result as well as
the Intermediate Result TLVs. So, for after a single or last EAP method is
concluded, is PEAPv2
explicitly stating (based on section 2.2.1 and 2.2.2) that both an
Intermediate as well as Final Result
TLVs must be invoked?
pg. 19&20 Section 2.2.3
* 2nd paragraph: PEAPv2 should provide more flexibility in its provisioning
mode than that specified by
this paragraph. The description implies the use of certificates but then
subsequent descriptions enable
the use of DH_ANON (e.g. no certificates).
* 3rd paragraph: PEAPv2 should provide more flexibility in the types of
credentials and EAP methods used
for provisioning. Since the protocol is merely provisioning, I do not
understand why key derivation is a
requirement? Also, as long as appropriate ground rules are applied for the
PEAPv2 part 1 conversation, I
think it is okay to add flexibility in allowing client-only authentication
on the PEAPv2 part 2
conversation.
Section 2.5:
* The key derivations for the Compound MAC can be better simplified.
* The nonces do not need to be included in the Compound MAC key derivations.
* Why are 2 separate keys needed for the Compound MACs?
* Why are the same nonces used for both the Compound MAC key as well as the
Session Key generators?
* A cleaner proposal would be to have a key construction that while
dependent on the EAP method's keying
material, do not rely on the Nonces (the nonces are used for liveness proof
but are not needed for
freshness, unless there is another security goal you are achieving that I
fail to see?).
* A proposal would be to construct the keys as such:
S-IMCK0 = tunnel keying material, ISKj = keying material resulting from the
j-th EAP method
For j = 1 to n-1 do
IMCKj = T-PRF(S-IMCKj-1, "Inner Methods Compound Keys", ISKj, 60);
Where S-IMCKj are the first 40 octets of IMCKj
The last 20 octets of IMCKj map to the Compound MAC key use to generate the
crypto-binding hashes.
On the last iteration, the final PEAPv2 keying material is then generated as
such:
MSK = T-PRF(S-IMCKn, "Session Key Generating Function", OutputLength)
where OutputLength is the desired output length.
[Ashwinp]
Action item: Nancy to send email to Dan Simon and CC PEAP alias about this issue.
[Ashwinp] The proposed resolution is as follows:
Replace in section 2.1.2
“Note that since TLS client certificates are sent in the clear, if
identity protection is required, then it is possible for the TLS
authentication to be re-negotiated after the first server authentication.”
WITH:
“Note that since TLS client certificates are sent in the clear, if
identity protection is required, then it is possible for the TLS
authentication to be re-negotiated after the first server authentication.
Alternatively, if identity protection is required, then it is
possible to perform certificate authentication using a EAP method
[for example: EAP-TLS] within the TLS session in PEAP part 2”
Remove the following 2 paragraphs in section 2.1.3:
“In the case where the EAP server and the authenticator
reside on the
same device, then the client will only be able to continue sessions
when connecting to the same NAS or channel server. Should devices be
set up in a rotary or round-robin, where the Server-Identifier TLV is
not used, it may not be possible for the peer to know in advance the
authenticator it will be connecting to, and therefore which sessionId
to attempt to reuse. As a result, the continuation attempt is likely
to fail.
In the case where the EAP authentication is remoted then continuation
is much more likely to be successful, since multiple NAS devices and
channel servers will remote their EAP authentications to the same
backend authentication server."
Add this para to section 2.2.1
The Intermediate-Result TLV is used to indicate the result of a
individual successful EAP method; and the Result TLV is used
to indicate result of the entire PEAP conversation.
Remove this para from section 2.2.1
“If no EAP methods have been negotiated inside the tunnel or no EAP methods have
been successfully completed inside the tunnel, the Crypto-Binding TLV MUST NOT be used.”
Add this para to 2.2.3
“ If the peer does not authenticate; or does not successfully authenticate
the EAP server during TLS negotiation, it can decide to go into initial
provisioning mode. While this section describes negotiation of a
certificate-based ciphersuite within TLS, PEAPv2 supports negotiation
of other ciphersuites (for example, ciphersuites that do not use certificates)
or extensions. However, the conversation may slightly differ if other TLS
ciphersuites or extensions are used.”
Add this section before 2.2.3
PEAPv2 Provisioning
PEAPv2 supports inbuilt provisioning of certificate trust anchors;
and can be extended to provision other peer credentials.
As described in PEAP part 2, after successful authentication
of the peer and EAP server within a server authenticated TLS
tunnel, the peer can request a credential from the EAP server.
In certain situations, the peer may not have the information
necessary to securely authenticate the server and create an
authenticated tunnel. At the same time, bootstrapping the
information to the peer out of band may be prohibitive from
a deployment cost perspective. In this case, at the cost of
security the peer can decide to ignore server authentication
and create an un-authenticated TLS tunnel. After successful
authentication of the peer and the server within this
unauthenticated TLS tunnel, the peer can request a credential
from the EAP server. Once this credential is obtained,
the peer can use this provisioning credential during
subsequent authentications of the network to reduce
surface area of attack. This unauthenticated tunnel
mode of provisioning provides ease of deployment at
the cost of introducing man-in-the-middle vulnerabilities.
As a result, implementation of this unauthenticated tunnel
mode of provisioning is OPTIONAL.
[Hao Zhou]
Section 2.2.3 Provisioning of Credentials PEAPv2 supports built-in provisioning of certificate trust anchors and can be extended to provisioning of other types of credentials. PEAPv2 supports provisioning in following two modes: a) Provisioning inside a server authenticated TLS tunnel: After regular authentication in PEAP part 2, the peer and EAP server can use Credential-payload TLV to request for and provision peer credentials. This provisioning payload is exchanged after the peer and EAP server have determined that both have successfully authenticated each other (either thru TLS handshake and/or inner EAP method); and the tunnel and inner EAP methods are between the same peers. After the peer has determined that it has successfully authenticated the EAP server and determined that the tunnel and inner EAP methods were between the same peer and EAP server by validating the Crypto-Binding TLV, it MAY send one or more Credential-Payload TLVs (marked as optional) to request credentials from the EAP server. The EAP server will send corresponding credentials in Crdential-Payload TLVs if its internal policy has been satisfied. It may ignore the credential provisioning request or request additional authentications if its policy dictates. The peer may receive a credential, but is not required to use the credentials received from the EAP server.
b) Provisioning inside a server unauthenticated TLS tunnel: In some cases, peer lacks the credentials to authenticate the server in TLS handshake. At the same time, bootstrapping the information to the peer out of band may be prohibitive from a deployment cost perspective. It can rely on the inner EAP method using existing credentials to authenticate the server. This provisioning mode provides ease of deployment at the cost of introducing man-in-the-middle vulnerabilities. As a result, implementation of the server unauthenticated tunnel provisioning mode is OPTIONAL. In this provisioning mode, as part of PEAPv2 part 1, if the peer does not authenticate; or does not successfully authenticate the EAP server during TLS negotiation, it can decide to go into this provisioning mode. While this section describes negotiation of a certificate-based ciphersuite within TLS, PEAPv2 supports negotiation of other ciphersuites (for example, ciphersuites that do not use certificates, anonymous DH) or extensions. However, the conversation may slightly differ if other TLS ciphersuites or extensions are used. For example, in a certificate based TLS handshake, the peer verifies that the EAP server possesses the private key corresponding to the public key contained in the certificate presented by the EAP server. However, the peer does not verify whether the certificate presented by the server chains to a provisioned trust anchor, as the peer may not be configured with a certificate trust anchor required to validate the server certificate. If the peer cannot verify that the server possesses the corresponding private key, or if the certificate presented by the server is unacceptable for any reason other than the lack of an appropriate trust anchor, the peer MUST NOT use this provisioning mode. Assuming that the server demonstrates possession of the private key, the peer continues with establishment of the tunnel (PEAPv2 part 2). As a result, it is possible that the TLS channel (PEAPv2 part 2) may be terminated by an attacker. The PEAPv2 Part 2 conversation is unchanged in this mode, except that the peer will only accept an EAP method supporting mutual authentication and key derivation that is compatible with its initial credentials (such as a password-based EAP method). The peer then uses the Crypto-Binding TLV to validate that the same server terminates both the TLS channel and the successfully completed EAP method, thereby verifying that the exchange was not subject to a man-in-the-middle attack. Assuming that the Crypto-Binding TLV exchange is successful, the peer will request for and the server will subsequently provide a credential, using the Credential-Payload TLV. Once the initial provisioning exchange completes, the peer is expected to use the provisioned credentials in subsequent PEAPv2 authentications, and SHOULD NOT use this provisioning mode. PEAPv2 servers implementing this provisioning mode MUST support the following additional ciphersuites, beyond those specified in Section 2.1.2: TLS_DH_anon_WITH_AES_128_CBC_SHA PEAPv2 peers implementing this provisioning mode MAY support the following additional ciphersuites, beyond those specified in Section 2.1.2: TLS_DH_anon_WITH_AES_128_CBC_SHA
Proposed Resolution: Accept
Issue 19: Editorial issues
Submitter:
Nancy Cam-Winget
Submitter email address:
ncamwing@cisco.com
Date first submitted:
June 24, 2004
Reference:
Document: PEAP-08
Comment type: E
Priority:
S
Section: Various
Rationale/Explanation of issue:
pg. 1 Abstract: change first sentence from
"....provides for support of multiple...."
to "....provides support for multiple...."
pg. 4 Introduction: change first sentence from
"....provides for support of multiple...."
to "....provides support for multiple...."
pg. 14 Section 2.1.3: The 8th paragraph may be missing a sentence?
pg. 22 2nd paragraph on page, the second line should change from
"...such a violation of TLV...."
to "...such as a violation of TLV...."
Technical Editorial
---------------------------
pg. 5 Standard key establishment: definition needs to clarify or highlight the
use of crypto binding to
prevent MitM attacks as well as the use of crypto binding to establish keying
material.
pg. 7 MSK and EMSK definition: please use the definitions from RFC 3748.
pg. 21 Section 2.3: 3rd condition should apply to both Intermediate and Final
Result TLVs, yes?
[Ashwinp] The proposed resolutions are:
pg. 1 Abstract: change first sentence from
"....provides for support of multiple...."
to "....provides support for multiple...."
pg. 4 Introduction: change first sentence from
"....provides for support of multiple...."
to "....provides support for multiple...."
pg. 14 Section 2.1.3: The 8th paragraph may be missing a sentence?
pg. 22 2nd paragraph on page, the second line should change from
"...such a violation of TLV...."
to "...such as a violation of TLV...."
pg. 7 MSK and EMSK definition: use the definitions from RFC 3748.
Master Session Key (MSK)
Keying material that is derived between the EAP
peer and server
and exported by the EAP method. The MSK is
at least 64 octets in
length. In existing implementations, a AAA
server acting as an
EAP server transports the MSK to the
authenticator.
Extended Master Session Key (EMSK)
Additional keying material derived between the
EAP client and
server that is exported by the EAP method.
The EMSK is at least
64 octets in length. The EMSK is not shared
with the
authenticator or any other third party. The
EMSK is reserved for
future uses that are not defined yet.
Issue 20: Meaning and Usage of Mandatory TLV
Submitter:
Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted:
July 2, 2004
Reference:
Document: PEAP-08
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
The definition of mandatory TLV is not clearly explained. We need to make
sure this is clear and the usage is consistent throughout the document.
[Hao Zhou] Here is the proposed resolution:
1. Change text in Section 4
" The mandatory bit in a TLV indicates that if the peer does not
support the TLV, it MUST send a NAK TLV in response; and all the
other TLVs in the message MUST be ignored. If an EAP peer finds an
unsupported TLV which is marked as optional, it MUST NOT send an NAK
TLV.
Note that a peer may support a TLV with the mandatory bit set, but
may not understand the contents. The appropriate response to a
supported TLV with content that is not understood is defined by the
TLV specification. "
To:
"The mandatory bit in a TLV indicates whether support of the TLV is required. If
the peer or
server does not
support the TLV, it MUST send a NAK TLV in response; and all the
other TLVs in the message MUST be ignored. If an EAP peer or server finds an
unsupported TLV which is marked as optional, it can ignore the unsupported TLV.
It MUST NOT
send an NAK TLV.
Note that a peer or server may support a TLV with the mandatory bit set, but
may not understand the contents. The appropriate response to a
supported TLV with content that is not understood is defined by the
TLV specification.
2. Section 4.4 Error TLV is defined as optional and is contradictory with the
following sentence:
"PEAPv2 implementations MUST support the Error TLV, which cannot be responded to
with a NAK
TLV." Suggest change to MAY or make Error TLV mandatory.
[Ashwinp] I don't see why we shouldn't make it Mandatory. Otherwise, seems fine.
[Hao Zhou] Agreed.
Proposed Resolution: Accept
Issue 21: Credential TLV Too General
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 7/6/2004
Reference:
Document: PEAP-08
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 4.18
Rationale/Explanation of issue:
Credential is a rather broad general term or concept. Labeling something as
a credential in a TLV doesn't really tell you much about it. It could be a
root CA certificate, an EAP-FAST PAC, an identity credential, an
application specific credential, .... All of these are very different and
would be handled differently. The extra layer of saying this is a
credential does not give much information. I think this may actually cause
problems if you try to make an API for TLV functions. The API would
probably have to special case on the crednetial TLV or deliver all
credentials to all callers, neither of which is good.
Requested change:
Replace Credential TLV with "Root Cert TLV". Do the same for any other use
cases we want to cover in this document (I don't know of any).
[Ashwinp] The proposal is to remove Credential TLV as a generic concept; and
restricts its use to exchange
a server-trusted-root.
Proposed changes
Change:
"Within a PEAPv2 part 2 conversation, a peer MAY request a credential
using a Credential-Payload TLV, and the EAP server MAY respond with a
Credential-payload TLV to the peer. Credentials can be exchanged in
regular authentication mode or initial-provisioning mode.
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP server by validating the Crypto-
Binding TLV, it MAY send one or more Credential-Payload TLVs (marked
as optional) to request credentials from the EAP server. The peer
may receive a credential, but is not required to use the credentials
received from the EAP server.
If the EAP server has determined that it has successfully
authenticated the peer and determined that the tunnel and inner EAP
methods were between the same peer and EAP server by validating the
Crypto-Binding TLV, then it MAY send one or more TLVs containing the
credentials (for example: PKCS#7 TLV, marked as optional):"
To:
"Within a PEAPv2 part 2 conversation, a peer MAY request a trusted root of
server certificate
using a Server-Trusted-Root TLV, and the EAP server MAY respond with a
Server-Trusted-Root TLV to the peer. The Server-Trusted-Root can be exchanged in
regular authentication mode or initial-provisioning mode.
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP server by validating the Crypto-
Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked
as optional) to request the trusted root of server certificate from the EAP
server. The peer
may receive a response, but is not required to use the trusted root
received from the EAP server.
If the EAP server has determined that it has successfully
authenticated the peer and determined that the tunnel and inner EAP
methods were between the same peer and EAP server by validating the
Crypto-Binding TLV, then it MAY respond with the
the server-trusted-root containing the PCKS#7 TLV "
2.
REPLACE "Assuming that the Crypto-Binding TLV exchange
is successful, the peer will request and the server will subsequently
provide a credential, using the Credential-Payload TLV"
WITH
"Assuming that the Crypto-Binding TLV exchange
is successful, the peer will request and the server will subsequently
provide a trusted root, using the Server-Trusted-Root TLV"
3.
REPLACE "Credential-Payload TLV" WITH "Server-Trusted-Root TLV" in the document.
4. REPLACE SECTION 4.18 Credential-Payload TLV with
4.18. Server-Trusted-Root TLV
The Server-Trusted-Root TLV allows the peer to send a request to the EAP
server for a trusted root in PKCS#7 format.
The Server-Trusted-Root TLV is always marked as optional, and cannot
be responded to with a NAK TLV. PEAPv2 server implementations that
claim to support provisioning MUST support Server-Trusted-Root TLV, PKCS#7 TLV,
and the
the PKCS#7-Server-Certificate-Root credential format defined in this TLV.
PEAPv2 peer implementations MAY NOT support this TLV.
The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
PEAP part 2 conversation), in both initial provisioning mode, and the
regular authentication process.
The peer MUST NOT request, or accept the trusted root sent inside the
Server-Root
credential TLV by EAP-server until it has completed authentication of EAP
server, and
validated the Crypto-Binding TLV. The peer may
receive a trusted root, but is not required to use the trusted root
received from the EAP server.
If the EAP server sets credential-format to PKCS#7-Server-Certificate-
Root, then the Server-Trusted-Root TLV MUST contain the root of the
certificate chain of the certificate issued to the EAP server
packages in a PKCS#7 TLV. If the Server certificate is a self-signed
certificate, then the root is the self-signed certificate. In this
case, the EAP server does not have to sign the certificate inside the
PCKS#7 TLV since it does not necessarily have to private key for it.
If the Server-Trusted-Root TLV credential format does not contain one of
the known values, then the EAP-server MUST ignore the value.
The Server-Trusted-Root TLV is defined as follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|
TLV Type |
Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
18
Length
>=2
Credential-Format
The Credential-Type field is two octets. Values include:
1 - PKCS#7-Server-Certificate-Root.
TLV
This field is of indefinite length. It can contains zero or more TLV associated
with the certificate-request.
5.
REPLACE SECTION 4.19 PCKS7#7 TLV with
"4.19. PKCS#7 TLV
The PKCS#7 TLV contains the PKCS #7 wrapped X.509
certificate. This field contains a certificate or certificate chain
in PKCS#7 [RFC2315] format requested by the peer.
The PKCS#7 TLV is always marked as optional, which cannot be
responded to with a NAK TLV. PEAPv2 server implementations that
claim to support provisioning MUST support this TLV. PEAPv2 peer
implementations MAY NOT support this TLV.
If the PKCS#7 TLV contains a certificate or certificate chain that is
not acceptable to the peer, then peer MUST ignore the value.
The PKCS#7 TLV is defined as follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|
TLV Type |
Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
20
Length
>=0
PKCS#7 Data
PKCS #7 wrapped X.509 certificate. This field contains a
certificate or certificate chain in PKCS#7 [RFC2315] format.
Proposed Resolution: Accept
Issue 22: Key Derivation
Submitter:
Nancy Cam-Winget
Submitter email address:
ncamwing@cisco.com
Date first submitted:
June 24, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 2.5
Rationale/Explanation of issue:
Insert the following text in Section 2.5:
"S-IMCK0 = tunnel keying material, ISKj = keying material resulting from the j-th EAP method
For j = 1 to n-1 do
IMCKj = T-PRF(S-IMCKj-1, "Inner Methods Compound Keys", ISKj, 60);
Where S-IMCKj are the first 40 octets of IMCKj
The last 20 octets of IMCKj map to the Compound MAC key use to generate the crypto-binding hashes.
On the last iteration, the final PEAPv2 keying material is then generated as such:
MSK = T-PRF(S-IMCKn, "Session Key Generating Function", OutputLength)
where OutputLength is the desired output length."
Action item: Nancy to send email to Dan Simon and CC PEAP alias about this issue.
To address comment 11 and 18, here is the proposed section 2.5 draft text that incorporates further optimizations to the current key derivations. The construction reduces the number of HMAC-SHA1 ops from 4 to 3, however the PRF calls are reduced to 1 vs 3. Only a single shared key is used for generating the compound MACs as opposed to two to further minimize the client requirements in both key generation as well as key cacheing. Finally, we are proposing this to stay closer to the EAP-FAST constructions.....
2.5. Key derivation
Since the normal TLS keys are used in the handshake, and therefore
should not be used in a different context, new keys must be derived
from the TLS master secret to protect the conversation within the PEAPv2 tunnel.
Instead of deriving keys specific to link layer ciphersuites, EAP
methods provides a Master Session Key (MSK) used to derive keys in a
link layer specific manner. The method used to extract ciphering
keys from the MSK is beyond the scope of this document.
PEAPv2 also derives an Extended Master Session Key (EMSK) which is
reserved for use in deriving keys in other ciphering applications.
This draft also does not discuss the format of the attributes used to
communicate the master session keys from the backend authentication
server to the NAS; examples of such attributes are provided in
[RFC2548].
PEAPv2 combines key material from the TLS exchange with key material
from inner key generating EAP methods to provide stronger keys and to
bind inner authentication mechanisms to the TLS tunnel. Both the
peer and EAP server MUST derive compound MAC and compound session
keys using the procedure described below.
The input for the cryptographic binding includes the following:
[a] The keys used to protect the PEAPv2 tunnel are calculated using the same construction as defined by TLS (RFC 2246 section 6.3). Additionally, a 40 octet tunnel key (TK) is also derived as keying material used to cryptographically bind the tunnel to subsequent EAP methods. Thus, using the TLS construction, the generated keying material is defined as:
key_block = PRF(master_secret, "key expansion", server_random + client_random)
where ‘+’ denotes concatenation.
The key_block is partitioned as follows:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
TK[seed_size= 40]
Where the client_write_MAC_secret and server_write_MAC_secret are the keys used by the client and server to authenticate the tunnel messages respectively. Similarly, the client_write_key and client_write_IV are used by the client to provide message confidentiality while the server uses the server_write_key and server_write_IV to achieve confidentiality. The TK is used to derive the compound MAC and compound session keys.
[b] The first 32 octets of the MSK provided by each successful inner EAP method ;for each successful EAP method completed within the tunnel.
ISK1..ISKn are the MSK portion of the EAP keying material obtained
from methods 1 to n. The ISKj shall be the first 32 octets of the generated MSK of the jth EAP method. If no keying material is provided for the EAP method, then ISKj shall be set to zero (e.g. 32 octets of 0x00)
The PRF algorithm is based on PRF+ from IKEv2 shown below ("|" denotes concatenation)
K = Key, S = Seed, LEN = output length
PRF+ (K,S,LEN) = T1 | T2 | T3 | T4 | ... where:
T1 = HMAC-SHA1(K, S | len | 0x01)
T2 = HMAC-SHA1 (K, T1 | S | len | 0x02)
T3 = HMAC-SHA1 (K, T2 | S | len | 0x03)
T4 = HMAC-SHA1 (K, T3 | S | len | 0x04)
...
The intermediate combined key is generated after each successful EAP
method inside the tunnel.
Generating the intermediate combined key:
S-IPMK0 = TK
for j = 1 to k do
IPMKj = PRF+ (S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60);
Where S-IPMKj are the first 40 octets of IPMKj
And CMKj are the last 20 octets of IPMKj used to generate the intermediate Compound MACs
k = the last successful EAP method inside the tunnel at the point
where the combined MAC key is derived.
Each IPMKj output is 60 octets. The first 40 octets are used as the key input to the succeeding IPMK(j+1) derivation and the latter 20 octets are used as the key, CMKj, used to generate the intermediate Crypto-Binding Compound MAC value at the jth EAP method.
Compound Session Key derivation:
The compound session key (CSK) is derived on both the peer and EAP
server.
MSK = PRF+ (S-IPMKn, "Session Key Generating Function", OutputLength)
The output length of the CSK must be at least 128 bytes. The first
64 octets are taken and the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in [RFC2284bis].
Since we are proposing to only require one shared key for the compound MACs, Section 4.6 Crypto-Binding TLV will need to be updated:
From pg. 36 description of Compound MAC “…output using the CMK_B1 or CMK_B2…”
To “…output using the CMK…”
[Dan Simon]
I looked over part (b) of the proposed
changes to the key
derivation section. It looks fine, with one caveat: it's
difficult to judge, based on the somewhat opaque definition
of the crypto-binding TLV, whether it might be possible that
the two MACs could ever be identical. Would it bother
anybody if an extra text label were concatenated to the MAC
input string--say, at the very beginning--that would be
defined as different for the two MACs? That would provide a
simple guarantee that the use of a single MAC key is safe.
[Hao Zhou] Would some strong
text forcing the two NONCEs to be different achieve the
same thing? How about adding "The S_NONCE and C_NONCE MUST be different.
If
they are the same, it is considered a tunnel compromise error." to the
end
of following section:
Nonce
The Nonce field is 32 octets. It contains a 256 bit nonce that is
temporally unique, used for compound MAC key derivation at each
end. This is the S_NONCE for the B1 message and a C_NONCE for the
B2 message.
[Dan Simon] I'm confused--which MACs
incorporate which nonce(s)? And which nonce(s) is/are included in the
(now
one common) MAC key derivation? The draft doesn't seem to be clear.
Certainly, the second nonce sent
can't be incorporated into the first MAC sent, since the former hasn't
been received yet. That also
excludes it from the common MAC key derivation, for the same reason.
That suggests that the nonces are
no longer being used to prove freshness and distinctness, and are really
only being used as labels--in
which case they might as well be explicit label strings, mandated to be
different.
[Hao Zhou] You are right that no
NONCES are included in the common MAC Key calculation.
But they are included in the Compound MAC calculation. Wouldn't two
random
number provide better freshness and distinctness than two fixed labels?
And
because of the common MAC key, these NONCES have to be different to
prevent
replay attack.
[Joe Salowey] They way the nonces are
being used they don't really provide freshness, we had this argument a
long time ago with the key binding draft.
[Nancy Cam-Winget]
Here is my understanding:
* the server incorporates S_NONCE in it's TLV
* the client incorporates C_NONCE in it's TLV
* the requesting Crypto-Binding TLV must set it's Sub-Type to 0
* the responding Crypto-Binding TLV must set it's Sub-Type to 1
To your original caveat, where the Nonce's should not be identical, I
agree.....but I am assuming the S_NONCE and C_NONCE are to prove
liveness of
the Crypto-Bind exchange not to contribute to the key derivation. With
that, only the first (requestor's) Nonce needs to be random but the
responding one must be either:
a. the same as the requestor's Nonce
b. some function of the requestor's Nonce, for instance: requestor's
Nonce XOR 1
If we believe TLV differentiation between the requestor and responder is
achieved through the Sub-Type field, then option (a) is acceptable;
otherwise we have to construct (b).
However, I think these are orthogonal to how the CMK's are derived. That
is, so long as we adhere to the above rules, I believe that we can still
retain a single CMK key and use it to hash both requesting and
responding
Crypto-Binding TLVs (unless you believe HMAC-SHA1 has other
weaknesses!).
Finally, I do not see the value the Nonces provide as the freshness is
coming from all the key contributions from TK to ISKj's.
Does that help or confuse further?
[Nancy Cam-Winget]
I need help understanding RFC 2716
Section 3.5 (Key Derivation) and how it
maps to the TK. The text is very slanted towards the PPP model and makes
explicit reference to how the keys are generated for PPP encryption. If
I
understand from this morning, you would like to use this key
construction as
the "MSK" or in PEAPv2 as the TK, correct?
However, as Section 3.5 puts its key derivation in terms of (quoted from
RFC2716):
(1) the derivation proceeds as follows:
given the master secret negotiated by the TLS handshake, the
pseudorandom function (PRF) defined in the specification for the
version of TLS in use, and the value random defined as the
concatenation of the handshake message fields client_hello.random and
server_hello.random (in that order), the value PRF(master secret,
"client EAP encryption", random) is computed up to 128 bytes, and the
value PRF("", "client EAP encryption", random) is computed up to 64
bytes (where "" is an empty string).
(2) Peer Encryption Key
(3) EAP Server Encryption Key
(4) Client Authentication Key
(5) EAP Server Authentication Key
....and other key material such as IV
So, for the TK, is the intent to compose the TK as 64 octets where:
TK = Peer Encryption Key | EAP Server Encryption Key
Can you please confirm? I would like to explicitly state the mapping in
the
PEAPv2 draft.
[Nancy Cam-Winget] Here is the proposed resolution:
Replace Section 2.5 with the
following:
2.5. Key derivation
Since the normal TLS keys are used in the handshake, and therefore
should not be used in a different context, new keys must be derived
from the TLS master secret to protect the conversation within the PEAPv2
tunnel.
Instead of deriving keys specific to link layer ciphersuites, EAP
methods provides a Master Session Key (MSK) used to derive keys in a
link layer specific manner. The method used to extract ciphering
keys from the MSK is beyond the scope of this document.
PEAPv2 also derives an Extended Master Session Key (EMSK) which is
reserved for use in deriving keys in other ciphering applications.
This draft also does not discuss the format of the attributes used to
communicate the master session keys from the backend authentication
server to the NAS; examples of such attributes are provided in
[RFC2548].
PEAPv2 combines key material from the TLS exchange with key material
from inner key generating EAP methods to provide stronger keys and to
bind inner authentication mechanisms to the TLS tunnel. Both the
peer and EAP server MUST derive compound MAC and compound session
keys using the procedure described below.
The input for the cryptographic binding includes the following:
[a] The PEAPv2 tunnel key (TK) is calculated using the first 40 octets
of the (secret) key
material generated as described in the EAP-TLS algorithm ([RFC2716]
Section 3.5). More
explicitly, the TK is the first 40 octets of the PRF as defined in
[RFC2716]:
PRF(master secret,"client EAP encryption", random)
Where random is the concatenation of client_hello.random and
server_hello.random
[b] The first 32 octets of the MSK provided by each successful inner EAP
method ;for each
successful EAP method completed within the tunnel.
ISK1..ISKn are the MSK portion of the EAP keying material obtained
from methods 1 to n. The ISKj shall be the first 32 octets of the
generated MSK of the jth
EAP method. If the MSK length is less than 32 octets, it shall be padded
with 0x00's to ensure
the MSK is 32 octets. Similarly, if no keying material is provided for
the EAP method, then ISKj
shall be set to zero (e.g. 32 octets of 0x00).
The PRF algorithm is based on PRF+ from IKEv2 shown below ("|" denotes
concatenation)
K = Key, S = Seed, LEN = output length
PRF+ (K,S,LEN) = T1 | T2 | T3 | T4 | ... where:
T1 = HMAC-SHA1(K, S | len | 0x01)
T2 = HMAC-SHA1 (K, T1 | S | len | 0x02)
T3 = HMAC-SHA1 (K, T2 | S | len | 0x03)
T4 = HMAC-SHA1 (K, T3 | S | len | 0x04)
...
The intermediate combined key is generated after each successful EAP
method inside the tunnel.
Generating the intermediate combined key:
S-IPMK0 = TK
for j = 1 to k do
IPMKj = PRF+(S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60);
Where S-IPMKj are the first 40 octets of IPMKj
And CMKj are the last 20 octets of IPMKj used to generate the
intermediate Compound MACs
k = the last successful EAP method inside the tunnel at the point
where the combined MAC key is derived.
Each IPMKj output is 60 octets. The first 40 octets are used as the key
input to the
succeeding IPMK(j+1) derivation and the latter 20 octets are used as the
key, CMKj, used to
generate the intermediate Crypto-Binding Compound MAC value at the jth
EAP method.
Compound Session Key derivation:
The compound session key (CSK) is derived on both the peer and EAP
server.
CSK = PRF+(S-IPMKn, "Session Key Generating Function", OutputLength)
The output length of the CSK must be at least 128 bytes. The first
64 octets are taken and the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in [RFC2284bis].
Since we are proposing to only require one shared key for the compound
MACs, Section 4.6
Crypto-Binding TLV will need to be updated:
From pg. 36 description of Compound MAC "...output using the CMK_B1 or
CMK_B2..."
To "...output using the CMK..."
Proposed Resolution: Accept
Issue 23: More Comments
Submitter: Hao
Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
Technical:
1. Section 1, Page 5, Initial provisioning mode. It seems it only describes
certificate based
cipher suite. It can be changed to "peer only confirms server's possession
of the private key
corresponding to the public key , but does not otherwise validate the server
authenticity." I
don't know if we need to describe that in the introduction section. Suggest
remove it totally as
provisioning was covered in Credential provisioning header.
[Ashwinp] Agreed.
2. Optimized session resumption described in Abstract is not explained in
the draft. There is a
section titled "Optimized for light weight devices". I am not sure they are
talking about the
same thing. Suggestion: either remove the mention of "optimized session
resume" from abstract or
provide explanation.
[Ashwinp] Remove optimized for session resume.
3. Section 2.1.2, "If the full TLS handshake is performed, then the first
payload of PEAPv2 part
2 is sent along with finished handshake message to reduce number of round
trips." Is it a "MUST",
"MAY" or "SHOULD"? Suggest change "is" to "SHOULD". We have EAP-FAST
implementation that doesn't
do that. Same in Section 2.2 first paragraph.
[Ashwinp] Change to MAY.
4. Section 2.1 "If the PEAP server does not support the version number
proposed by the PEAP peer,
it terminates the conversation, as described in Section 2.2.2." Section
2.2.2 describes protected
termination, which doesn't apply here. Suggest change to "it either starts a
different EAP type
or terminates the conversation by sending EAP-Failure, depends on the server
policy."
[Ashwinp] Leave this issue out. Maybe outside scope of PEAP. -->. If peer
proposes a version that is not supported by server, then the server
terminates the conversation by sending EAP-Failure. if the server
proposes a version that is not acceptable tot client, then client can
NAK the request to start a different EAP type or terminate the
conversation by sending EAP-Failure.
5. Section 5.1, "The EAP-type in the clear could modified in other PEAP
packets." Change it
to "The EAP-type in the clear could be modified in other PEAP packets and
will likely result in
failure, hence are not included in crypto-binding".
[Ashwinp] OK.
6. Section 5.12.1, last two paragraphs are duplicated in Section 5.12.
Suggest merge these two
section together.
[Ashwinp] OK.
Editorial:
1. Section 1, Page 4. Standard key establishment, Section 6.8 should be 5.8
now.
[Ashwinp] OK.
2. Section 5.12, "Devices such as regular operating systems typically
support secure
provisioning and secure credential storage capabilities, for example
regular operating systems; and hence initial provisioning mode is not
recommended for these systems." Regular operating system are duplicated.
this sentence needs to
be revised.
[Ashwinp] OK.
Proposed Resolution: Accept
Issue 24: Cleanup of Provisioning Mode
Submitter:
Ashwin Palekar
Submitter email address:
Ashwinp@microsoft.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 2.2.10
Rationale/Explanation of issue:
Provisioning Mode depends on server policy, access can be granted or denied based on combinations of which provision mode was in, which types of credentials have been provisioned, and certain inner EAP methods have been run, etc. Also change all mentioning of "initial provisioning mode" in the draft.
[Ashwinp]
1. "this provisioning mode" could imply mode a or b. We should be more explicit to avoid confusion. Call it "provisioning mode with unauthenticated tunnel"? 2. Replace ""initial provisioning mode" with "provisioning mode b" or "provisioning mode with unauthenticated tunnel". 3. The text needs to be revised to align with the proposed fix for Credential-payload-tlv (the issue in another email thread).
Proposed Resolution: Discuss
Issue 25: Numbering of TLVs
Submitter:
Ashwin Palekar
Submitter email address:
Ashwinp@microsoft.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
This is an issue about the consistent numbering of TLVs.
[Hao]
Proposed Resolution: Accept
Issue 26: Cleanup of Server-Trusted-Root and PKCS#7
TLVs
Submitter: Ashwin Palekar
Submitter email address:
Ashwinp@microsoft.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 4.18
Rationale/Explanation of issue:
[Hao Zhou] Why do we still need two TLVs? Can we just use Server-Trusted-Root
TLV with Credential-Format and
Data field? If Credential-Format is PKCS#7, then data is PKCS#7 wrapped X.509
certificate. Do we
foresee multiple certificates in the Server-Trusted-Root?
[Ashwinp] I assumed multiple certificate "formats" that could be used to
package the trusted-root of server
cert. If there aren't multiple certificate formats, then it could be reduced to
a single TLV.
Plus, with this approach, the PKCS#7 TLV can be reused by other TLVs in future.
[Joe Salowey] It's been a little while since I looked at PKCS#7, but from
what I remember it is a
generic format for cryptographically protected messages. It is not specific to
the transport of
certificates. So I think it is probably OK to have it separate out the format.
I think there is an additional issue as to how exactly the cetificates are
enclosed in PKCS#7
format. I think this needs to be specified. I think there is a spec somewhere,
but I don't
remember what it is. I don't think just saying PKCS#7 is a full specification
(although it is
probably good enough for this draft).
[Ashwinp] 1. we should separate the format field.
2. Since PKCS#7 format can be used for many reasons, we may need to specify what
options are
allowed and not allowed. However, I could not find a good reference that does
this. For example,
the PIC draft does not mention anything other than PKCS#7.
http://www.drizzle.com/~aboba/IEEE/draft-ietf-ipsra-pic-06.txt
[Joe Salowey] Perhaps it is OK, let's use it right now and we can look into it at some later point.
[Ashwinp]
These are the proposed changes:
1. REPLACE "Within a PEAPv2 part 2 conversation, a peer MAY request a credential
using a Credential-Payload TLV, and the EAP server MAY respond with a
Credential-payload TLV to the peer. Credentials can be exchanged in
regular authentication mode or initial-provisioning mode.
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP server by validating the Crypto-
Binding TLV, it MAY send one or more Credential-Payload TLVs (marked
as optional) to request credentials from the EAP server. The peer
may receive a credential, but is not required to use the credentials
received from the EAP server.
If the EAP server has determined that it has successfully
authenticated the peer and determined that the tunnel and inner EAP
methods were between the same peer and EAP server by validating the
Crypto-Binding TLV, then it MAY send one or more TLVs containing the
credentials (for example: PKCS#7 TLV, marked as optional):"WITH
"Within a PEAPv2 part 2 conversation, a peer MAY request a trusted root of server certificate
using a Server-Trusted-Root TLV, and the EAP server MAY respond with a
Server-Trusted-Root TLV to the peer. The Server-Trusted-Root can be exchanged in
regular authentication mode or initial-provisioning mode.
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP server by validating the Crypto-
Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked
as optional) to request the trusted root of server certificate from the EAP server. The peer
may receive a response, but is not required to use the trusted root
received from the EAP server.
If the EAP server has determined that it has successfully
authenticated the peer and determined that the tunnel and inner EAP
methods were between the same peer and EAP server by validating the
Crypto-Binding TLV, then it MAY respond with the
the server-trusted-root containing the PCKS#7 TLV "2. REPLACE "Assuming that the Crypto-Binding TLV exchange
is successful, the peer will request and the server will subsequently
provide a credential, using the Credential-Payload TLV"WITH
"Assuming that the Crypto-Binding TLV exchange
is successful, the peer will request and the server will subsequently
provide a trusted root, using the Server-Trusted-Root TLV"3. REPLACE "Credential-Payload TLV" WITH "Server-Trusted-Root TLV" in the document
4. REPLACE SECTION 4.18 Credential-Payload TLV with
4.18. Server-Trusted-Root TLV
The Server-Trusted-Root TLV allows the peer to send a request to the EAP
server for a trusted root in PKCS#7 format.
The Server-Trusted-Root TLV is always marked as optional, and cannot
be responded to with a NAK TLV. PEAPv2 server implementations that
claim to support provisioning MUST support Server-Trusted-Root TLV, PKCS#7 TLV, and thethe PKCS#7-Server-Certificate-Root credential format defined in this TLV.
PEAPv2 peer implementations MAY NOT support this TLV.
The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
PEAP part 2 conversation), in both initial provisioning mode, and the
regular authentication process.The peer MUST NOT request, or accept the trusted root sent inside the Server-Root credential TLV by EAP-
server until it has completed authentication of EAP server, and
validated the Crypto-Binding TLV. The peer may
receive a trusted root, but is not required to use the trusted root
received from the EAP server.
If the EAP server sets credential-format to PKCS#7-Server-Certificate-
Root, then the Server-Trusted-Root TLV MUST contain the root of the
certificate chain of the certificate issued to the EAP server
packages in a PKCS#7 TLV. If the Server certificate is a self-signed
certificate, then the root is the self-signed certificate. In this
case, the EAP server does not have to sign the certificate inside the
PCKS#7 TLV since it does not necessarily have to private key for it.
If the Server-Trusted-Root TLV credential format does not contain one of
the known values, then the EAP-server MUST ignore the value.
The Server-Trusted-Root TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
18
Length
>=2
Credential-Format
The Credential-Type field is two octets. Values include:
1 - PKCS#7-Server-Certificate-Root.
TLV
This field is of indefinite length. It can contains zero or more TLV associated
with the certificate-request.5. REPLACE SECTION 4.19 PCKS7#7 TLV with
"4.19. PKCS#7 TLV
The PKCS#7 TLV contains the PKCS #7 wrapped X.509
certificate. This field contains a certificate or certificate chain
in PKCS#7 [RFC2315] format requested by the peer.
The PKCS#7 TLV is always marked as optional, which cannot be
responded to with a NAK TLV. PEAPv2 server implementations that
claim to support provisioning MUST support this TLV. PEAPv2 peer
implementations MAY NOT support this TLV.
If the PKCS#7 TLV contains a certificate or certificate chain that is
not acceptable to the peer, then peer MUST ignore the value.
The PKCS#7 TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
20
Length
>=0
PKCS#7 Data
PKCS #7 wrapped X.509 certificate. This field contains a
certificate or certificate chain in PKCS#7 [RFC2315] format.
Proposed Resolution: Accept
Issue 27: IANA Considerations
Submitter: Hao
Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 6
Rationale/Explanation of issue:
Need IANA assignment policy for Identity Type TLV, Credential Format Type
for
Server-Trusted-Root TLV, Request Action TLV,
[Ashwinp] Make it consistent with TLV registration. We should require
registration and designated expert with specification required for all
the above TLV values.
[Ashwinp] The IANA considerations (spec required et al) need to apply to TLV type values as well.
REPLACE the name space registration text with " The following name spaces in PEAPv2 require registration:TLV-Types, Identity-Type field of Identity-Type TLV, Credential-Format field of Server-Trusted-Root TLV, Action field of Request-Action TLV. The values assigned to TLV types Vendor-Specific TLV type codes do not require registration."In section recommended registration policies replace the text with:"Additional TLV type codes, Identity-Types, Credential-Formats, Actions may be allocated following Designated Expert with Specification Required [RFC2434].
Proposed Resolution: Accept
Issue 28: Separator
Submitter: Hao
Zhou
Submitter email address: hzhou@cisco.com
Date first submitted: July
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: 4.13, 4.14
Rationale/Explanation of issue:
There is an open issue in Section 4.13 and 4.14:
Does the use of a ":" separator make sense even if an IPv6 address is used?
[Ashwinp] Leave it as open.
[Joe Salowey] Specify use of RFC 2373 and use a space as a separator between the IPv6 address and the FQDN.
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
Proposed Resolution: Accept
Issue 29: Miscellaneous Cleanup
Submitter:
Ashwin Palekar
Submitter email address:
ashwinp@microsoft.com
Date
first submitted: August
8, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
Replace "initial provisioning mode" and "provisioning mode B" WITH "server unauthenticated tunnel provisioning mode"
In section 4.20.1 remove this line0 0-1 0 0 Server-Trusted-Root TLV
Proposed Resolution: Accept
Issue 30: Questions
Submitter:
Elena Demaria
Submitter email address:
Elena.Demaria@tilab.com
Date
first submitted: September 10, 2004
Reference:
Document: PEAP-08
Comment type: T
Priority:
S
Section: Various
Rationale/Explanation of issue:
I have a pair of questions on implementation of PEAPv2
(draft-josefsson-pppext-eap-tls-eap-08).
In section 2.2.2 it is written:
"Even if Crypto-Binding TLVs have been exchanged in previous
conversations, the Crypto-Binding TLV MUST be included in both
protected
success/failure (Result TLV) indications."
Section 4.5, instead, states:
" The Crypto-Binding TLV MUST be used to perform Cryptographic
Binding
after each successful EAP method in a sequence of EAP methods is
complete in PEAPv2 part 2. The Crypto-Binding TLV can also be
used
during Protected Termination."
Is the exchange of a Crypto-Binding TLV a MUST in the
Protected
Termination phase, or it is used only after a successful EAP
method?
Normally a protected termination follows an EAP method but
this is not
always the case as in draft-giaretta-mip6-authorization-eap-01
where
after the EAP inner method there is an exchange of TLVs that do
not
transport EAP authentication methods but MIPv6 configuration
parameters.
If the crypto binding exchange in the Protected Termination
phase is a
MUST I assume that in the case described in draft-giaretta the
final
crypto-binding is derived using a null key. Is it correct?
In section 2.5 (key derivation) is shown the prf algorithm to be
used:
"The PRF algorithm is based on PRF+ from IKEv2 shown below
("|"
denotes concatenation)
K = Key, S = Seed, LEN = output length
PRF+ (K,S,LEN) = T1 | T2 | T3 | T4 | ... where:
T1 = HMAC-SHA1(K, S | len | 0x01)
T2 = HMAC-SHA1 (K, T1 | S | len | 0x02)
T3 = HMAC-SHA1 (K, T2 | S | len | 0x03)
T4 = HMAC-SHA1 (K, T3 | S | len | 0x04)
..."
What is "len"?
[AP] This is the output length specified in the key generation algorithm.
[HZ] Yes. We should change "len" to "LEN" for consistency and to
eliminate confusion. I guess that len is the (ASCII) decimal representation
of LEN. Thus LEN = 60 -- len = "60" (0x3630)
Otherwise, I can't imagine how to concatenate LEN with
the rest of the seed. Is this correct?
[Elena] Some further comments.
1)I assume that the hex value in your example is 0x3c (hex
value which corresponds to 60).
[Simon Josefsson] Right. We should clarify that LEN should be a binary
encoding of the length in one octet.
2) If we assume to memorize LEN value in an octet (as it
seems reading your e-mail) the maximum value is 255 (0xff). May it be a problem?
[Simon Josefsson] Also right. We should explicitly mention this limitation.
However, what application need to generate more output? I'm
not sure I see a need to address the limitation.
[HZ] LEN should be the actual length in octets, i.e., 0x60 in
your example. It should be concatenated directly just like 0x01, 0x02 after it.
The
label in the PRF function is treated as binary form, not ASCII.
Proposed Resolution: Accept
Issue 31: "Issue:" Cleanup
Submitter:
Bernard Aboba
Submitter email address:
aboba@internaut.com
Date
first submitted: October 14, 2004
Reference:
Document: PEAP-09
Comment type: E
Priority:
S
Section: 4.2 and others
Rationale/Explanation of issue:
Question: Have we
resolved all the issues denoted with "Issue:" in the
draft text? Here is a listing of these "Issue Bugs":
1215: [Issue] Can the peer use some other TLS alert to indicate the failure
[HZ] This is Issue 2, marked as resolved. My feeling is that this is same to
any certificate based cipher suite, if peer doesn't validate the server
certificate and continue, server will not know otherwise.
1220: [Issue] Since the server does not know upfront that the peer has
[HZ] This is Issue 3, marked a resolved. See the resolution note.
2144: [Issue] The length in the TLS payload TLV will not be included in
[HZ] I thought we concluded that TLS total length is only used for
guideline, the fragmented TLS data is still protected by the TLS. So it's no
harm not including the total length in the crypto-binding. That's discussed
in issue 5, marked as resolved.
2154: [Issue] if Outer-TLVs are modified, it compound MAC would fail; but
[HZ] That's Issue 6, marked as resolved.
2499: [Issue] Does the use of a ":" separator make sense even if an IPv6
2572: [Issue] Does the use of a ":" separator make sense even if an IPv6
[HZ] Issue 28. I thought we agreed on space character " ". We just need to
check on the internationalization of the FQDN.
3754: [Issue] Reporting??
[HZ] Issue 7? Don't see it anymore.
4089: [Issue] The examples have not been changed to show outer TLVs.
[HZ] It's Issue 1, please see resolution note. Ashwin added an example of
the outer-TLV.
Section 4.2 of the TLS
Payload TLV should be deleted. It's no longer needed.
Please remove all references of TLS Payload in the draft (there are a few).
[Bernard Aboba] Removal of Section 4.2 will also require renumbering of other sections and fixing of references within the draft.
Proposed Resolution: Accept