Presumably you are looking at something like this: https://www.etsi.org/deliver/etsi_ts/129200_129299/129229/13.01.00_60/ts_129229v130100p.pdf
*6.3.10 SIP-Authenticate AVP* *The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response.It shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See3GPP TS 33.203 [3] for further details about RAND and AUTN. The Authentication Information has a fixed length of32 octets; the 16 most significant octets shall contain the RAND, the 16 least significant octets shall contain the AUTN.* I believe what it's saying is: in the [textual] SIP WWW-Authenticate header, there are some fields RAND and AUTN which are encoded in some textual form (hex? base64? Check the details of the auth scheme) You need to convert those to their underlying binary data, giving you two [16]byte blobs, then concatenate them to give 32 bytes of data. If so, you had roughly the right idea in the first place (except s2 was less than 16 bytes). You could concatenate the hex representations and then decode, as you did; or I would be inclined to decode them separately: https://go.dev/play/p/851IrsExn76 The result is [32]byte, which is 16 bytes from one field and 16 bytes from the other. You just use it as-is for the AVP value; this is the "binary encoded" value. It doesn't mean you should turn it into a string of ASCII "1" and "0" characters. On Tuesday, 14 March 2023 at 11:12:11 UTC Brian Candler wrote: > On Tuesday, 14 March 2023 at 09:26:05 UTC Van Fury wrote: > > Am developing a server (diameter) which will response with an AVP > SIP-Authenticate. > In the specification > > " The SIP-Authenticate AVP is of type OctetString and It shall contain, > binary encoded, the concatenation of the authentication challenge RAND and > the token AUTN" > > > I believe "binary encoded" here just means []byte. Concatenate them using > append(). > > > > > The RAND and the AUTN in this case are hexadecimal strings s1 and s2. > > > I don't believe either is a "hexadecimal string" in the sense of being > encoded using the ASCII symbols "0" to "9" and "a" to "f". They may > conventionally be *displayed* in this format, e.g. for debugging purposes, > but internally and on-the-wire I think they are just sequences of bytes. > > NOTE: my experience is with RADIUS rather than Diameter, so I *could* be > wrong. I'm just outlining what I *expect* to be the case; I haven't gone > reading through Diameter RFCs. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/de06f8ad-b81f-4fc2-bca0-9a356e92f956n%40googlegroups.com.
