> On Fri, 2016-09-16 at 16:30 +0100, David Woodhouse wrote:
>> On Fri, 2016-09-16 at 15:07 +0200, Nikos Mavrogiannopoulos wrote:
>> >
>> >
>> > Ok. For openconnect client it would be fairly easy to handle this,
>> > only send an extension with fairly static data, as it only sends a
>> > username. However, there is a catch, we should do that for both
>> > openssl and gnutls. Ocserv would require to be able to parse the
>> > TLS
>> > client hello since the extension data are in variable positions,
>> > however that shouldn't be really hard. I could do the ocserv part
>> > and
>> > the gnutls part if you do the openssl part :)
>> Have I got the actual payload of the extension right? I've done it as
>> an ASN.1 SEQUENCE containing one or more (in our case just one) ASN.1
>> OCTET-STRINGs each with an identity.
>
>
> opaque psk_identity<1..2^16-1>;
> psk_identity identity_list<1..2^16-1>;
>
> That means that for id 'psk' you have:
>
> |uint16(size of psk + 2)||uint16(size of psk)||psk|
>
> or |uint16(5)||uint16(3)||psk|
> ? ? ? 2-bytes ?2-bytes ? ?3-bytes
>
> Where the uint16 is in big-endian order.
More generally, since the client can propose multiple identities, it is...
uint16 10015 // provisional extension ID
uint16 extlen // all extensions have a length of their payload
... then the payload contains what you talked about above...
uint16 entirely_redundant_payload_len_again == extlen-2
uint16 ident1_len
char "dave"
uint16 ident2-len
char "nikos"
...
Can we ditch the first in uint16 in payload, given that it is entirely
redundant? Or am I misreading the spec to put it there in the first place,
and the formal language is supposed to *include* what I called 'extlen'
above?
--
dwmw2
