-----BEGIN PGP SIGNED MESSAGE-----
A1) please include real packet dumps, including encrypted data
with keys, to help people.
A2) There is no per-attribute description/reference.
-> AT_VERSION_LIST for instance has no reference.
A3) paragraph 1 of 5.2. This conversation seems totally out of
place, and very confusing.
A4) The definitions of the attributes seems to be partially defined
only in the scenarios of sections 9-15. I would rather the
attributes were defined seperately from the messages in which
they are used. Otherwise, it appears that one has to code per-message
marshalling/etc. It is hard to tell if this is true or not.
A5) It was not at all obvious that the AT_MAC is a keyed operation.
The last sentence of 8.1 says so, but I missed it at least twice,
thinking, but, it must be keyed, I remembered reading about it.
Maybe this is just the way that I read the document.
A5b) Annex A/B might be a little more detailed.
In particular, I think that you have chosen G to be SHA1, but
I'm not particularly certain.
Nor do I understahe what "m" is, or what the "optional user input"
is in this context.
A6) split normative and informative references.
A7) section 3, overview, para 3.
It seemed that this was the only place that the value of the Start
subtype was clearly stated.
A8) section 5.1, page 9,
> In this case, the permanent username MUST be of the format "1imsi".
It took me awhile to understand that the thing in quotes is a
pattern, not a string. Please remove "", or use another notation.
A9) section 5.1, page 9, para 4.
This seems really nebulous.
A10) section 5.2, first paragraph.
It seems that you are putting the most complicated "gotcha"
at the beginning. At this point, I don't even know what you are
talking about yet!
A11) time-sequence diagrams. They are simply not useful to me. They just
seem to take lots of space.
They are useful when there are more than two parties.
A12) section 5.1, 5.2 and 5.3 should have *NO* mention of
re-authentication. Please describe the base protocol first,
(including state machines), and then give the version that
supports re-authentication.
A13) section 5.3, page 15, para 7.
" A received AT_PERMANENT_ID_REQ does not necessarily originate from "
The advice given seems very complicated and very dubious to me.
I believe that this must come out from the client state machine.
A14) section 6.
Caveat: I read this much less carefully.
page 22, para 4:
"
Re-authentication identities are one-time identities. If the client
does not receive a new re-authentication identity, it MUST use
either the permanent identity or a pseudonym identity on the next
authentication to initiate full authentication.
"
Given that the identity is involved in the AT_MACs, are there
any cryptographic restrictions on the one-time identities?
A15) section 7. basic format.
What if length == 0. Malformed packet.
Then what?
A16) section 7. 0/127, 128-255 as "skippable".
I recommend that you adopt the terminology from IKEv2.
The high bit is the "critical" bit (or in this case, the
"non-critical" bit).
A17) section 8.2. AT_CHECKCODE.
This whole concept seems very fragile to me.
In particular, the whole concept of round trips could be much better
explained. Remember that there are multiple entities that
re-transimit: 802.11, LCP, Radius, etc.
EAP re-transmits seem to be server driven.
Radius re-transmits are client driven.
A18) Is AT_CHECKCODE cumulative, or does it just protect the SIM/Start
message?
A19) What if it is known that the encapsulator provides integrity
protection and privacy? I.e. IKEv2?
A20) section 10.
I'd like to see real numbers in the entire packet.
Hex dumps.
The code/id/Length/etc. break out seems to take way more white
space that it provides value.
A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general.
What about UTF-8? Internationalization?
A22) section 18.
This seems to be the only place that there is a table of
values. I guess that is okay, but I found it hard to find.
I'd like to see a table with brief explanations of each
attribue back in section 10 or earlier.
A23) security considerations seem very well written. Good work!
A24) Annex B. I found it to be clear as MUD. I guess I don't
code very often to FIPS documents, are they all so obtuse?
C code for this PRF would be welcome, along with test vectors.
When I get mine working, I'll be happy to contribute them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat
iQCVAwUBP2YUp4qHRg3pndX9AQFIHAP+KQgZHhvCtMe8FQc36Mp/0nbO8ISOzHx3
ruoDdA4jmZCyIwtftP1XqVuWP+Kjr40gl63gaqFpqmglQTj9j1f5lyQlsNPGMrfj
2ndNlhGN7HigTgkmOFWkeyzHXNfmcA2IVUZv7ev2CBKBqo98H0N01xHrne1XyKTS
SdSAyzz8SWw=
=JIMR
-----END PGP SIGNATURE-----
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
