|
Thank you for your kindnes, I think I have to use
more time on this to understand what you are doing, both. I am so nuts.
It's long time since I have programmed, maybe 10 years, when I study
elektronics. I am only a 33 years Norwegian, but I have to refresh my
programmingtecniq anyway.
But I'am working with it, and I am getting to
find out how it works, as I allways do.
I am also working with a web that uses ASP to make
an useraccount. But I only have it in my mind. Using vbscript.
seeyou.. all.., I'll be back..soon.
I'm also with an active thread on
microsoft.public.win32.programmer.networks with the
subject "Wireless Provisioning Services and IAS Authorization DLL" there is
some new informations.
Washington Moreira
> Ok, as near as
I can tell, there is no BINARY data type in Microsoft's
>
implementation of C. So, that means we need a USHORT for the first field in
> the packet, followed by two UCHARs. In the Result packets, there
should be
> three USHORTs instead of one UCHAR and two USHORTs.
>
> Unfortunately, I won't be able to test the new packet structure until
> tomorrow. But, I surmise that we will still get the same error, as I
do not
> believe the error code 87 has anything to do with the
structure of the data
> (but I could be wrong on this point).
>
> Also, on my way home yesterday, I made a realization: the documents
I've
> read state that the EAP attributes are in an array terminated by
a
> raatMinimum entry. That means, if we want to add one value, we
actually need
> to add two. The first one is an EAP-TLV URI entry and
the second is a
> raatMinimum entry to denote the end of the array.
Therefore, my code should
> actually malloc enough space for the
EAP-TLV URI with the URL in it plus
> enough space for a raatMinimum
entry to terminate the array. It should all
> be one contiguous block
of memory and the lpValue should point to the
> beginning of that block
of allocated memory.
>
> This is all assuming I have correctly
understood what I've read. The
> documents are not very specific and
don't offer any examples.
>
>
> "Eliot Gable"
<support8@xxxxxxxxxxxxxx> wrote in
message
> news:F66dnfaCcvFqKRDeRVn-jg@xxxxxxxxxxx...
>> You're right; we're both loosing our minds. That should
be a u16 for the
>> first one. Although, the second two, according
to the WPS Deployment
>> document, should be UCHAR data types. Now,
it actually specifies BINARY
>> data type for the first 3, but I
don't know how it would know what the
>> length of the BINARY value
is in binary digits if we just put a binary
>> number in it. Also, I
do not know if this is even a valid type in C for
>> Microsoft. I am
trying to find that out right now. But it certainly isn't
>> a type
in ISO C. It may be implemented as a class in C++, but I'm not that
>> familiar with Windows programming, so I'm kind of learning the
Windows
>> specific stuff as I go.
>>
>>
"Washington Moreira" <digisystem@xxxxxxxxxxxxxxxx>
wrote in message
>> news:uvUahkW9FHA.3760@xxxxxxxxxxxxxxxxxxxx...
>>> Very thanks Eliot.
>>> Thanks for your
comments about my struct. I'm 54 years old and sometimes
>>> my
mind fails, and for many years I have not used one packet structure.
>>> My wrong packed struct would be correct for an old 16 bit
environment.
>>> Excuse-me if I'm an idiot asking about your
struct layout:
>>> I need 16 bits to define the first three
fields, but you are using an
>>> UCHAR data type encompassing
these 16 bits. Is this correct?
>>>
>>> Please look
below to these few code lines writed for an Unix Like
>>>
environment (from
>>> http://hostap.epitest.fi/wpa_supplicant/devel/eap__tlv_8h.html)( from
>>> header
file):
>>>
>>> 00048 struct eap_tlv_result_tlv
{
>>> 00049 u16
tlv_type;
>>>
00050 u16
length;
>>> 00051
u16 status;
>>> 00052 }
__attribute__((packed));
>>>
>>> And from C source
file (from
>>> http://hostap.epitest.fi/wpa_supplicant/devel/eap__tlv_8c.html) Note that
>>> the function below constructs
the complete EAP response including the TLV
>>>
packet:
>>>
>>> 00058 u8 *
eap_tlv_build_result(int id, u16 status, size_t *resp_len)
>>>
00059 {
>>>
00060 struct eap_hdr
*hdr;
>>> 00061 u8
*pos;
>>> 00062
>>>
00063 *resp_len =
sizeof(struct eap_hdr) + 1 + 6;
>>>
00064 hdr =
malloc(*resp_len);00065 if
(hdr == NULL)
>>>
00066
return NULL;
>>> 00067
>>>
00068 hdr->code =
EAP_CODE_RESPONSE;
>>>
00069 hdr->identifier =
id;
>>> 00070
hdr->length = host_to_be16(*resp_len);
>>>
00071 pos = (u8 *) (hdr +
1);
>>> 00072
*pos++ = EAP_TYPE_TLV;
>>>
00073 *pos++ = 0x80; /*
Mandatory */
>>>
00074 *pos++ =
EAP_TLV_RESULT_TLV;
>>>
00075 /* Length
*/
>>> 00076
*pos++ = 0;
>>>
00077 *pos++ =
2;
>>> 00078 /*
Status */
>>>
00079 WPA_PUT_BE16(pos,
status);
>>> 00080
>>>
00081 return (u8 *)
hdr;
>>> 00082 }
>>>
>>>
>>>
If I'm not wrong, looking above, there is two bytes for the first three
>>> fields(not declared in this way), more two bytes to define
the length of
>>> the value. In this case the status is a two
bytes value.
>>>
>>> If 16 bits is correct to define
the first three fields, rewriting my
>>> packed struct woul
be:
>>>
>>> typedef struct
_PEAPTLV_URI{
>>>
WORD TLVType
: 14;
>>> //bit fields from position 0 -
13
>>>
WORD TLVReserved : 1; //bit
>>> field position
14
>>>
WORD TLVMandatory : 1; //bit
>>> field position 15 closing the first two
bytes
>>>
UCHAR TLVValueLength; //Here the
>>> big doubt, IETF docs ponts
this as a 16
bits
>>>
UCHAR TLVValue[UNLEN];
>>> }PEAPTLV_URI,
*pPEAPTLV_URI;
>>>
>>> (note the bit fields declared
from right (low order) to the left (high
>>> order) In this way I
don't need to use bitwise operators.
>>>
>>> Please
I'm waiting your comments. Perhaps, exchanging our tests and
>>>
informations we can solve our problems.
>>>
>>>
Thanks
>>> Washington
Moreira
>>>
>>>
>>>
>>> "Eliot
Gable" <support8@xxxxxxxxxxxxxx> wrote in
message
>>> news:1133306452_43599@xxxxxxxxxxxxxxxxxxxxxxxxx...
>>>> This is what I have based on the WPS
Deployment documentation on the
>>>> structure of the EAP
packets:
>>>>
>>>> #define EAP_TLV_RESULT_TLV 3
/* Acknowledged Result */
>>>> #define EAP_TLV_NAK_TLV
4
>>>> #define EAP_TLV_CRYPTO_BINDING_TLV 5
>>>>
#define EAP_TLV_CONNECTION_BINDING_TLV 6
>>>> #define
EAP_TLV_VENDOR_SPECIFIC_TLV 7
>>>> #define EAP_TLV_URI_TLV
8
>>>> #define EAP_TLV_EAP_PAYLOAD_TLV 9
>>>>
#define EAP_TLV_INTERMEDIATE_RESULT_TLV 10
>>>> #define
EAP_TLV_PAC_TLV 11 /* draft-cam-winget-eap-fast-01.txt */
>>>>
#define EAP_TLV_CRYPTO_BINDING_TLV_ 12 /*
>>>>
draft-cam-winget-eap-fast-01.txt */
>>>>
>>>>
#define EAP_TLV_RESULT_SUCCESS 1
>>>> #define
EAP_TLV_RESULT_FAILURE 2
>>>>
>>>> #define
EAP_TLV_TYPE_MANDATORY 0x80
>>>> #define
EAP_TLV_TYPE_ACK_RESULT
0x03
>>>>
>>>>
>>>> typedef
struct eap_tlv_uri_packet {
>>>> UCHAR TLVType; /*
Bit 1: Mandatory Requirement
*/
>>>> /* Bit 2: TLVReserved
*/
>>>> /* Bit 3-16: TLVType
*/
>>>> UCHAR TLVValueLength;
>>>> UCHAR
TLVValue;
>>>> }
EAPTLVURIPACKET;
>>>>
>>>> typedef struct
eap_tlv_result_packet {
>>>> UCHAR TLVPacketType; /* Bit
1: Mandatory Requirement
*/
>>>> /* Bit 2:
TLVReserved */
>>>>
/* Bit 3-16: TLVPacketType */
>>>> USHORT
TLVStatusLength;
>>>> USHORT TLVStatus;
>>>> }
EAPTLVRESULTPACKET;
>>>>
>>>>
>>>>
>>>>
>>>>
In my actual code block that adds the EAP-TLV URI, I have
this:
>>>>
>>>>
>>>>
ucTLVValueLength = (UCHAR) strlen(url);
>>>> cbDataLength =
sizeof(EAPTLVURIPACKET) + (sizeof(UCHAR) *
>>>>
ucTLVValueLength) + 1;
>>>> sprintf(mesg, "About to malloc %d
bytes for EAPTLV Packet.\n",
>>>>
cbDataLength);
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> euEAPTLV =
RadiusAlloc(cbDataLength);
>>>> sprintf(mesg, "Finished
malloc.\n");
>>>> Debug(mesg);
>>>> bzero(mesg,
255);
>>>> euEAPTLV->TLVType =
EAP_TLV_URI_TLV;
>>>> euEAPTLV->TLVValueLength =
ucTLVValueLength;
>>>> sprintf(mesg, "About to copy %d bytes
data into TLVValue location at
>>>> %X.\n", strlen(url),
&euEAPTLV->TLVValue);
>>>>
Debug(mesg);
>>>> bzero(mesg, 255);
>>>>
strcpy(&euEAPTLV->TLVValue, url);
>>>> sprintf(mesg,
"Done copying.\n");
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> cbDataLength = strlen((const
char*)euEAPTLV);
>>>> sprintf(mesg, "Length of EAP TLV Packet:
%d.\n", cbDataLength);
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>>
>>>> /* Fill in the
RADIUS_ATTRIBUTE struct. */
>>>> /*cbDataLength =
strlen(url);*/
>>>> raEAPTLV.dwAttrType =
ratEAPTLV;
>>>> raEAPTLV.fDataType =
rdtUnknown;
>>>> raEAPTLV.cbDataLength =
cbDataLength;
>>>> raEAPTLV.lpValue = (PCSTR)
euEAPTLV;
>>>>
>>>> /* Add as the ratPEAPTLV URI
TLV. */
>>>> sprintf(mesg, "Replacing first attribute of
ratEAPTLV.\n");
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> dwResult =
RadiusReplaceFirstAttribute(pInRespAttrs,
&raEAPTLV);
>>>>
>>>>
>>>>
>>>>
Then, in
RadiusReplaceFirstAttribute:
>>>>
>>>>
>>>>
>>>>
>>>>
DWORD
>>>> WINAPI
>>>>
RadiusReplaceFirstAttribute(
>>>>
PRADIUS_ATTRIBUTE_ARRAY pAttrs,
>>>> const
RADIUS_ATTRIBUTE* pSrc
>>>> )
>>>>
{
>>>> DWORD dwIndex, dwResult;
>>>> char
mesg[255];
>>>> bzero(mesg,
255);
>>>>
>>>> if ((pAttrs == NULL) || (pSrc ==
NULL))
>>>> {
>>>> return
ERROR_INVALID_PARAMETER;
>>>>
}
>>>>
>>>> dwIndex =
RadiusFindFirstIndex(pAttrs,
pSrc->dwAttrType);
>>>>
>>>> if (dwIndex !=
RADIUS_ATTR_NOT_FOUND)
>>>> {
>>>>
sprintf(mesg, "Attribute found at index %d.\n",
dwIndex);
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> /* It already exists, so overwrite
the existing attribute. */
>>>> dwResult =
pAttrs->SetAt(pAttrs, dwIndex, pSrc);
>>>> } else
{
>>>> sprintf(mesg, "Attribute not found (%d). Adding
one (pAttrs := %X; pSrc
>>>> := %X).\n", dwIndex, pAttrs,
pSrc);
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> /* It doesn't exist, so add it to
the end of the array. */
>>>> dwIndex =
pAttrs->GetSize(pAttrs) - 1;
>>>> dwResult =
pAttrs->InsertAt(pAttrs, dwIndex, pSrc);
>>>>
}
>>>>
>>>> if(dwResult == E_ACCESSDENIED)
{
>>>> sprintf(mesg, "Access denied while replacing
attribute.\n");
>>>>
Debug(mesg);
>>>> bzero(mesg, 255);
>>>>
}
>>>> if(dwResult == ERROR_INVALID_PARAMETER)
{
>>>> sprintf(mesg, "Invalid parameter while replacing
attribute: index out
>>>> of
range.\n");
>>>> Debug(mesg);
>>>>
bzero(mesg, 255);
>>>> }
>>>> if(dwResult ==
NO_ERROR) {
>>>> sprintf(mesg, "Success. Attribute
replaced or added.\n");
>>>>
Debug(mesg);
>>>> bzero(mesg, 255);
>>>>
}
>>>> sprintf(mesg, "Done replacing attribute. Returning with
result: %d.\n",
>>>> dwResult);
>>>>
Debug(mesg);
>>>> bzero(mesg,
255);
>>>>
>>>> return
dwResult;
>>>>
}
>>>>
>>>>
>>>> Of course, when
I try to add the parameter, I get the error 87
>>>>
(ERROR_INVALID_PARAMETER). I do not get an error in
IASSAM.log.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
"Washington Moreira" <digisystem@xxxxxxxxxxxxxxxx>
wrote in message
>>>> news:OlChE9S9FHA.952@xxxxxxxxxxxxxxxxxxxx...
>>>> Hi
Eliot,
>>>>
>>>> First, thank you for your post
on my previous thread. At least I'm not
>>>> alone with this
problem.
>>>>
>>>> Looking for my rastls.log I
think that my big problem is the EAPTLV URI
>>>> struct format
that I have created based on docs from the WPSDeploy.doc
>>>>
and WPS Protocol description on MSDN (
>>>> http://msdn.microsoft.com/library/default.asp?url=""> )
>>>> As I have explaned in other posts,
from WPS Protocol description we
>>>>
have:
>>>>
>>>> PEAP-TLV URI
Packet
>>>> Fields
>>>>
>>>>
MandatoryRequirement Type Binary(1 bit) Mandatory TLV set to
1
>>>>
TLVReserved Type
Binary(1 bit) set to 0
>>>>
TLVType
Type Binary(14 bits) set to 8
>>>>
TLVValueLength Type UCHAR Length of
TLVValue field
>>>>
TLVValue
Type UCHAR URI to a master document
>>>>
>>>>
From these infromations above we can create a packet struct. But look
>>>> now to the informations from
draft-josefsson-pppext-eap-tls-eap-10.txt
>>>> (15 October
2004)
>>>>
>>>>
_________________________________________________________________
>>>>
4.8. URI TLV
>>>>
>>>> The URI
TLV allows a server to send a URI to the client to refer
it
>>>> to a resource. The TLV contains a URI
in the format specified in
>>>> RFC2396 with UTF-8
encoding. Interpretation of the value of the
URI
>>>> is outside the scope of this
document.
>>>>
>>>> If a packet
contains multiple URI TLVs, then the client SHOULD
select
>>>> the first TLV it can implement, and
ignore the others. If the client
>>>> is
unable to implement any of the URI TLVs, then it MAY ignore
the
>>>> error. PEAP implementations MAY
support this TLV; and this TLV
>>>> cannot be
responded to with a NAK TLV. The URI 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
|
>>>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
|
URI...
>>>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>
M
>>>>
>>>> 0 -
Optional TLV
>>>>
>>>>
R
>>>>
>>>>
Reserved, set to zero (0)
>>>>
>>>>
TLV Type
>>>>
>>>>
8
>>>>
>>>>
Length
>>>>
>>>>
>=0
>>>>
>>>>
URI
>>>>
>>>> This
field is of indefinite length, and conforms to the
format
>>>> specified in
[RFC2396].
>>>>
______________________________________________________________________________________________
>>>>
>>>>
As you can see, we have conflicts. Note that the field Length is a 16
>>>> bit value and the mandatory field is zero (non
mandatory)
>>>>
>>>> My doubt is how MS have
implemented on IAS?
>>>>
>>>> OK. Returning to
my rastls.log you will see that my TLV URI packet sent
>>>> to
the eap dll was discarded because was considered as a invalid
>>>> attribute. Below a relevant lines from the
log:
>>>>
_______________________________________________________________________________
>>>>
[1912] 16:47:40:703: EapTlsBegin()
>>>> [1912] 16:47:40:703:
SetupMachineChangeNotification
>>>> [1912] 16:47:40:703: State
change to Initial
>>>> [1912] 16:47:40:703: EapTlsBegin:
Detected PEAP authentication
>>>> [1912] 16:47:40:703:
MaxTLSMessageLength is now 16384
>>>> [1912] 16:47:40:703:
CRYPT_E_NO_REVOCATION_CHECK will not be ignored
>>>> [1912]
16:47:40:703: CRYPT_E_REVOCATION_OFFLINE will not be
ignored
>>>> [1912] 16:47:40:703: The root cert will not be
checked for revocation
>>>> [1912] 16:47:40:703: The cert will
be checked for revocation
>>>> [1912] 16:47:40:703:
EapPeapBegin done
>>>> [1912] 16:47:40:703:
EapPeapMakeMessage
>>>> [1912] 16:47:40:703:
EapPeapSMakeMessage
>>>> [1912] 16:47:40:703:
PEAP:PEAP_STATE_INITIAL
>>>> [1912] 16:47:40:703:
EapTlsSMakeMessage
>>>> [1912] 16:47:40:703:
EapTlsReset
>>>> [1912] 16:47:40:703: State change to
Initial
>>>> [1912] 16:47:40:703:
GetCredentials
>>>> [1912] 16:47:40:703: Flag is Server and
Store is local Machine
>>>> [1912] 16:47:40:703:
GetCachedCredentials Flags = 0x4061
>>>> [1912] 16:47:40:703:
GetCachedCredentials: Using Cached Credentials
>>>> [1912]
16:47:40:703: GetCachedCredentials: Hash of the cert in the cache
>>>> is
>>>>
>>>> 6
4 3 E 5 8 D 2 5 2
2 5 C 4 0 3 6 D 1
C 6 9 A D
>>>> D 0 5 2 F
C F 5 | d > X . R % . . m . i . . R . .
|
>>>>
>>>> C A 1 B 8
0 A 2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
>>>> 0 0 0 0 0 0 0 0 | . .
. . . . . . . . . . . . . . |
>>>> [1912] 16:47:40:703:
BuildPacket
>>>> [1912] 16:47:40:703: << Sending Request
(Code: 1) packet: Id: 33,
>>>> Length: 6, Type: 13, TLS blob
length: 0. Flags: S
>>>> [1912] 16:47:40:703: State change to
SentStart
>>>> [1912] 16:47:40:703: EapPeapSMakeMessage
done
>>>> [1912] 16:47:40:703: EapPeapMakeMessage
done
>>>> [1912] 16:47:40:703:
EapPeapMakeMessage
>>>> [1912] 16:47:40:703:
EapPeapSMakeMessage
>>>> [1912] 16:47:40:703:
PEAP:PEAP_STATE_WAIT_FOR_APPLICATION_TLV
>>>> [1912]
16:47:40:703: Received invalid attributes from
application.
>>>> [1912] 16:47:40:703: EapPeapSMakeMessage
done
>>>> [1912] 16:47:40:703: EapPeapMakeMessage
done
>>>> [1912] 16:47:40:703: EapPeapEnd
>>>>
[1912] 16:47:40:703: EapTlsEnd
>>>> [1912] 16:47:40:703:
EapTlsEnd()
>>>> [1912] 16:47:40:703: EapPeapEnd
done
>>>>
___________________________________________________________________________________________________
>>>>
>>>>
>>>>
I hope that we find someone that help us.
>>>> Thanks for your
attention
>>>>
>>>> Washington
Moreira
>>>>
>>>>
>>>>
>>>>
>>>>
"Eliot Gable" <support8@xxxxxxxxxxxxxx> wrote in message
>>>> news:1133294445_42627@xxxxxxxxxxxxxxxxxxxxxxxxx...
>>>>>I am trying to write an extension
DLL for IAS that does the WPS guest
>>>>> authentication. I
have it successfully registering itself, grabbing
>>>>>
packets,
>>>>> testing cases, selectively converting
Access-Reject packets to
>>>>>
Access-Accept
>>>>> packets, etc. The only part I cannot
figure out is how and when to do
>>>>>
the
>>>>> EAP-TLV URI attribute-value pairs. I imagine I do
them in an
>>>>> Access-Challenge packet, but I do not know
how to figure out WHICH
>>>>> packet
to
>>>>> put them in or HOW to put them in the packet. I
cannot find any USEFULL
>>>>> documentation on doing the EAP
programming stuff in an IAS DLL. I also
>>>>>
do
>>>>> not understand how my EAP messages get encrypted
along with the rest,
>>>>> or how
>>>>> I
can modify them inside a call to the RadiusExtensionProcess2
>>>>> function. Any
>>>>> help or
examples on how to do this would be greatly
appreciated.
>>>>>
>>>>>
Thanks.
>>>>>
>>>>> Eliot
Gable
>>>>> CCNA, CWNA, CWSP,
>>>>>
Security+,
Network+
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
>>>>> News==----
>>>>> http://www.newsfeeds.com The #1
Newsgroup Service in the World!
>>>>> 120,000+
Newsgroups
>>>>> ----= East and West-Coast Server Farms -
Total Privacy via Encryption
>>>>> =----
>>>>
>>>>
>>>>
>>>>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
>>>> News==----
>>>> http://www.newsfeeds.com The #1
Newsgroup Service in the World! 120,000+
>>>>
Newsgroups
>>>> ----= East and West-Coast Server Farms - Total
Privacy via Encryption
>>>> =----
>>>
>>>
>>
>>
>
>
|
